Now this dialog contains a lot of information, but to be honest it kind of overwhelmed me and didn’t really give me any good feeling about what had actually gone wrong. Obviously it was related in some way to MDbg, the managed debugger used by Reflector. So I pulled down the Managed Debugger Sample and the Deblector source and set about trying to figure what had really gone wrong. Anyway I tracked this dialog down to the following piece of code

private void DebuggerErrorEventHandler(Object sender, CorDebuggerErrorEventArgs e)
{
    Trace.WriteLine("ManagedCallback::DebuggerError");
    if (InternalHandleRawMode(ManagedCallbackType.OnDebuggerError, e))
        return;
 
    e.Continue = false;
    InternalSignalRuntimeIsStopped(null, new DebuggerErrorStopReason());
    Debug.Assert(false, "Critical failures -- received DebuggerError callback.");
}

And examining the CorDebuggerErrorEventArgs object allowed my to actually find the error code 0x80131C30, this wasn’t a number I was familiar with, so I had to Google it, which led me to the fact that ICorPublish does not cross the 32/64 bit boundary. Ah, now were getting somewhere I thought, the .net flags in the header of the target I was trying to debug was set as follows

But for some (presumably good) reason, Reflector’s binary is set to ’32bit required’. As I was running on Vista x64 my target was being run as a 64 bit image, but Relfector + Deblector + the ICorPublish interface they created were running as 32 bit.

The solution to my problem, well I simply ticked the ’32bit required’ tick box in the flags section of the .net header for the target I wished to debug and everything started working.