Question

I’m trying to determine why a process is hanging and am learning about various tools such as Process Explorer, Process Monitor, and WinDbg.

Anyway, I’m trying to use WinDbg and after attaching to my process, the debugger says this:

(1e9c.1128): Break instruction exception - code 80000003 (first chance)
eax=7ffda000 ebx=00000000 ecx=00000000 edx=77c5c964 esi=00000000 edi=00000000
eip=77c18b2e esp=0543ff5c ebp=0543ff88 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!DbgBreakPoint:
77c18b2e cc              int     3

If I run !analyze -v, it displays this:

FAULTING_IP: 
ntdll!DbgBreakPoint+0
77c18b2e cc              int     3

I’m a software developer (VB.NET / C#) with no experience in this level of debugging, so I’m not sure what I’m doing, but it appears as though WinDbg is attaching to my process and then immediately breaking. Then, when I do an analyze it thinks the breakpoint (which it just set) is the problem with the application?

How am I supposed to use WinDbg to simply attach to a process and analyze it?

(Also, are there any good books/tutorial for getting started with this level of debugging and WinDbg?)

Answer 1

WinDbg is a user and kernel mode debugger, but on its own it doesn’t really understand managed code and as such the !analyze command is of limited use. If you want to debug managed applications using WinDbg, you need some way to make WinDbg understand the internal structures of managed code. There are a number of extension DLLs that enables this. The .NET framework ships with sos.dll and there are downloads such as psscor2.dll and sosex.dll.

SOS and PSSCOR2 provide more or less the same features while SOSEX adds new features for managed debugging. Help files for each of these are available from withing WinDbg. E.g. to get the help for SOS you can use the !sos.help command.

You have to load either SOS or PSSCOR2 and possibly SOSEX to debug a managed application with WinDbg. E.g. if you want to load SOS you use the load command like this

.loadby sos clr

This will load SOS from the location of the .NET runtime. Please note that the runtime is called mscorwks in .NET 2 and coreclr in Silverlight, so if you’re using either of these, you need to change the .loadby command accordingly.

WinDbg needs symbols to display additional information. This is particular important for unmanaged code. You can use the .symfix command to let WinDbg retrieve symbols as needed from Microsoft’s symbol server.

As your application is hanging, there’s a good chance that you’ll have one or more blocked threads. You can view managed threads using the !threads (or just !t) command. In .NET simple locks are implemented internally using a structure called SyncBlocks. You can view these using the !syncblk command. If you have loaded SOSEX the !dlk command can automatically detect deadlocks.

If you want more information, there are a couple of books and some blogs to read.

Books:

• Advanced .NET Debugging by Mario Hewardt. There’s also a book on native debugging from the same author.
• Debugging Microsoft .NET 2.0 Applications by John Robbins
• CLR via C# by Jeffrey Richter is an excellent introduction to the internals of the CLR.

Blogs:

• Tess’ blog is great. It has numerous tutorials and labs you can use to practice.
• Tom’s blog is also very useful.

Videos:

• I did a presentation on managed debugging at the Microsoft development center in Denmark. Videos are available on Channel p. Part 1 and part 2.