If broken it is, fix it you should

Using the powers of the debugger to solve the problems of the world - and a bag of chips    by Tess Ferrandez, ASP.NET Escalation Engineer (Microsoft)
Tess Ferrandez
I work as a developer evangelist at Microsoft, and my job is to help developers make the most of their skills on the MS stack.

In this blog I share tips on anything from debugging and troubleshooting to development on platforms like Windows, Web, Windows Phone and Kinect. And also some random tidbits about computing and my life at MS.


Thanks for visiting my blog

@TessFerrandez

Options
Search this blog
Tags
Archive
Archives

Things to ignore when debugging an ASP.NET Hang - Update for .NET 2.0

MSDN Blogs > If broken it is, fix it you should > Things to ignore when debugging an ASP.NET Hang - Update for .NET 2.0

Things to ignore when debugging an ASP.NET Hang - Update for .NET 2.0

2 Apr 2007 8:19 AM
  • Comments 12

I often get questions like "what is this thread doing?". A lot of the time it is about threads that are essential to the process but completely unrelated to the problem at hand. 

A while back, in the beginnings of this blog, I wrote a post about what threads you can ignore so you can focus on what is important, and according to the blog stats, it turned out to be one of the most popular posts.   Since then a lot of people have wanted to see an update for 2.0.

Rather than repeating the whole post I'll just show the ones that have a new look and feel... and if you are interested in finding out a bit more about what they are, check out the old post

CLR Threads

Idle CLR Worker Thread

16 Id: efc.a00 Suspend: 1 Teb: fff88000 Unfrozen
ChildEBP RetAddr Args to Child 
0219fc84 7d4d8c56 00000228 00000000 0219fcc8 ntdll!ZwWaitForSingleObject+0x15
0219fcf4 79e718fd 00000228 00009c40 00000000 kernel32!WaitForSingleObjectEx+0xac
0219fd38 79e718c6 00000228 00009c40 00000000 mscorwks!PEImage::LoadImage+0x199
0219fd88 79e7187c 00009c40 00000000 00000000 mscorwks!CLREvent::WaitEx+0x117
0219fd98 79f5e51b 00009c40 00000000 00000000 mscorwks!CLREvent::Wait+0x17
0219fe18 79f8b1c5 001880e0 00009c40 00000000 mscorwks!ThreadpoolMgr::SafeWait+0x73
0219fe94 79f7997f 00000000 00000000 00000000 mscorwks!ThreadpoolMgr::WorkerThreadStart+0xf5
0219ffb8 7d4dfff1 0019c440 00000000 00000000 mscorwks!ThreadpoolMgr::intermediateThreadProc+0x49
0219ffec 00000000 79f79939 0019c440 00000000 kernel32!BaseThreadStart+0x34

 

Idle CLR Completion Port/IO Thread

14 Id: efc.11c8 Suspend: 1 Teb: fff8e000 Unfrozen
ChildEBP RetAddr Args to Child 
0209fe7c 7d50664c 00000234 0209fee8 0209fec0 ntdll!NtRemoveIoCompletion+0x15
0209fea8 79f795de 00000234 0209feec 0209fee8 kernel32!GetQueuedCompletionStatus+0x29
0209ff14 79f7997f 00000000 00000000 00000000 mscorwks!ThreadpoolMgr::CompletionPortThreadStart+0x11a
0209ffb8 7d4dfff1 0019c440 00000000 00000000 mscorwks!ThreadpoolMgr::intermediateThreadProc+0x49
0209ffec 00000000 79f79939 0019c440 00000000 kernel32!BaseThreadStart+0x34

 

Idle CLR Gate Thread

15 Id: efc.1534 Suspend: 1 Teb: fff8b000 Unfrozen
ChildEBP RetAddr Args to Child 
0211fe18 7d4d0ec5 00000000 0211fe58 00000000 ntdll!ZwDelayExecution+0x15
0211fe80 79f56b45 000001f4 00000000 fcffff56 kernel32!SleepEx+0x68
0211feb4 79f56b15 000001f4 00000000 fcffff0a mscorwks!EESleepEx+0xa3
0211fee8 79f405ed 000001f4 00000000 79f569e7 mscorwks!__DangerousSwitchToThread+0x70
0211fef4 79f569e7 000001f4 9e2c9368 000003f4 mscorwks!__SwitchToThread+0xb
0211ffb8 7d4dfff1 00000000 00000000 00000000 mscorwks!ThreadpoolMgr::GateThreadStart+0xa1
0211ffec 00000000 79f56952 00000000 00000000 kernel32!BaseThreadStart+0x34

 

