Sometimes when you start an executable named say xxx.exe on Windows Desktop a modal pop-up may appear:
As often happens, this error message is incomplete, misleading and unhelpful. What is missing is not xxx.exe, which likely is a freestanding application with no installer.
If this error occurs during a debug session inside Microsoft Visual Studio, you may examine the Debug tab of the Output windows, just to find the laconic message:
The program ' xxx.exe' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
which is not correct, but still incomplete and unhelpful.
The way to know which DLL is missing is to use GFlags to set a particular Windows feature – no need to install the DependencyWalker utility (mentioned in many places on the interweb). gflags.exe is the Global Flags Editor, an utility that enables and disables advanced debugging, diagnostic, and troubleshooting features. Get it from here, look for the “Standalone Debugging Tools for Windows (WinDbg)” section.
Once you got that installed, you may wonder where it did install – well, on my 64-bit Windows it ends up in C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\.
To set the option we need, do this in a Command Prompt:
"C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\gflags.exe" /i xxx.exe +sls
Note 0: the option is sls, an acronym that stands for Show Loader Snaps – a flag that captures detailed information about the loading and unloading of executable images and their supporting library modules and displays the data in the kernel debugger console
Note 1: Replace xxx.exe with the name of your executable without the path.
Note 2: the UAC confirmation should come up; if not, launch the command from a Command Prompt window that you started by right-mouse-button clicking on the Command promp icon and selecting the “Run as Administrator” context menu command.
If you then launch again the xxx.exe debug session inside Microsoft Visual Studio, and examine the Debug tab of the Output windows after the pop up comes, you’ll find an extensive diagnostic that should allow you to identify the missing DLL:
Another option is to directly launch the executable by double-clicking on it. In this case you need to access the kernel debugger console, which is most easily done via the excellent sysinternals DebugView utility.
Anyway the diagnostic you get is complete and leads in the right direction, but unhelpful because difficult to interpret. Here are some tips to help yourself:
- read the Dynamic-Link Library Search Order for Desktop Applications documentation
- look for DLL names immediately before the lines with the messages “LdrpSearchPath – RETURN: Status: 0xc0000135″
Good luck !
Post Scriptum 1: In practice, the easiest thing to do once you find the missing DLLs, is copying them to the executable location. The second option is to change the working directory (in Visual Studio, do that in Project properties, Configuration Properties, Debugging, Working Directory (be careful to set that for the Configuration / Platform combination you’re actually trying to debug !)
Post Scriptum 2: I’d suggest disabling the sls option when you’re done.