The Case of RegSvr32 and the Haunted DLL

June 28, 2008

no comments

Last week I’ve resolved a simple “debugging” case by phone, and figured that it might benefit putting it online.  Here’s the approximate outline of the call:

Customer: Sasha, we have a COM component registration that is failing because regsvr32 says it can’t find the DLL.

Myself: Where is it looking for that DLL?

Customer: It doesn’t matter where it’s looking.  We put the component in the System32 directory, but it still complained that it can’t find it.

Myself: [With a flash of psychic debugging] Is it a 64-bit system and you’re trying to register a 32-bit component?  You should put the component in the SysWOW64 directory.

Customer: Yes, how did you know that?

This is one of these psychic debugging cases, where you can see the answer in a split second if you’ve encountered the situation before.  When a 32-bit application (be it an installer or the 32-bit regsvr32.exe) thinks it’s looking for a file in the System32 directory, it’s actually looking for the file in the SysWOW64 directory.

The reason for this behavior is plain old compatibility.  32-bit applications running on top of the Windows-on-Windows64 layer should be none the wiser regarding the location of system DLLs.  Therefore, file system redirection ensures that any accesses (even hard-coded accesses) to the System32 folder are routed to SysWOW64.  The same applies to the Program Files directory, which on a 64-bit system is replicated to Program Files (x86) for 32-bit applications.  And finally, if you remain incautious, the same issue can bite you with registry redirection – there is a separate view of the registry for 32-bit applications on 64-bit Windows, and only a small number of keys are reflected across both registry views for interoperability scenarios.

This can lead to the very frustrating situation where you’re repeatedly trying to copy the file to System32 and run the registration code, only to be told that the file could not be found.

If you’re keen enough on porting your applications to 64-bit Windows, you’re probably not going to port every single line of code you’ve ever written – at the same time.  .NET applications are easiest to port, but native code takes time.  Therefore, you are probably going to end up running 32-bit applications on 64-bit Windows and getting 32-bit processes to talk to 64-bit processes.  This can be challenging, and we at Sela have prepared a 2-day course for addressing the new 64-bit architecture, improvements and practical porting issues for managed and native applications, and writing high-performance concurrent applications on top of the newest versions of Windows.

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>