How can I learn WinDbg? (re: seemingly simple hung process)

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.

Anyways, 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

Tess Ferrandez' blog is a fantastic resource for .NET WinDbg material:

If broken it is, fix it you should

Although many of her articles target IIS/ASP.NET worker process crash, hangs and leaks, most of the techniques can be applied to all sorts of scenarios.

Answer 2

Advanced Windows Debugging would be a good start.

When Windbg attaches to a process, it injects a thread that calls DbgBreakPoint. That is what you are seeing. You can use ~ to see running threads and then ~n to switch to a different thread. k will give you a stack trace of the current thread, which should give you some idea of the hang.

Answer 3

The int 3 instruction (cc in binary) is one of the ways debuggers set break points in an application. This instruction generates an interrupt which pauses the execution of the program and gives the debugger an opportunity to react to this interrupt. You just need to choose to continue execution until you reach where your program is hanging.

Answer 4

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 provides 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 mscorwks

This will load SOS from the location of the .NET runtime. Please note that the runtime is called clr in .NET 4 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 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.