Debugging with Windbg – with no time to spare


Debugging with Windbg – with no time to spare

Sometimes time is not on our side and we need data before we can even think about it. With Blue screens that is mostly the case, no one will give you days to examine the crash that just happened, they want to know will it happen again today, tomorrow or anytime soon.
There is a nifty way of creating a fast analysis of dump file that I came across that helped me a lot.
I got these commands from someones blog but after days of debugging my history list is as complex as a dump file. So if you think you own credits for this reach out and I’ll make sure you get them. (not my thing to take someones credits for their hard work).

Requirements

What you need is Microsoft Windbg installed on a system, here I used a Microsoft Windows 2012R2 system. Windbg is installed in C:Program Files (x86)Windows Kits8.1Debuggersx64 by default, remember that path.
That’s all you need next to some disk space to save the dump files.
So when you collected some dumps like I did (looks bad all those folders but that over the course of 3 months, one per server. Mostly because of picadm.sys which is fixed now).

Command prompt

Open Command prompt with Administrative rights and browse to C:Program Files (x86)Windows Kits8.1Debuggersx64.
First command to use is the one to load the dump file with Windbg. This is the same process as you would do when you open Windbg but now it’s done through a command line – which is cooler.
Command used is: kd -z

You could make a batch file for this with a parameter for the server name, not that much work and it would be you instant debug tool.

Next command used is the command to open a log file where the dump is to be written.
Command used is: .logopen

And we continue, Windbg by default doesn’t know about the symbols so we need to guide it to a symbol path. This you’ve also see in my previous blog and here it’s done again. Again all these steps could be integrated in one batch file.

Command used is: .sympath srv*c:symbols*http://msdl.microsoft.com/download/symbols

So now the dump is connected, the log is open and the symbols are loaded. Let’s analyze!
What this command does is reload the dump with the symbols loaded now and kick off the !Analyze command and some more options.

Command used is: .reload;!analyze -v;r;kw;lmnt;.logclose;q

The end result is a log file in the temp location that you set that is easily read (for a dump file) and didn’t take you longer than 1 minute to create. 
Below is the debuglog.txt that was creared and it shwos the 1E BSOD that occured because of a c05 that happened somewhere. the c05 was caused by TDX.SYS being a bad boy, there seems to be fix from Microsoft for it so let’s give that a try.
I hope this helps you creating a log of a dump and perhaps solves some issues. The dump logs tell a lot and most issues you ran into are known already. If you see a file that is of a specific vendor, first see if you can remove the software to test. If that’s not possible contact the vendor they might have more customers with this issue. 
Enjoy reading dump files 🙂

Leave a Reply

https://tracking.cirrusinsight.com/869c29e2-3a9b-48c5-9232-0b95e7993ae8/controlup-com-pixel-php