c# application does not start on another computer

3
votes

when i try to launch my c# application on another computer than it was developed i get the following error message:

System.IO.FileLoadException: Could not load file or assembly 'Widgets3D, Version=1.0.3511.25568, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)

File name: 'Widgets3D, Version=1.0.3511.25568, Culture=neutral, PublicKeyToken=null' ---> System.Runtime.InteropServices.COMException (0x800736B1): This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)

i checked with dependency walker and process monitor but couldnt find any missing DLLs. especially the one mentioned in the error Widgets3D.dll is there!

both PCs are up to date with the latest XP service pack and updates. the application works on many PCs here. there is just this one which is making the problem.

EDIT: as suggested i tried to regsvr32 the missing dll, but that gives me this error:

LoadLibrary("./Widgets3D.dll") failed - This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

thanks!

7
c#dllcrash
I guess that the Widgets3D is a 3rd party library/component which depends upon other dlls/components. You'll be having the setup of this component, I believe. Can you run that setup, and then try running your app again? – Kirtan
no the Widgets3D is my own library. but this one depends on other thridparty libraries. (the ogre3D engine to be precise) all the dlls from ogre are there in the same directory. – clamp
Are they registered using regsvr32? – Kirtan
when i try to register them i get this error: "OgreMain.dll was loaded, but the DllRegisterServer entry point was not found. This file can not be registered." – clamp

7 Answers

2
votes

Reading that exception, here is the important part:

System.Runtime.InteropServices.COMException

That's not a .Net assembly. It's a COM dll, and it needs to be registered.

2
votes

Does the widgets3d need to be installed? Try Regsvr32 over it on the other machine.

Just open a command window and run:

Regsvr32.exe path-to-your-widgets3d.dll

and try again.

You're load library error seems to indicate that other associated dll's required by the 3d library are possibly not registered on the target machine. Try running the installer for the the 3d library on the machine.

Also check this post

1
votes

i checked with dependency walker and process monitor but couldnt find any missing DLLs.

There's no need of doing this. Just go to Start -> Run -> regsvr32 <path of Widgets3D.dll>\Widgets3D.dll -> Press Enter.

Done!

1
votes

Widgets3D.dll probably depends on the C++ runtime libraries. Grab the appropriate "Visual C++ Redistributable" for the compiler it was built with and run that on the target system. You can't download debug DLLs from Microsoft, so hopefully it was built in a release configuration.

1
votes

Aaah, DLL-hell I presume. It may be useful trying to unregister it and register it again. If it has recently been moved since last time it must be relocated first to be unregistered before being registered again. I have experienced this a lot using COM dlls.

Hope this helps.

1
votes

just in case you are interested. we found the solution to the problem to be a recent security patch for VC KB971090

uninstalling this patch and rebuilding the DLLs solved the issue.

there are quite a few topics on this: https://stackoverflow.com/search?q=KB971090

1
votes

Uninstalling is one way of dealing with the problem but if you have an ATL component that is vulnerable, you'll definitely want the security patch and make the necessary changes to your app to take advantage of the security fixes.

The way I dealt with this is to develop a workaround that allows the patch to be installed but still target the old versions of the DLLs when building. I've described this solution here.