I had a late one last night trying to track down why a C++ dll wouldn't load in my WPF app when loaded on a tablet running Windows 7. The app would start up, but when it got to a chunck of code which needed the Touchless Vision library (a wonderful library, by the way), I would get a

Problem Signature 09: System.IO.FileNotFoundException

exception, and the library would not load.

Because I was on a tablet, I figured the device had been kneecapped in some why, so that sent me down a bunch of different (wrong) paths having to do with Direct Show. But the obvious thing I wanted to do was to simply name that missing DLL. My first searches pointed me to Dependency Walker. But, unfortunately, it turns out that it cannot profile on Windows 7, since the code attempts to inject its own DLL into the application to profile, and Windows 7 is (fortunately) stopping that from happening. The error I would get is

00:00:00.359: STATUS_STACK_BUFFER_OVERRUN encountered
00:00:00.375: Entrypoint reached. All implicit modules have been loaded.

So, it would die before it got anywhere near my loading of the DLL.

What I did find was the the Event View's Application Log was logging a Windows Error Reporting event with a pointer to a WER file that reported on the error:

C:\Users\user\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_app.exe_8d71ed22febf18ad4a832d42e7d230eecadf4384_039395ef

Which has a bunch of lines such as:

LoadedModule[1]=C:\Windows\SYSTEM32\ntdll.dll
LoadedModule[2]=C:\Windows\SYSTEM32\MSCOREE.DLL
LoadedModule[3]=C:\Windows\system32\KERNEL32.dll
LoadedModule[4]=C:\Windows\system32\KERNELBASE.dll

Now that file is nice enough to list all the DLLs that were loaded up until the exception. But it still did not list the DLL that it could not find. But I know that the app loaded on my development machine, so all I had to do was get past the point in my program where it crashes on the Tablet, and then crash it on my dev machine, causing an event in Event Viewer. A simple

    int a = 0;
    int b = 1 / a;

was enough to get the code to crash right after my first call to the DLL. Now, when I go to the WER file on my dev machine, I get the complete list of DLLs loaded right up to and past the point where the tablet failed. Compare the two files, and viola: Since I was running the debug version of the application on the tablet, I was loading the debug version of the C++ library, which, by the way, will need the MSVC100D.dll to run. Argh, how many times has that bit me in the past 15 years. Of course, since I haven't been doing MFC for about 10 years, I had completely forgot about that.

Time to catch up on some sleep.