Idle GC Thread

18 Id: efc.12b8 Suspend: 1 Teb: fff82000 Unfrozen
ChildEBP RetAddr Args to Child 
0257fe6c 7d4d8c56 000002dc 00000000 00000000 ntdll!ZwWaitForSingleObject+0x15
0257fedc 79e718fd 000002dc ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xac
0257ff20 79e718c6 000002dc ffffffff 00000000 mscorwks!PEImage::LoadImage+0x199
0257ff70 79e7187c ffffffff 00000000 00000000 mscorwks!CLREvent::WaitEx+0x117
0257ff80 7a0d6f16 ffffffff 00000000 00000000 mscorwks!CLREvent::Wait+0x17
0257ffa8 7a0d722e 00000000 fcb9fe5a 0257ffec mscorwks!SVR::gc_heap::gc_thread_function+0x2f
0257ffb8 7d4dfff1 001b20e8 00000000 00000000 mscorwks!SVR::gc_heap::gc_thread_stub+0x9b
0257ffec 00000000 7a0d7192 001b20e8 00000000 kernel32!BaseThreadStart+0x34

 

Idle Finalizer Thread

20 Id: efc.132c Suspend: 1 Teb: fff7c000 Unfrozen
ChildEBP RetAddr Args to Child 
0267fcd0 7d4e1cda 00000002 0267fd1c 00000001 ntdll!NtWaitForMultipleObjects+0x15
0267fd78 7d4e3e16 00000002 7a398698 00000000 kernel32!WaitForMultipleObjectsEx+0x11a
0267fd94 7a0849d8 00000002 7a398698 00000000 kernel32!WaitForMultipleObjects+0x18
0267fdb4 7a085307 001b0c60 0267fe6c 0267feb4 mscorwks!SVR::WaitForFinalizerEvent+0x7a
0267fdc8 79ed890c 0267feb4 00000000 00000001 mscorwks!SVR::GCHeap::FinalizerThreadWorker+0x75
0267fdd8 79ed88aa 0267feb4 0267fe60 79f54f64 mscorwks!Thread::UserResumeThread+0xfb
0267fe6c 79ed87d1 0267feb4 fc89ff4a 00000000 mscorwks!Thread::DoADCallBack+0x355
0267fea8 79ed976c 0267feb4 00000000 001cad20 mscorwks!Thread::DoADCallBack+0x541
0267fed0 79ed9737 7a085292 00000008 7a0854b0 mscorwks!ManagedThreadBase_NoADTransition+0x32
0267fedc 7a0854b0 7a085292 fc89fef6 00000000 mscorwks!ManagedThreadBase::FinalizerBase+0xb
0267ff14 79ed8d16 00000000 00000000 00000000 mscorwks!SVR::GCHeap::FinalizerThreadStart+0xbb
0267ffb8 7d4dfff1 001b0ca8 00000000 00000000 mscorwks!Thread::intermediateThreadProc+0x49
0267ffec 00000000 79ed8cd0 001b0ca8 00000000 kernel32!BaseThreadStart+0x34

 

Idle CLR Debugger Thread

17 Id: efc.1964 Suspend: 1 Teb: fff85000 Unfrozen
ChildEBP RetAddr Args to Child 
022cfe34 7d4e1cda 00000003 022cfe80 00000001 ntdll!NtWaitForMultipleObjects+0x15
022cfedc 7d4e3e16 00000003 022cff20 00000000 kernel32!WaitForMultipleObjectsEx+0x11a
022cfef8 79f0cb1e 00000003 022cff20 00000000 kernel32!WaitForMultipleObjects+0x18
022cff58 79f0ca7b fcc2fe6a 00000000 00000000 mscorwks!DebuggerRCThread::MainLoop+0xcf
022cff88 79f0c9be fcc2fe5a 00000000 00000000 mscorwks!DebuggerRCThread::ThreadProc+0xca
022cffb8 7d4dfff1 00000000 00000000 00000000 mscorwks!DebuggerRCThread::ThreadProcStatic+0x82
022cffec 00000000 79f0c978 00000000 00000000 kernel32!BaseThreadStart+0x34

Idle Timer Thread 

22 Id: efc.136c Suspend: 1 Teb: fff76000 Unfrozen
ChildEBP RetAddr Args to Child 
0284fecc 7d4d0ec5 00000001 0284ff0c 00000000 ntdll!ZwDelayExecution+0x15
0284ff34 79f667c7 00002710 00000001 0284ffa4 kernel32!SleepEx+0x68
0284ffb0 79f66758 00000000 7d4dfff1 0219e75c mscorwks!ThreadpoolMgr::TimerThreadFire+0x6d
0284ffb8 7d4dfff1 0219e75c 00000000 00000000 mscorwks!ThreadpoolMgr::TimerThreadStart+0x54
0284ffec 00000000 79f66702 0219e75c 00000000 kernel32!BaseThreadStart+0x34

