I'm moving again... back to my original blog: http://randtalk.blogspot.com/
I don't think anyone follows this blog anyway so....
Saturday, December 13, 2014
Tuesday, December 9, 2014
Getting Started with WinDbg
Recently one of my applications started freezing up on our Production servers. It was impossible to figure out what was going on from the logs and reviewing the code seemed to only show that such behavior should be impossible. So I took a crash dump and used WinDbg to analyze. Turned out it seemed to be caused by one of the libraries our origen used and that was recently upgraded. Simple, right?
...Not quite, I skipped the part where it took me more than 2 days to figure out how to properly take the dump and get it running inside WinDbg.
So to save other people the trouble, here what you need to now and how to get started.
First, you'll need to get the program which comes in two versions, 32 and 64-bit. The one you need depends on the version of the program you are debugging, not the operating system it is on.
On a 64-bit Windows, you can tell this at by looking at the process in Task Manager. A 32-bit application with have *32 next to the process name in the Details tab.
The WinDbg installers though are part of the Windows SDK package which is downloadable on the Microsoft site.
However, the web installer wants to install the entire SDK but really you just need WinDbg. So...
You can download the ISO here and after mounting it, there should be a folder with the WinDbg installers, thus avoiding the need to install the SDK.
This is for the Windows 7 SDK but for other versions there should be something similar; just search around for it.
OK, so let's say you need to debug a 32-bit process running on 64-bit Windows 7. However, you will doing the analysis on another machine (running a different version of .NET).
So first, you need to take the process dump. To do this, I recommend you use SysInternal's Process Explorer (procexp.exe). If you Google it, you will easily find it (will put a link up eventually)
This avoids the issue of having to run the 32-bit version of Task Manager because it's too stupid figure the correct format of the dump file in the 64-bit program. ProcExp avoids the whole issue because it's smart :) Just right-click on the process and select Dump --> Full Dump
I've never tried mini dumps, but more is probably better.
No once you have this file, you need to copy it somehow to your debugging machine. Also you need to copy 2 files from the machine:
Now start the version of WinDbg based on the application's bit-ness, in our case 32-bit.
Then, drag the dump file into the program. This will load it.
Now configure the Symbols Path using File->Symbols Path, and enter:
SRV*{local path}*http://msdl.microsoft.com/download/symbols
The {local path} should be a folder; it does not have to exist.
Now you need to load the process PC's .NET environment, specifically the two DLL files.
Execute .load {full path to file} to load the two DLLs.
Then type !analyze which will begin analyzing the dump.
If you get an error saying something like the CLR version does not match, most likely it is because it automatically loaded this machine's environment which overrides the custom set ones.
If you run .chain it should show the first entry as something related to .NET. Also make sure the two DLLs you loaded are under it.
Type .unload to remove the entry and analyze again. This should not have any issues now.
And now you're all set up!
Here's a few cheat sheets to get you started:
http://windbg.info/doc/1-common-cmds.html
http://theartofdev.com/windbg-cheat-sheet/
Also here's the link to the SOSEX extension which adds some pretty useful features, in my opinion.
http://www.stevestechspot.com/
You can load it in a similar manner as the other DLLs.
Pictures to come at a later date... or never.
This avoids the issue of having to run the 32-bit version of Task Manager because it's too stupid figure the correct format of the dump file in the 64-bit program. ProcExp avoids the whole issue because it's smart :) Just right-click on the process and select Dump --> Full Dump
I've never tried mini dumps, but more is probably better.
No once you have this file, you need to copy it somehow to your debugging machine. Also you need to copy 2 files from the machine:
- SOS.dll
- mscordacwks.dll
- C:\Windows\Microsoft.NET\Framework64\{version}
- C:\Windows\Microsoft.NET\Framework\{version}
Now start the version of WinDbg based on the application's bit-ness, in our case 32-bit.
Then, drag the dump file into the program. This will load it.
Now configure the Symbols Path using File->Symbols Path, and enter:
SRV*{local path}*http://msdl.microsoft.com/download/symbols
The {local path} should be a folder; it does not have to exist.
Now you need to load the process PC's .NET environment, specifically the two DLL files.
Execute .load {full path to file} to load the two DLLs.
Then type !analyze which will begin analyzing the dump.
If you get an error saying something like the CLR version does not match, most likely it is because it automatically loaded this machine's environment which overrides the custom set ones.
If you run .chain it should show the first entry as something related to .NET. Also make sure the two DLLs you loaded are under it.
Type .unload to remove the entry and analyze again. This should not have any issues now.
And now you're all set up!
Here's a few cheat sheets to get you started:
http://windbg.info/doc/1-common-cmds.html
http://theartofdev.com/windbg-cheat-sheet/
Also here's the link to the SOSEX extension which adds some pretty useful features, in my opinion.
http://www.stevestechspot.com/
You can load it in a similar manner as the other DLLs.
Pictures to come at a later date... or never.
Keeping It Simple
Complexity is a great demotivator... For example:
Complexity: You have a 40 minute manual build/deployment process where a single error will set you back to the beginning? You're not going to doing builds too often and when you do, it will contain a large number of changes which if any issues arise will be some times be impossible to figure out what the root cause.
Solution? Automate the deployment process as much as possible. (NAnt, Ant, write some utility programs)
Complexity: You keep your shopping, to-do list, or a large amount of important information in your head. I guarantee you will forgot things and drive other people mad.
Solution? Write things down and organize them, because if you can't find it, it's the same as not writing it down... which leads to...
Complexity: You keep things everywhere in an unorganized manner such that it takes much longer than necessary to find things when you need them.
Solution? Find or develop some organization system with fixed rules which significantly narrows the area you need to look in.
Complexity: You have way too many blogs such that it you spend so much time trying to decide which one to post in that you don't post anything at all (Raises hand)
Solution? Well so far I decided to just pick one and move all the other content here. I'm still figuring it out...
Complexity: You have a 40 minute manual build/deployment process where a single error will set you back to the beginning? You're not going to doing builds too often and when you do, it will contain a large number of changes which if any issues arise will be some times be impossible to figure out what the root cause.
Solution? Automate the deployment process as much as possible. (NAnt, Ant, write some utility programs)
Complexity: You keep your shopping, to-do list, or a large amount of important information in your head. I guarantee you will forgot things and drive other people mad.
Solution? Write things down and organize them, because if you can't find it, it's the same as not writing it down... which leads to...
Complexity: You keep things everywhere in an unorganized manner such that it takes much longer than necessary to find things when you need them.
Solution? Find or develop some organization system with fixed rules which significantly narrows the area you need to look in.
Complexity: You have way too many blogs such that it you spend so much time trying to decide which one to post in that you don't post anything at all (Raises hand)
Solution? Well so far I decided to just pick one and move all the other content here. I'm still figuring it out...
Subscribe to:
Posts (Atom)