I have a 32 bit .Net application winform that invokes a C++ dll. We package the app into an installer and it installs and runs fine on at least 20 or so machines. The app was originally developed and runs fine on a Win 7 x64 machine (mine).
However when I run it on my bosses desktop (Win 7 x64) the application will not launch.
oh yeah…
When I try to launch the application I get a JIT dialog with
System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
When I run depends on the exe on the bosses machine it says that app exe is x86 but that all the dependent dll at x64 and flags it as an error. When I run depends on the app on my machine the exe and dll are all marked x86.
How could this change between machines? The installer is just unpacking and copying in the normal way and works fine on plenty of other x64 machines…
naturally it only breaks on his machine which is two hours away and we have a trade show coming up. sigh.
very confused…
================= solved ==================
So we fixed it. Finding the missing the dll was a bit tricky.
First of all we goofed and we ran the wrong version of depends for an x64 box. So it was incorrectly reporting that the app was looking for x64 dll. If we had run the correct version I think we would have caught the issue sooner.
What solved it for us was looking at the log of Process Monitor from System Internals. It logs every file access and registry read. The log quickly showed a failed read on a Direct X 11 dll.
It turns out that a previous installer from some other app had installed some of the DX11 dll. That fooled our installer, and it skipped the DirectX 11 step so we had a missing dll.
Thanks for the help guys!
It is a simple “file not found” kind of error, but with the very awkward behavior that it doesn’t tell you what DLL could not be found. Which might be the C++ DLL but also any implicit DLL dependencies it might have. Like the runtime support DLLs, very commonly missed, you can deploy them with the vcredist installer. Or deploying the Debug build of the DLL, that can’t work.
Getting a decent diagnostic requires turning on loader snaps and a debugger. Invariably hard to do on a machine that doesn’t have tools installed. The SysInternals’ ProcMon utility is an excellent alternative, you’ll see the program searching for the DLL. Albeit that you’ll drown in the amount of trace data it generates. Work from the bottom of the trace backwards.