REGSVR32: the module "xxxxx.dll" failed to load ... dependent assembly could not be found

Question

I'm having an issue with regards to registering a *.dll under Windows 7 x64.

I've tried placing the *.dll in both, C:/Windows/System32 and C:/Windows/SysWOW64 and attempting to register with "regsvr32 xxxxx.dll" under an elevated command prompt. I also tried to register it from a seperate directory. It responds with the following error:

The module "xxxxx.dll" failed to load.
Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

The EventLog notes:

Activation context generation failed for "C:\(path-to-dll)
Dependent Assembly
Microsoft.VC90.ATL,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found.
Please use sxstrace.exe for detailed diagnosis

N.B. I have installed both x86 and x64 Microsoft Visual C++ 2010 Redistributables.

An interesting aside is that I attempted to register the same *.dll on my work x64 Windows 7 laptop and it registered as expected. I guess this leans towards the fact that some kind of C++ dependency is missing / ATL related?

If anyone could help point me in the right direction or shed any additional light on the matter; i'd be more than grateful.

Regards.

Huey

Where did you look for the error? Is that in the windows application logs? I don't see any there – Zellazelle

System log in the Windows event viewer iirc @RennishJoseph – Huey

Answer 1

This is almost certainly due to a missing dependency. Use a tool like Dependency Walker to find the required dependencies of the DLL. Or, if the DLL is supplied by a third party, read their documentation which should specify the required dependencies.

Note that Microsoft.VC90.ATL indicates version 9 of MSVC which is VS2008. So you would need to install the MSVC 2008 runtime to meet that dependency. It looks like you installed the MSVC 2010 runtime by mistake.

Finally, please don't put files into the system directory. It belongs to the system and should not be modified by you.

Bushel

Thank you for the recommendation of Dependency Walker. It is indeed a very powerful tool. I was not intending on leaving the *.dll in the system directories, it's just something that was suggested as a solution on similar posts on SO; I was scepital to believe it myself. You were correct, it was a mistake on my behalf; for whatever reason I assumed Version9 was VS2010 and not VS2008. Installing the VS2008 x86 Redistributables solved my issue. Thank-you for your answer. – Huey

The system directory is a pet bug bear of mine. Hence my little mini-rant!! – Bushel

I can't say that I disagree! I've seen a lot of posts whereby people suggest dumping random *.dll's in there. Big pet peeve of mine as well. – Huey

Answer 2

Dependent Assembly Microsoft.VC90.ATL,processorArchitecture="x86"

This indicates missing Visual C++ runtime module (see Visual C++ Libraries as Shared Side-by-Side Assemblies). It is available as redistributable installer (this is presumably the one you need; x86 variant), which you need to install before registering your DLL (which is in turn dependent on missing component).

Rusticus

Hi Roman. Thank you for the response. The link you provided was more than helpful and i'll definately keep it in stock for the future. Cheers! – Huey

Have a look at updated answer, I added download link which should be helpful. – Rusticus

Answer 3

There is also another reason why this fails. I just ran into this myself. I was using API methods that did not support Windows 7, such as PathCchRemoveFileSpec which I had to update to the older, deprecated PathRemoveFileSpec. I used Dependency Walker to verify this was the cause. Dependency Walker lies a bit. If you look at my screenshot (below), the red section shows the actual problem - the methods it wasn't able to resolve in DLLs it has, etc. - but the blue shows DLLs that are actually not the problem at all (these DLLs exist). Since Dependency Walker is so old, it lies a bit (its outdated, it thinks something isn't available from time to time), but usually, it also tells the truth...you just have to scroll down a bit from the top left pane like I did. Note to self: please scroll down next time. Anyways, once I ditched pathcch.h, everything worked on 7. Happy coding.

Infidel

I don't see why this would cause regsvr32 to fail, unless the unsupported API calls were used in the DLLRegisterServer or DLLUnregisterServer functions? – Tetrarch

@DaveInCaz IIRC, if anywhere in the DLL there is a dependency to a new API function that does not exist yet in your version of Windows, it will fail this way. – Infidel

I see what you mean - the DLL will fail to load even before the register/unregister will be called. That makes sense, thanks – Tetrarch

@DaveInCaz N P ! – Infidel

Answer 4

I got relieved from this error message. In my binary path, I had a SPACE. Just replaced the SPACE with UNDERSCORE(_). It worked for me.

Dolmen

Answer 5

as i have also faced the same issue while registering the x.dll through Regsvr32,there is one of the possible reason is that x.dll might be unmaged dll. To use unmanged dll export function in the dot net code, you have to use Dllimport.

Bicycle