How to analyze a hang on a managed thread using windbg
The location of the crash dump file is:
%LOCALAPPDATA%\Microsoft\Windows\WER
- This is quite difficult to find online
First download windbg using the latest windows SDK and select just the windows debugging components.
Remember to use the right windbg for your process. If the process is x86, you need to use x86 windbg. This causes an error:
“Failed to load data access DLL, 0x80004005”
Use this link to learn how to setup the environment properly:
http://blogs.msdn.com/b/friis/archive/2010/09/02/managed-debugging-with-windbg-and-psscor2.aspx
It mentions how to load the Psscor2 dll - Just note to copy the right dll (x86/ x64) after downloading it into the correct windbg.exe folder (x86/ x64). That is not mentioned clearly.
http://www.microsoft.com/en-us/download/details.aspx?id=1073
Also, after setting the symbol path, please do .reload to reload the environment.
srv*C:\Symbols\symserv* http://msdl.microsoft.com/download/symbols
.cordll -u -l
.loadby sos mscorwks
.load psscor2
mscorwks does not work for .NET 4.0 and above. For that, use:
.loadby sos clr
To debug and/ or find the exception details:
!clrstack
!analyze
The below article, now shows how to find out which thread is causing the hang:
http://blogs.msdn.com/b/benjaminperkins/archive/2013/01/08/debugging-a-hung-application-with-windbg.aspx
!syncblk
~80s
k
The note to remember is that, once you find out the thread causing the hang using the !syncblk command, Use this command to shift focus to it:
~<threadid>s
To find what the thread is waiting on, you can then use "k" command as the article says.
To quit the debugger without killing the process:
qd
This article shows how to attach to the process and wait for a crash:
http://support.citrix.com/article/CTX106566
Essentially, after setting up as mentioned in the first link, type in "g" and press enter to see the windbg waiting for errors. It will say: "BUSY", and "Debuggee is running...". It will also mention all the exceptions being thrown at any time.
This excellent article shows how to debug an out of memory problem:
http://blogs.msdn.com/b/amolravande/archive/2008/12/16/debugging-outofmemoryexceptions-in-managed-code-using-windbg.aspx
To cancel a long running command: Debug Menu > Break.
%LOCALAPPDATA%\Microsoft\Windows\WER
- This is quite difficult to find online
First download windbg using the latest windows SDK and select just the windows debugging components.
Remember to use the right windbg for your process. If the process is x86, you need to use x86 windbg. This causes an error:
“Failed to load data access DLL, 0x80004005”
Use this link to learn how to setup the environment properly:
http://blogs.msdn.com/b/friis/archive/2010/09/02/managed-debugging-with-windbg-and-psscor2.aspx
It mentions how to load the Psscor2 dll - Just note to copy the right dll (x86/ x64) after downloading it into the correct windbg.exe folder (x86/ x64). That is not mentioned clearly.
http://www.microsoft.com/en-us/download/details.aspx?id=1073
Also, after setting the symbol path, please do .reload to reload the environment.
srv*C:\Symbols\symserv* http://msdl.microsoft.com/download/symbols
.cordll -u -l
.loadby sos mscorwks
.load psscor2
mscorwks does not work for .NET 4.0 and above. For that, use:
.loadby sos clr
To debug and/ or find the exception details:
!clrstack
!analyze
The below article, now shows how to find out which thread is causing the hang:
http://blogs.msdn.com/b/benjaminperkins/archive/2013/01/08/debugging-a-hung-application-with-windbg.aspx
!syncblk
~80s
k
The note to remember is that, once you find out the thread causing the hang using the !syncblk command, Use this command to shift focus to it:
~<threadid>s
To find what the thread is waiting on, you can then use "k" command as the article says.
To quit the debugger without killing the process:
qd
This article shows how to attach to the process and wait for a crash:
http://support.citrix.com/article/CTX106566
Essentially, after setting up as mentioned in the first link, type in "g" and press enter to see the windbg waiting for errors. It will say: "BUSY", and "Debuggee is running...". It will also mention all the exceptions being thrown at any time.
This excellent article shows how to debug an out of memory problem:
http://blogs.msdn.com/b/amolravande/archive/2008/12/16/debugging-outofmemoryexceptions-in-managed-code-using-windbg.aspx
To cancel a long running command: Debug Menu > Break.
Comments
Post a Comment