Mike Stall's .NET Debugging Blog

Notes on Managed Debugging, ICorDebug, and random .NET stuff

Browse by Tags

Tagged Content List
  • Blog Post: Breaking changes in ICorDebug from 1.1 to 2.0.

    Here are some random notes about specific ICorDebug breaking changes between .NET v1.1 (Everett) and .NET 2.0 (Whidbey). (I came across these as I was cleaning out old documents in preparation for my upcoming move). This would have been more timely 2 years ago, but better late than never. This can be...
  • Blog Post: Things that what work in Native-debugging that don't work in Interop-debugging.

    Interop-debugging (mixed-mode) is managed + native debugging combined. Well, sort of. Native and managed debugging have very different paradigms. Native debugging tends to own the whole process, while managed debugging tends to require control of the whole process while only exposing a managed view to...
  • Blog Post: How to tell if a function is managed code?

    This is a moot point for pure C# apps, but what if you're writing in MC++ (or some other 'mixed' language) and you want to know if a function is getting compiled as managed or native code? You can try and inspect the source and infer from the language rules. Eg, in MC++, look for #pragma managed / #pragma...
  • Blog Post: Interop-debugging fails when using more than 63 TLS slots

    Here's a Public Service Announcement: Interop-debugging may hang if the debuggee uses more than 63 native Thread Local-Storage slots and then loads the CLR. KB939969 has more details, including three workarounds. This is fixed in Orcas, so only applies to pre-Orcas runtimes (like .NET 2.0). You really...
  • Blog Post: Tips for writing an Interop Debugger

    I've had a growing number of people inquire about how to write an interop-debugger with ICorDebug. I strongly advise anybody considering writing an interop-debugger to reconsider for reasons listed here . However, for those who can not be dissuaded, and promise to do something really really cool, here...
  • Blog Post: You don't want to write an interop debugger.

    I've had a growing number of people inquire about how to write an interop-debugger with ICorDebug. My goal here is to discourage you from doing that. (This reminds me of one of my college classes. On day one, the acting-Prof launched into a great sermon "Why you should drop this class now". It turned...
  • Blog Post: Beware of the Vectored Exception Handler and managed code

    A vectored exception handler (see kernel32!AddVectoredExceptionHandler ) lets you add to a global list of filters that get executed by the OS when a native exception is thrown. More specifically, this list is executed by the OS before the filters in the FS:0 chain are executed. This means you can get...
  • Blog Post: Why can't you detach in interop-debugging?

    Matt Pietrek noticed you can't detach while interop-debugging (aka " mixed-mode ") in VS. Short answer: this is a limitation of the CLR / ICorDebug. Longer answer follows... Some history : Interop-debugging is managed + native debugging simultaneously in a single debugger. This means it's the lowest...
  • Blog Post: You can't do Edit-and-Continue with Interop-debugging on.

    Somebody asked on the forums about Edit-and-Continue (EnC) in mixed mode . You can't use managed EnC with mixed-mode ( interop ) debugging enabled. This is a limitation of the CLR Debugging Services. Both Interop-debugging and EnC are complicated features; combining them would be a huge test-matrix and...
  • Blog Post: F5 vs. Ctrl-F5

    In VS, F5 will launch your application under the debugger. Under the debugger, you'll hit breakpoints, be able to edit-and-continue, and do all the debugger things you know and love. Ctrl+F5 will launch your application outside of the debugger. This is like launching your app from the "start...
  • Blog Post: Out-of-band events and Mixed-mode debugging

    Interop-debugging splits all debug events into "In-band (IB) " and "Out-of-band (OOB)". Inband events are the good ones: at an inband event, the debuggee is stopped and you can use the rest of the ICorDebug API normally to do inspection and other things like setup funcevals (aka property-evaluation)...
  • Blog Post: 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...
  • Blog Post: Auto-attach to child process is not supported in managed-debugging

    Native-only debugging allows you to debug child processes. In other words, you can debug process A, and then if A spawns process B, your debugger can automatically start debugging process B. This eliminates the need to manually attach to process B, and potentially losing the ability to debug B at startup...
  • Blog Post: You can't get a mixed-mode callstack from inprocess.

    You can't get a full-mixed (both managed+ native) stack of a thread within your own process. You can get a native-only stack from function like DbgHelp!StackWalk64 (which is what this article on Codeproject does) to get the native callstack of a native thread. However, the native stackwalker gets lost...
  • Blog Post: 64-bit CLR doesn't support Interop debugging

    Just FYI, we don't support interop-debugging on 64-bit CLR (or on win9x). You can still do 32-bit interop-debugging within the WOW on 64-bit. (You also can't do managed-debugging locally across the WOW boundary. You can set up a remote debugging channel to yourself across the WOW boundary.) The reason...
  • Blog Post: Interop-stepping is 400 times faster in Whidbey over Everett

    We’ve made Interop-debugging (aka “mixed-mode debugging”) much faster and more stable in Whidbey (VS8) than it was in Everett (VS7). Interop-stepping was very slow in Everett. One way to measure this is to step over a line like this: int x = GetCount(dwStartMS) + (a+b+c)+(a+b+c)+(a+b+c)+(a+b+c)+(a...
  • Blog Post: Why you can’t debug mscorwks when interop-debugging

    Interop (aka mixed-mode) debugging allows you to debug both the managed and unmanaged portions of your app. However, even when interop-debugging, you still can’t debug the core runtime itself (most of mscorwks.dll). I briefly here that the key danger is deadlocking. I want to explain more fully in this...
  • Blog Post: Hardmode vs. Softmode

    User-mode debugging can be split into 2 models: Hardmode and Softmode. Hardmode means using the native debugging APIs. This means all threads are stopped by the OS at each debug event and there’s no helper-thread . The debugger does not need to run any code in the debuggee’s process. Softmode means not...
  • Blog Post: What is Interop-Debugging?

    (This is an excerpt from an internal document I wrote explaining what is Interop-Debugging (aka Mixed Mode) and how does it work under the covers) General Debugging background. When a process is being debugged, it generates debug-events which a debugger can listen and respond to. These events include...
  • Blog Post: Implications of using a helper thread for debugging

    What it means? I mentioned in a previous post ( http://blogs.msdn.com/jmstall/archive/2004/10/10/240452.aspx ) that the CLR debugging services is an “in-process model” which means it has a helper thread running in the same process as the EE which provides debugging information at runtime. Contrast this...
  • Blog Post: Why is managed debugging different than native-debugging?

    People ask “why can’t a native debugger debug managed code?”. The reason is that the CLR provides a lot of cool services beyond what you get in a typical native C++ app, such as: running on a Virtual Machine / JITing, Dynamic class layout, the type-system, garbage-collection, reflection-emit, and more...
Page 1 of 1 (21 items)