How can I force a DLL to register itself if it won’t respond to regsvr32?
A customer was having trouble registering a DLL.
We are trying to use the
regsvr32command to register a DLL that is not already registered, but the command is not working. We get the message “The module ‘contoso.dll’ was loaded but the entry-point DllRegisterServer was not found. Make sure that ‘contoso.dll’ is a valid DLL or OCX file and try again.” How can we force contoso.dll to be registered?
Registering a DLL is not a formally-defined operation. It’s a general way of saying “Do whatever is required to make it possible to use the DLL in the manner it was intended.” For DLLs that are COM servers, this typically means creating registry keys to advertise the DLL’s objects.
There is a convention for DLLs that if they know how to register themselves, they can export a function under the well-known name DllÂRegisterÂServer, and the function must follow certain rules. Furthermore, a DLL that supports DllÂRegisterÂServer advertises the fact by adding the string OLESelfRegister to their version string file info.
But there is no rule that requires any arbitrary DLL to support this feature.
From the error message, it is apparent that the contoso.dll does not support this optional feature. You can’t force it to support a feature any more than you can force a program to support the -? option or force a book to have a happy ending.
The idea of self-registration comes from the days of ActiveX, when the idea was that users could go to a Web page and install components directly off the Internet. The system would use the DllÂRegisterÂServer function to tell the DLL, “Okay, you’ve just been downloaded. Please do whatever is required so that Web pages can start using you.”
ActiveX as a Web technology is dead. Nobody uses it any more. The problem that DllÂRegisterÂServer was created to solve no longer exists. But the idea of DllÂRegisterÂServer still carries on. There is nothing inherently Internet-related about DllÂRegisterÂServer, and some people still use it to decentralize their setup programs: Instead of putting all of the settings required by their program in one massive file, they let each DLL be responsible for its part of the project.
But the authors of contoso.dll didn’t do that. The work of setting up the system so that the contoso.dll file is ready to use is handled by whatever program installed contoso.dll. If you need to register contoso.dll, you’ll have to run its setup program.
Light
Dark
6 comments
Excellent info.
I’ve lost count of how many times I had to explain to bosses, managers and coworkers that there is nothing magical about registering a DLL, that it is just a call of a function.
And if you’re the DLL author and the dll does need registering, please make regsvr32 conoso.dll work. I’ve seen too many cases where some completely outside thing damaged the DLL registration and it needed to be redone and the setup program wouldn’t do it because the product was installed as far as it could see.
We had a slightly different problem although it seems to have abated now, but some years ago there was some widespread brain rot where people would automatically try and register any DLL they encountered. We got so many problem reports from people trying to register a DLL that wasn’t a COM server that we added a dummy DllRegisterServer() that pops up an error message asking the user why they’re trying to register a DLL that isn’t supposed to be registered.
I wanted to add “Does your mother know you’re doing this?” to the message but was overruled.
The reason for this was due to a bug in Windows Update for Windows 7 and Windows 8. It would randomly lose DLL registrations of critical windows components causing explorer to break in mysterous ways.
The fix was to register *all* DLLs in Windows\system32 with regsvr32 using a cmd.exe for loop; ignoring any errors this generated. All you did by popping up the message box was annoy people trying to fix this.
That said, in the unlikely case when the DLL in question is indeed a reasonably vanilla in-proc COM server but doesn’t self-register, there are still things they can do about it. For one, take a look at the resources – does it have an embedded typelib? If so, pull the CLSIDs/ProgIDs from there, and slap the InprocServer32 with the DLL path on the former.
IIRC, the DllRegisterServer thing predates ActiveX on the Web, it was introduced along with in-proc servers in general when 16 bit COM/OLE 2 were first introduced, made popular by Word 6. Year 1994 or so, when Windows 3.11 for Workgroups were all the rage.