Unexpected permission "feature" in Windows 7

Question

I stumbled upon an unexpected permissions "feature" of Windows 7.  I was testing some ActiveX code used to write an Excel spreadsheet, and got a crash when I tried to close my file.  The same code worked just fine on my Windows XP machine, and it didn't matter if I used LabVIEW 8.6 or LabVIEW 2009.
Both machines were set up in the "standard" manner, and I was running as the sole user in an account with Administrator privileges.  My test file was C:\Test.xls.  When I invoked the ActiveX Close, I got an unknown error (-2146877284, which LabVIEW said was "unknown", but occurred in Excel).
When I examined the permissions for C:, I discovered that (for both XP and 7) the group "Users" has Read, but not Write, permissions, while "Administrators" have both Read and Write.  XP seems to allow the write, so works without errors.  Windows 7 may "want" to pop up the UAC window (which it definitely does not do), but I'm guessing that it is both ignoring my Administrator credentials and generating an "unknown" error call.
To test this theory, I wrote another routine to try to write a text file using standard LabVIEW VIs.  When I do a File Open with the Create option for a file on the root of the C: drive, I get Error 8 (File Permission error), which at least makes sense (after the fact).
I've brought this to the attention of the NI Support Team (who helped me figure this out).  If this is, indeed, the UAC getting into the fray, it would be "nice" if LabVIEW could notify us ...

Answer 1

In retrospect, I agree this is "expected behavior in Windows 7".  It
was completely unexpected by me, in part because it arose in a curious
context.  I originally developed my code on Windows XP, and made use of
the ability to right-click an ActiveX property node and get "Help for
Close" (for example).  In addition, the code I developed worked fine in
the early version where I did not try to write the results to a
file.  When I moved it to Windows 7, the right-click help was missing,
and seemed to be OS-specific.  As it happened, I was trying to add the
"Close" ability to save the file, and to simplify the path, I used
C:\Test.xls (much easier to type than C:\Users\Robert Schor\My
Documents\Test.xls), and had to go back to my XP machine to find out
descriptions for the arguments of the Close command.  So when the
program failed with an error message that was "off the wall" (referring
to an error code of -214682784, as well as a file name of C:\2CE93000),
I made the (logical?) assumption that this was "another Windows
7/LabVIEW incompatibility" bug/feature.  This was, of course, bolstered
by the observations that things worked under Windows XP and both
"failures" occurred in Windows 7.
It would be "nice" to
fix the problem with Help to work with Windows 7.  It would also be
"nice" to arrange to trap UAC-produced "errors" and have LabVIEW return
an error code such as 8 (even nicer would be to add an error code that
says "Windows UAC prevented access to this file").