Partager via

The debugger is not just an extension to BCL + Reflection

  • Article

Don't have your non-debugger app use the debugging services just to get some cool functionality.

The managed debugging services are not just another library that picks up where BCL/ Reflection left off.

 

The BCL + reflection provides some basic ability to inspect your own process, including:

  1. getting a current thread's stacktrace, including names of each function on the stack.
  2. looking up a method by string name at runtime.
  3. dynamically invoking methods.
  4. enumerating types within an assembly.

The managed debugging services (eg, ICorDebug, MDbg) provide some very cool additional functionality along these lines, including:

  1. The ability to lookup local variables by name, and get and set them.
  2. The ability to get source filenames for functions.
  3. Sniffing interesting events such as exceptions.
  4. The ability to change the current instruction pointer within a function
  5. The ability to enumerate all threads, modules, assemblies, and appdomains within a process.

 

Every so often, somebody wants to add something like the above functionality to their app, finds that BCL/Reflection/etc doesn't do it, and then wants to pursue it via the debugging APIs.

Don't.

 

Specifically, the debugging APIs are for diagnostic tools. Don't use the debugging APIs for non-diagnostic production behavior.

Here are some reasons why you shouldn't use the debugging APIs for non-debugger functionality in production cases :

  1. It may break in optimized code. That local that you're looking for may get optimized out. That function caller your sniffing for may have been inlined. That generic parameter you want to find may get code-folded away.
  2. A process can't debug itself. So you at least need a 2nd process to serve as a debugger. Now you need to communicate between 2 processes. That has some complexities, including bridging the gap between ICorDebugValue and System.Object.
  3. Only 1 debugger can be attached to a process. So if your app spins up a debugger to attach to itself, you couldn't spin up a "real" debugger (like VS) to debug your app.
  4. Running under a debugger can change performance characteristics.  PSA- Pinvokes may be 100x slower under the debugger 
  5. It creates a new versioning boundary. And the debugger versioning story is different than the BCL's, and so an app using the debugging services on itself would get sucked into the worst of both worlds.
  6. And it just adds extra complexity. You immediately add a 2nd process, at least 3 more threads, another versioning boundary, and a lot more moving parts...

 

Same reasoning applies for other tool APIs like the profiler.

Now that said, what are good uses of the debugger APIs?

  1. Writing debuggers.
  2. Writing diagnostic tools (like something that takes a stack trace of all threads) . While you're at it, check out the "Building Diagnostic Tools for .Net forum". You can view these tools as highly-specialized debuggers.

Comments

  • Anonymous
    November 06, 2007
    " That's ridiculous, I would never do that " you think. But there's a certain class