Windows Explored

After a recent upgrade to a non-Windows component, we started a seeing a few complaints of Windows Script Engine issues, manifesting themselves as Internet Explorer issues or the failure to execute VB scripts on the local workstations. After isolating the issue to a problem registry value for VBscript and JScript, the issue was resolved by re-registering these components. In doing so, I became a little curious about the whole regsvr32 process and did a little investigating into what happens when regsvr32 is executed.

For starters, think of an unregistered DLL like a person without an identity. You exist, but without a social security number, an address, or any other official documentation, you’re just not a functional part of society. If you want to work, contribute, or be known, you need to walk into the local social security office and start by getting an SSN (yes, the Windows registry is a bureaucratic institution).

I use Process Monitor to do a simple trace all regvsr32.exe operations¹. In the example here, I am going to unregister and then register a module. It doesn’t really matter which one, but I want to use one where the effects of unregistering it are obvious. I start by un-registering jscript9.dll, the Windows Script Engine for Internet Explorer 9.

The process starts with some basic file operations as regsvr32 searches for jscript.dll:

Afterwards, the actual “un-registering” process begins when regsvre32 executes the necessary code within the DLL. Unregistering a module does not mean deleting it from the file system. Instead, regsvr32 comes along and says “I am deleting your identity from the registry and you are no longer a citizen of Windows”. Since these operations are spread across the procmon trace, I set a filter for registry deletion activity:

As mentioned above, the function for unregistering itself (DLLUnregisterServer) is within the DLL. You can see this by looking at the stack of one of the RegDelete operations:

Afterwards, Kernel32 is called to execute RegDeleteKey, and the result of this specific dll unregister can be seen by looking at the registry itself; the parent key for the JScript CLSID ({16d51579-a30b-4c8b-a276-0ff4dc41e755}) remains but the various sub-keys have been deleted²:

Programs can still reference or search for the guid (the CLSID), but if it no longer exists or there are no sub keys and data pointing to the path of the module or other necessary data , the program or Windows may error or just fail to perform some operation. To see the effect of this DLLUnregisterServer, if I open Internet Explorer and go to About Internet Explorer, there will be no version, cipher strength, and product ID information available as this relies on JScript to query and then display this information³:

Next, I do the opposite and register jscript9.dll, recreating the keys that were deleted earlier:

Again, the registration process is a function that resides within the DLL, DllRegisterServer:

And like before, kernel32 is called to execute RegCreateKey, and we can see the keys and values have been recreated in the registry:

For more information of regsvr32 usage and error messages, see http://support.microsoft.com/kb/207132 and http://support.microsoft.com/kb/249873.

¹ Be wary of the difference in registering system 64 bit modules vs 32 bit modules. In Windows 64 bit OS, all system 64 bit DLLs reside in windows\system32, while 32 bit DLLs reside in windows\syswow64, which you will need to manually navigate to. This also needs to be done from an elevated command prompt, otherwise regsvr32 will not execute properly.

² During the un-registration process in Windows 7, the following error is encountered: “The module ‘jscrip9.dll’ was loaded but the call to DLLUnregisterServer failed with error code 0x80004005…”

If you look at the trace for the un-registering process, you will notice the parent key for JScript has an operation CANNOT DELETE. I am not sure about the internals here but the cause for this is that the parent key is not being deleted during the unregister process, otherwise, things actually proceed normally and the sub-keys that contain the module values are deleted, effectively unregistering the module. I suppose post XP, it makes sense to leave the guid behind.

In Windows XP, all the keys for JScript are deleted, including the parent key. Additionally, in XP there are two other keys for JScript: JScript Authoring and JScript Encoding, which are, too, are deleted, as well as a series of other keys in HKCR:

³ If you want to pry a little deeper into this specific unregister process for jscript, you can actually see the script code it uses to display this information by looking in the temporary Internet files for a file named about: