Somebody says, “Your program is consuming 100% CPU” and hands you a debug session. Usually, this happens because one thread has gotten stuck in an infinite loop. And if you’re lucky it’s the type of infinite loop that’s easy to diagnose because it’s just one function that isn’t returning. (The more complicated types are where a function does some work and then returns, and then some of that work has a delayed effect that causes the function to run again, and so on.) Let’s assume we’re lucky because, well, debugging is an exercise in optimism.

The first step is to find the thread that is using all the CPU. That’s actually pretty easy with the help of the !runaway debugger extension.

0:011> !runaway
 User Mode Time
 Thread    Time
 192c      0 days 0:05:22.457
 1384      0 days 0:00:16.063
 14ac      0 days 0:00:08.392
 48c       0 days 0:00:03.955
 1db0      0 days 0:00:00.010
 1888      0 days 0:00:00.010
 1078      0 days 0:00:00.000
 1470      0 days 0:00:00.000
 1f84      0 days 0:00:00.000
 1d60      0 days 0:00:00.000
 1850      0 days 0:00:00.000
 134c      0 days 0:00:00.000
 19fc      0 days 0:00:00.000
 1b4       0 days 0:00:00.000

Wow, thread 0x192c has sure used a lot of CPU time, but that doesn’t mean that it’s the thread that is in a 100% CPU loop, because the CPU time is cumulative over the lifetime of the thread. Maybe that thread has a lot of CPU time because it’s been around the longest. What you need to do is resume execution for a little while, then break in again and see whose CPU time has increased.

0:011> g
^C
(1928.1d34): Break instruction exception - code 80000003 (first chance)
eax=7ffd9000 ebx=00000001 ecx=00000002 edx=00000003 esi=00000004 edi=00000005
eip=7c901230 esp=0124ffcc ebp=0124fff4 iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             efl=00000246
ntdll!DbgBreakPoint:
7c901230 cc               int     3
0:011> !runaway
 User Mode Time
 Thread    Time
 192c      0 days 0:05:23.679
 1384      0 days 0:00:16.063
 14ac      0 days 0:00:08.392
 48c       0 days 0:00:03.955
 1db0      0 days 0:00:00.010
 1888      0 days 0:00:00.010
 1078      0 days 0:00:00.000
 1470      0 days 0:00:00.000
 1ea4      0 days 0:00:00.000
 1d60      0 days 0:00:00.000
 1850      0 days 0:00:00.000
 134c      0 days 0:00:00.000
 19fc      0 days 0:00:00.000
 1b4       0 days 0:00:00.000

Aha, we see that thread 0x192c is the only one who gained any noticeable amount of CPU time. That’s probably the one that’s responsible for the 100% CPU usage.

0:011> ~~[192c]s
eax=00000000 ebx=77d5e581 ecx=0012daa0 edx=0000000c esi=01d18140 edi=00000000
eip=77d5e590 esp=0012da78 ebp=0012da88 iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
USER32!FindWindowA+0xf:
77d5e590 50               push    eax
ChildEBP RetAddr
0012da88 1000714b USER32!FindWindowA+0xf
0012dbc8 100061f3 ABC!CAlpha::FindTarget+0x27f
0012dbf4 603517e8 ABC!CBeta::TransferData+0x18a
0012dc28 10002d9d DEF!CGamma:TransferData+0xc
0012dc48 00505303 ABC!CBeta::BeginAsync+0x51
0012dc5c 0090a21a GHI!CPrintSession::Open+0x2a51
0012dd20 009099d8 GHI!CPrintSession::Init+0x252
0012e060 009097e6 GHI!CPrintOptions::GetSettings+0x24a
0012e0a4 0090973d GHI!CPrintOptions::OpenSettings+0x248
0012e130 00909664 GHI!CDocumentMenu::OnInvoke+0x24
...

Now this is where the magical “gu” command comes in. You type “gu” to run the current function until it returns. If you get another prompt back, then type “gu” again, to run that function until it returns. And so on, until you find the function that doesn’t return.

That’s the one with the infinite loop.

Now you can start investigating why that function is stuck.