title: Writing .NET interop debugger
body: <p>I'm developing a user-mode (Ring3) code-level debugger. It also should support native (x86) debugging of the .NET executables. Basically, I need following:</p>
  
  <p>1) .NET loads some modules in the stealth mode, without LOAD_DLL_DEBUG_EVENT, and frequently even without the possibility to get the name of the executable. I need a notification;</p>
  
  <p>2) I'd also like to get a notification each time JIT compiler compiles a method;</p>
  
  <p>3) For the given CIL method, I need the addresses of the corresponding native CPU commands;</p>
  
  <p>4) Stack walk (decoding of managed stack frames) would be also appreciated.</p>
  
  <p>(Of course, more questions will come later). The solutions must be independent of the .NET version. There is a .NET debugging API from Microsoft which solves the problems 1 (partially), 3 and 4, and a .NET profiling API that solves 2.</p>
  
  <p>Unfortunately, my debugger and .NET APIs in the interop mode just don't fit together. I already have a reliable and <em>fast</em> debugging engine with breakpoints, memory management and so on. My program is a streamlined single-thread application. In a step-by-step mode it can trace, analyse and protocol the debugged code at a speed of 500.000 commands per second.</p>
  
  <p>Microsoft's solution is quite different. .NET debugger is a smart beast; if I were requested to write a managed debugger, it would be my first choice. It never suspends the Debuggee - only pauses .NET execution - and therefore may call mscoree and co., which have full access to the internal structures, in the context of the Debuggee. To communicate, it creates one additional thread in the Debuggee and another in Debugger. (And Continue() for unhandled exception callback must be sent from yet another thread!) </p>
  
  <p>For me this means heavy changes to my code, endless critical sections, semaphores, shared memory and deadlocks. I can't use memory breakpoints. If Debuggee goes wild, it may influence the helper DLL. Execution in the context of the Debuggee may also mean too strong influence on the debugger application.</p>
  
  <p>Is there a non-intrusive, version-independent way to solve the listed problems?</p>
  
  <p>Olly</p>