Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » Troubleshooting   (RSS)
Thursday, November 01, 2007 1:34 PM

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
Posted by jmstall | 0 Comments
Friday, October 12, 2007 1:54 AM

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
Posted by jmstall | 1 Comments
Tuesday, September 25, 2007 8:10 PM

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
Posted by jmstall | 3 Comments
Monday, August 27, 2007 8:00 PM

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
Posted by jmstall | 1 Comments
Wednesday, January 10, 2007 1:27 AM

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
Posted by jmstall | 2 Comments
Monday, October 23, 2006 11:56 AM

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
Posted by jmstall | 2 Comments
Filed under:
Thursday, September 28, 2006 3:06 AM

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
Posted by jmstall | 4 Comments
Filed under: ,
Monday, July 24, 2006 11:12 AM

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
Posted by jmstall | 3 Comments
Filed under:
Friday, July 21, 2006 10:43 AM

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 ...
Posted by jmstall | 0 Comments
Wednesday, July 12, 2006 7:03 PM

#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
Posted by jmstall | 1 Comments
Filed under:
Sunday, July 09, 2006 1:06 PM

Conventions for passing the arguments to a process

A process's main() function gets an array of strings for the command line args. This is string[] in C#, or {int argc, char** argv} in C/C++. But there are some different conventions for how the parent app passes those strings in. If you execute a program
Posted by jmstall | 4 Comments
Filed under:
Monday, July 03, 2006 2:16 PM

Managed vs. Native debugging APIs

FxCop has a great rule ( UseManagedEquivalentsOfWin32Api ) to tell you about managed APIs that exist instead of trying to pinvoke out. I'm writing a native debugger in managed code (more on this later), and FxCop was telling me to use the managed debugging
Posted by jmstall | 6 Comments
Thursday, June 29, 2006 11:05 AM

Debugger won't properly evaluate C#s base keyword

Public Service Announcement: You may have noticed that trying to evaluate members using C#'s 'base' keyword in the debugger still calls the derived members. (The 'base' keyword lets you access base class member implementations from within a derived class,
Posted by jmstall | 8 Comments
Wednesday, June 28, 2006 10:54 AM

How to build Mdbg apps

I often publish little samples in this blog based off MDbg (which generally show off the debugging services in some way; such as app to convert Pdb-->XML , or this harness to print all exceptions in an app ). I generally call these apps "harnesses"
Posted by jmstall | 1 Comments
Filed under: ,
Wednesday, May 24, 2006 3:23 PM

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
Posted by jmstall | 6 Comments
More Posts Next page »
 
Page view tracker