Why is System.Diagnostic.Debugger class compiled in retail?

There’s a good reason that methods on a “System.Diagnostics.Debugger” class are still compiled in retail builds, although this occasionally surprises folks. Here’s why…   Background: The System.Diagnostics.Debugger class provides some useful low-level debugging APIs such as: Debugger.Break() – causes the app to break under the debugger when executed. This is used for VB’s “Stop” statement…

0

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…

1

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 shouldn’t be using a lot of TLS slots in the first place,…

3

ICorPublish does not cross the 32/64 bit boundary

I mentioned earlier that ICorDebug does not cross the 32/64 boundary. If you want to debug a 32-bit managed app, you need to use a 32-bit version of the ICorDebug interfaces (or Mdbg). If you want to debug a 64-bit managed app, you need a 64-bit savy debugger. When you debug a 64-bit managed app in…

1

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 out…

3

Possible slowdowns under a debugger

Here’s a list of things that may slow down execution under a debugger. I’ve seen a few threads go by about ways that running under the debugger significantly slows down normal execution by more than 2x, and this is a collection of those items.  Background:Stepping through each statement (F10) runs significantly slower than just running…

2

How to start a console app in a new window, the parent’s window, or no window

The ProcessStartInfo.CreateNoWindow property says “Gets or sets a value indicating whether to start the process in a new window.” and later “true to start the process without creating a new window to contain it; otherwise, false. The default is false”  But that’s misleading and wrong because it’s meaning changes depending on what another property (UseShellExecute)…

4

Caveats about managed JIT-debugging

I received some questions in the mailbag about what Debugger.Launch actually does. Debugger.Launch the same mechanism as JIT-attach when you get an unhandled managed exception. Here are some random caveats about the jit-launch mechanism: Jit-launch calls kernel32!CreateProcess on the string set by the DbgManagedDebugger registry key to create a debugger process. Registry settings are described…

3

Resolving functions and func-eval syntax

I got a question about MDbg’s func-eval syntax, which brings up a nice point about function resolution: Is it possible to evaluate a function by specifying an instance variable instead of the fully qualified name of the class? f ex.get_StackTrace… is so much nicer than …System.Exception.get_StackTrace ex I really could have titled this post “Why…

0

#line hidden vs. DebuggerNonUserCode attribute

I got this great question from the mailbag:    “[W]hat is the relation between the “# line hidden” directive and the DebuggerNonUserCode attribute ? Are these the same ?” Short Answer:They’re both markings that library authors can put in their source code to mark certain portions as “hidden” to the end-user while debugging. In both cases,…

1