Idle Appdomain Unload Thread 

21 Id: efc.12d8 Suspend: 1 Teb: fff79000 Unfrozen
ChildEBP RetAddr Args to Child 
0275fcbc 7d4d8c56 000002d0 00000000 00000000 ntdll!ZwWaitForSingleObject+0x15
0275fd2c 79e718fd 000002d0 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xac
0275fd70 79e718c6 000002d0 ffffffff 00000000 mscorwks!PEImage::LoadImage+0x199
0275fdc0 79e7187c ffffffff 00000000 00000000 mscorwks!CLREvent::WaitEx+0x117
0275fdd0 79f78d81 ffffffff 00000000 00000000 mscorwks!CLREvent::Wait+0x17
0275fe94 79ed8d16 001babd0 00000000 00000000 mscorwks!AppDomain::ADUnloadThreadStart+0x2fb
0275ffb8 7d4dfff1 001b8670 00000000 00000000 mscorwks!Thread::intermediateThreadProc+0x49
0275ffec 00000000 79ed8cd0 001b8670 00000000 kernel32!BaseThreadStart+0x34

So now that you know whats right, go out there and find out what's wrong:)





,
Comments
  • Christopher Steen
    3 Apr 2007 12:35 AM

    So how much faster is it really and is it? WCF performance in comparison. [Via: clemensv@microsoft.com...

  • Jason Haley
    4 Apr 2007 11:54 PM
  • Piers
    24 May 2007 2:26 AM

    Hmm, based on that, my threads aren't doing anything when it crashes. They're all doing WaitForSingleObject or somesuch.

    If all of my threads start with

    05 0006fff0 00000000 kernel32!IsProcessorFeaturePresent+0x9e

    or

    01 009affec 00000000 kernel32!GetModuleFileNameA+0xeb

    does that mean I've got the wrong symbols loaded for the Kernel? Do I care?

  • 25 May 2007 9:12 AM

    Hi Piers,

    Yes that means that you dont have any symbols loaded.

    Typically if you take a memory dump when a process CRASHES you will only see one thread.  And if at that point there is no real cause for the crash it is probably a recycle because of some recycling setting in the apppool.  I think though you might be talking about a hang, and if you feel that you have a hang but nothing is executing you might not have taken the dump at the time of the actual hang.

    Tess

  • Piers
    7 Jun 2007 3:13 AM

    Yes it was a hang, but I had to look at the managed code to see what was going on.

    Later I realized that you'd done a walkthrough on this that I'd missed (http://blogs.msdn.com/tess/archive/2006/10/16/net-hang-debugging-walkthrough.aspx). Any chance of a proper index of your posts? The standard blog 'archives by date' format doesn't really work for this kind of technical/reference material (this comment not just restricted to your blog, obviously)

    Cheers,

  • 7 Jun 2007 9:03 AM

    What did you have in mind?  I am all for doing stuff that could improve the accessibility of the posts,  feel free to email me offline too (through the contact link) if you want if you have some good ideas for this...

    Thanks

    Tess

  • If broken it is, fix it you should
    13 Aug 2007 10:54 AM

    Recently we have been getting quite a few similar hangs in ASP.NET. From the first look they really aren't

  • If broken it is, fix it you should
    20 Aug 2007 8:26 AM

    Recently we have been getting quite a few similar hangs in ASP.NET. From the first look they really aren't

  • If broken it is, fix it you should
    4 Feb 2008 4:23 AM

    This is the first in a series of about 10 labs on .NET debugging. The lab will use a site called BuggyBits,

  • If broken it is, fix it you should
    7 May 2008 5:31 AM

    If I were to pick out ten keywords for my blog I would pick, in no particular order, ASP.net, windbg,

  • Justin
    8 Jul 2008 9:06 AM

    这是关于.NET调试的10个实验里的第一个。这个实验的对象是个名叫BuggyBits的站点，就像名字暗示的一样，虫子的攻击是非常凶猛地！(buggy：多虫的,臭虫成灾的) 开始前，请务必按照前...

  • If broken it is, fix it you should
    16 Sep 2008 7:36 AM

    Here are of some of the reader emails I got this week and my answers to them... How do I troubleshoot

Page 1 of 1 (12 items)
Leave a Comment
  • Please add 4 and 7 and type the answer here:
  • Post