Khoji On Tech (and more)

Windows Vista protects itself against illegal Registry writes with a “fake” virtual registry, to which the illegal writes can be made without doing any damage to the real registry. The company I work for produces a little free utility that writes some Registry values to solve some problems with certain file types on network drives. In the process of testing this utility for Vista we have discovered some interesting facts about the way this virtual Registry works. We’re not yet 100% sure about all the ramifications, but it looks as though this is going to have far-reaching consequences for many existing programs. Many will seem to work at first but will then fail, many will have to be rewritten.

Normally, when a program wants to start with Admin rights Vista’s UAC (User Account Control) will kick in and ask the user to confirm that the operation can be performed. However, this only happens if a program explicitly asks for Admin rights, for which there is a special new mechanism in Vista called the application manifest (details and a link at the end of this post).

If a program just starts normally, not asking for any special rights, UAC does not kick in. In default Vista mode, that program will start with restricted rights, even if it is an old XP-style program that actually expects to be running in an Admin account, which is the case with very many Windows programs. What is really interesting is what happens if a program like this then tries to write to the Registry: Nothing! As far as the program is concerned, it is able to write the Registry with full Admin rights. It can write keys, delete keys, create and change values in any way it wants in any part of the Registry it wants. UAC does not kick in, no error messages are displayed, no error states are returned after the writes. As far as the program is concerned, its values have been written to the Registry correctly. It can even read them back from the Registry again, and the values will still be there after a Vista reboot.

The only problem is, the values haven’t been written to the Registry. They have been written to a virtual Registry that appears to be a kind of sandbox. The program itself can read its values back from this fake Registry, but any Registry values for Windows functions or settings will always fail because Vista itself only reads the real, protected Registry. If you open RegEdit and look for the values your program has written you will not find anything there. We haven’t yet been able to find out where this is stored, but there appears to be one instance for each user account in Vista.

This new mechanism is going to have a very mixed bag of consequences. Programs that merely abuse the Registry as their own private database are going to be OK, at least on the face of it, because they will be able to write and read back the values they need. However, any programs that write Registry values that need to be read by other programs or Windows will fail, because those values are written to the fake Registry, not the real Registry. All these programs will have to be rewritten to include an application manifest (see below).

In their infinite and predictable wisdom, Microsoft have decided not to issue any error messages or warnings when programs expecting to have Admin rights make writes to the Registry. Instead, Vista seamlessly permits these programs to make their writes, letting them believe that they have the same write permissions they had under XP. This means that all the programs that only store their data values in the Registry are going to be building up an additional parallel Registry in Vista, which may or may not have negative consequences, but editing the Registry is going to become much more interesting. When you edit the Vista Registry with RegEdit you can no longer be sure that what you see is what is really there. New tools are going to be needed that also provide access to the fake Registry. Or Registries — remember, it seems that there is one of these things for every user account.

To avoid all this, programs needing permission for Admin writes must come with an “application manifest”, which is an .XML-style file that can be included either as an external file or compiled into the application directly. If you’re interested in the technical details they are available in Kenny Kerr’s developer blog. Programs that need to make system-wide Registry entries, or entries that can be read by Windows or other programs, will fail silently without an application manifest. Their writes will seem to work and will not generate any error messages but actually they are being written to one of the fake sandbox Registries.