How many times have you been debugging .NET code that calls into a native DLL and ended up with this kind of error in the fusion log on a new machine?

BEGIN: Native image bind.
END: Incorrect function. (Exception from HRESULT: 0x00000001 (S_FALSE))

Usually this is because the (you guessed it) native image (DLL) failed to be retrieved by the .NET side. But what DLL is it looking for, and where? We have no context to work from.

If you use Process Monitor you can find out.

Using it in practice

The procedure isn’t too hard to follow, but like any good debugging, it’ll be an iterative process as you gain ground and understand your circumstances further.

In practice my method usually looks like this:

Run procmon with as few filters as possible (see below)
Run your application in the debugger, and wait until you get the exception for a failed assembly binding
Scan to the bottom of the procmon list and look for any DLLs that seem to be returning FILE NOT FOUND over and over again. This is because the DLL binding process evaluates every directory in your %PATH% environment variable if it can’t immediately find the asked-for dependency locally.
- This can frequently take several iterations as you track down every native dependency.
Once you find the DLL in question, fix it so it can be found (either add it to the %PATH%, include it with your application, or track down and kill the dependency on it somehow).

Useful filters

Process Monitor has an intimidating and clunky filter interface, but with enough exposure to it you’ll either get really good at it or just end up using the same filters every time for this task.

The settings I usually use are:

Include Process Name contains your application name (in my case, Testbed)
Exclude Path ends with pdb
- PDBs are frequently getting thrashed if you’re running inside a debugger. You don’t care.
Exclude Operation starts with Reg
- Nobody cares about registry access
The stock exclusions (for weird Win NT files, Process Monitor itself, etc.)