WinDBG Beginner Sessions: Part 1 - Hang

/

We got through the exhibition post, but now it’s time to get serious. I figured the quickest way to get going here is to go through Tess Ferrandez’s series of debugging labs. I’ve heard that these are actually some of the best tutorials and hands-on experience you can get with WinDBG, so I’m excited to get started.

Of course, one of the reasons I’ve waited so long to do this is due to the labs having the demo site setup in IIS. I’m definitely not the best at deploying and configuring IIS, so instead here I used IIS Express. This seems to work quite well so I’ll be sticking with that throughout the labs. So let’s get started with lab 1 – the hang.

The first part of the lab was to recreate the issue. Since TinyGet appears to be dead, I just manually hit refresh on the browser windows. While that was going I ran the following command to get a dump file while going to the page in question:

.\procdump.exe -n 2 iisexpress.exe

Unfortunately, I forgot to generate the dump using the -ma switch, so no memory information will be available. I swear to remember to use this from now on!

Based on the suggestion of the lab, running the ~* kb 2000 command. Ok, so after some searches, I'm still not exactly sure what this command is saying, but here's a shot in the dark:

  • ~* will execute the following command towards all threads.
  • kb will print out the native (non-.NET) call stack.
  • 2000…well, here’s where I'm lost. If anyone out there happens to know, please let me know.

And the results of this is the below. Let's see, it appears that most of these threads are just in a waiting state.

clip_image001

Oh, but after some scrolling, thread 28 has something interesting.

clip_image002

Let's take a closer look at this thread and switch the debugger to it with the ~28s command. Then, we'll check out the managed call stack with the !ClrStack command.

clip_image003

See anything here? Talk about interesting, this thread is sleeping! Well, that's about all the commands I can think to run for this. Tess' lab suggests to run the !syncblk command, however, when I ran it I get the below.

clip_image004

Perhaps that's due to the fact that it isn't a full dump? Regardless, I think we have more than enough information from our dump here. Now, let's check the code that the !ClrStack command has given us. It's telling us to check out the DataLayer.GetFeaturedProducts() method, so let's take a look.

And look what we have.

clip_image005

Of course, looking back at the actual walkthrough of the lab, I missed a bit without the !synblk command. I’m definitely going to redo this with an actual full dump to see if I can find the thread that is being blocked and the thread that’s doing the blocking. I got a bit lucky on this one, I think.