regsvr32 Problems

ActiveX components and controls have been around for many years.  Unfortunately, when regsvr32 fails to register a DLL, the only information provided is an error code.  Usually in the format of a 32-bit hex number, such as 0x80004005 (although not necessarily that particular error code, I simply picked one at random for this blog post).

If you search the Internet, you’ll soon realize that regsvr32 has been a “pain-in-the-butt” for many many years (not just for Chilkat DLL’s, but for all ActiveX DLL’s including Microsoft’s very own).  The biggest problem is that there’s NO information about why it failed, and there are a large number of potential reasons — and the list of reasons and the complexity of operating system security/access/permissions is ever-increasing.

A natural reaction is to assume that the problem must be related to something within the DLL.  In the case of Chilkat ActiveX DLL’s, this is always NOT true.  The Chilkat ActiveX’s are standard self-registering ActiveX components, and the internal code relating to regsvr32 registration is exactly what is generated by Microsoft Visual Studio for ATL/COM projects.  It has been unchanged for approx. 10 years.  Therefore, any problem with regsvr32 is always a result of the environment, usually security, permissions or access restrictions.  For example, does the DLL reside on a UNC path that is not local to the computer and therefore not trusted?  The best way to solve a regsvr32 problem is to Google the error code returned by regsvr32.

I hope that one day Microsoft improves the regsvr32 error message to give us some sort of clue about the cause of a regsvr32 failure…