How can I tell if I'm interop-debugging?

Sometimes I'm debugging and I want to make sure that I'm actually interop-debugging and not accidentally managed-only debugging. (Now that interop-debugging is so much faster and more stable in whidbey, it's easy to forget you're doing it).

One way is to just look at the callstack and see if there are any native frames. However, that may not always work. Maybe there isn't any native code on the stack, which could be the case if you're interop-debugging a C# app. Or maybe the debugger is filtering out native frames as external code because you don't have symbols for them.

So the technique I prefer is to just look at the modules window. If you're interop-debugging, you'll see all the native modules too, particularly kernel32.dll (should always be loaded). There's also mscorwks.dll (the dll that implements most of the runtime), mscorjit.dll (where the CLR's jit is implemented), and mscoree.dll (the dll that bootstraps the runtime). If you're managed-only debugging, you won't see these dlls.  It's quick, it's easy, it's non-invasive, and it doesn't matter what state your debuggee is in (eg, it will work even if no threads are in managed code).

Comments

• Anonymous
  February 22, 2007
  There is not always a 1:1 correlation between Managed modules and native modules. For example, Sometimes

• Anonymous
  October 11, 2007
  This is a moot point for pure C# apps, but what if you're writing in MC++ (or some other 'mixed' language)