As I've mentioned previously, Windows Vista has significantly improved user access control, so at long last you don't need to run as an Administrator all the time. Instead any operations that require administrative privileges prompt for a password before allowing them to run. This is nothing terribly special - Unix has been doing these for decades.

Of course its a little painful when you first install your computer as seemingly everything needs to be elevated, but once that's done it's much less of a problem.

Part of this user access control functionality is that the program files directory (generally C:\Program Files) can no longer be written to by applications (unless explicitly run as administrator). If an application tries to write to this location, it instead ends up writing to a location within the user's profile instead (something like C:\Users\Dave\AppData\VirtualStore\Program Files). This is supposed to be completely transparent to the program in question - it thinks it is writing to C:\Program Files, and can successfully reload the files again afterwards.

Up until yesterday this had worked fine for me with no problems whatsoever. I had run all our applications and catalogued all instances where they incorrectly try to write to the program files directory, to ensure that we fix them in the near future. All seemed well.

Then one of our applications suddenly stopped working on my machine (and just on my machine). It was failing with an error trying to load one of our DLLs, which was located in the application directory. Bizarre. The application directory is the FIRST place that Windows looks when loading DLLs.

So I thought, maybe that DLL is missing a dependency instead. I opened up Dependency Walker and tried to open the DLL. It couldn't find the file at all. In fact it thought that the entire application directory was empty. So I tried with OleView and got exactly the same result.

It turned out that file virtualization was busted. There was an empty directory in the virtual store program files with the same name as my application directory. When Dependency Walker, OleView, and my application were run, they seemed to see only this empty directory, instead of getting a merged view of both that directory, and the real program directory.

Consequently the application couldn't find its DLLs, and so failed to load miserably. Deleting the directory under the virtual store fixed the problem, and everything worked again. I tried creating the directory manually in the virtual store, and again things stopped working.

So it appears as either there is a bug in file virtualization so that it fails to merge the directories correctly in some cases, or alternatively there is a way to toggle how this works but I was unable to find it (and I searched for quite a while).

Ultimately I rolled back to a system restore point and things worked correctly again.

Anyone know how to report bugs to Microsoft these days? This is without getting charged for a support call of course?

Posted by Dave Bryant at 7:33 PM | Comments (2) | TrackBacks (0)