Registering a 32bit DLL with SysWow64\Regsvr32 generates a different CLSID, then an error message

Question

Dev environment :

• Windows 2008 Server 32 bits
• Visual Studio 2010 Professional
• Visual Basic 6

Target environment :

• Windows 2012 R2 64 bits

A VB6 application ( app.exe ) relies on a COM-visible .NET DLL ( netdll.dll ), which relies itself on a COM DLL generated by Visual Basic 6 (a wrapper to handle the ListBox object, lets call it vb6dll.dll ).

All of them are 32bits, since the dev os is 32 bit, as said above. I also checked them with the file command provided with Cygwin :

amessihel@aselkim:~> file path/to/app.exe
path/to/app.exe: PE32 executable (GUI) Intel 80386, for MS Windows

amessihel@aselkim:~> file path/to/netDLL.dll
path/to/netdll.dll: PE32 executable (DLL) (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

amessihel@aselkim:~> file path/to/vb6.dll
path/to/vb6.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

RegAsm was used to register netdll.dll :

amessihel@aselkim:~> /cygdrive/c/Windows/Microsoft.NET/Framework/v4.0.30319/RegAsm ./netdll.dll /codebase /tlb:netdll.tlb

SysWow64\\RegSvr32 was used to register vb6dll.dll in the target environnment.

amessihel@aselkim:~> /cygdrive/c/Windows/SysWOW64/regsvr32.exe ./vb6dll.dll

When I launch the VB6 application, I got this message :

Retrieving the COM class factory for component with CLSID {XXXX} failed due to the following error: 80040154

I think it's not a duplicate of this question . I figured out the CLSID of vb6dll.dll changed from Windows 2008 to Windows 2012 R2 ... And it seems to be why netdll.dll can't find it... If so, why registering behaves this way ?

Update : I admit I'm a newbie with CLSID stuffs... If I understand it clearly, VB6 writes itself CLSIDs for each COM object, and these CLSIDs are retrieved by RegSvr32. If true, why Windows 2012 version of RegSvr32 (SysWow64) writes another CLSID in the registry ?

Answer 1

Resolved. The CLSID is written inside the DLL. Adapted a piece of code found here to write a small appli retrieving the CLSID for a DLL. I found out my DLL wasn't identical, because it was command-line generated without binary compatibilit y.

TL;DR : if the CLSID change, the DLL too.