User-friendly: Analyzing your first BSoD!

[FredeGail]

Introduction

   Note

So this will be a little bit different guide for analysing dump files and hopefully figure out the cause of a BSoD. It'll be userfriendly for sure, and I will share my own experience. The tutorial will start off with the very basic things, and will probably get a little harder, but not that hard at all!
So there you have it! Read it through a couple of times if you misunderstood something, or just ask in the thread itself.

Happy analysing!

   Tip

If your Windbg shows errors related to the symbol path, you should read the Windbg tutorial again and check up on it.

   Warning

Delete the bunch of dumps you're analyzing once a month or so. It can run up in Gigabytes!

Get the Windbg ready!
Windbg stands for Windows Debugging as you probably guessed, and it's the visualizer for the dump file. It works a bit like a command prompt, a bit different though; you enter a command, you will get it. But we will get to all this later, first let's get your Windbg ready. The tutorial below covers it all, return when you're ready!

Configuring the Debugging Tools

What is a dump file?
A dump file, also called a crash dump, is created when a BSoD appears. It'll make you able to see what the BSoD caused in many cases. It'll tell you what kind of events that has been happening till the BSoD took place. Bigger dumps takes longer to load. If the user doesn't have this included in the zip file, you should link to the page below.

Posting Instructions

Let's get started
If you followed the "Configuring the Debugging Tools" you're able to simply double-click on a .dmp file and Windbg will open. Let Windbg load the dump, it can take time. If it takes more than 2min or so, the dump is in-complete. If this is the case, you should pick another dump in the .zip.

Probably caused by
So in the very first beginning there's a lot of text just when you open the dump. That's actually information about the symbols you picked earlier. When you see a text field where it says:

Probably caused by: (something)

.. the dump is loaded. In most cases, it shoots the fault at 'ntoskrnl.exe' which is likely very incorrect. It'll just put the fault on that .exe file if it can't figure out what's 'Probably' causing the dump.
If the dump points to something else, go to a driver reference (Carrona), and search for it. A dump is fairly easy to analyse if this is the case.

Bugcheck
The Bugcheck is probably something you know by own experience. It's a number and some text which shows what kind of BSoD the user has been experiencing. Here's an example of a Bugcheck.

STOP 0x1000007F: UNEXPECTED_KERNEL_MODE_TRAP_M

You can check this website (BSOD Index) and search for the probably causes.

In this case, it could be the CPU.

So, where's the Bugcheck?
the command '!analyse -v' will give you a more detailed analyse-dump. You can't really miss it. It's surrounded by stars and says Bugcheck.
In a lot of cases, the Bugcheck says it's caused by a memory corruption, and you should inform the user to run a Memtest86+.

Check for old drivers.

lmntsm

That's a command for showing drivers, but I certainly do not recommend it that way. Do it this way:

i) click Debug
ii) click Modules
iii) sort it by date

Wrap the old drivers in a

[/CODE ] and post it for the user. If the user wonders how to find the drivers make a [QUOTE][/QUOTE ] saying:

[QUOTE]How to Find Drivers
search Google for the name of the driver
- compare the Google results with what's installed on your system to figure out which device/program it belongs to
- visit the web site of the manufacturer of the hardware/program to get the latest drivers (DON'T use Windows Update or the Update driver function of Device Manager).
- if there are difficulties in locating them, post back with questions and someone - will help you search Google for the name of the driver
- compare the Google results with what's installed on your system to figure out which device/program it belongs to
- - if there are difficulties in locating them, post back with questions and someone will try and help you locate the appropriate program. 
- The most common drivers are listed on this page: [url=http://www.carrona.org/dvrref.html]Driver Reference[/url]
- - Driver manufacturer links are on this page: [url=http://www.carrona.org/drvrdown.html]Drivers and Downloads[/url]
To remove any left over driver remnants, especially from graphics cards, use driver sweeper 
[url=http://www.guru3d.com/category/driversweeper/]Guru3D - Driver Sweeper[/url][/QUOTE]

[B]What if a process is set as 'Probably caused by'?[/B]
When the Probably caused by function ends with .exe and the Bugcheck informs a process, you know it's a process, for now. It'll likely be a worm also known as Malware. For that we have the awesome tool for a scan. You should link to the following:

[URL="www.malwarebytes.org"][B]Malwarebytes[/B][/URL]

It could also be a broken system file in that case, they should run the 'sfc /scannow command in a command prompt. It'll likely restore some Windows 7 files. Tell the user to run it 2-3 times as it won't likely repair at first run.

[URL="http://www.sevenforums.com/tutorials/1538-sfc-scannow-command-system-file-checker.html"][B]SFC-command[/B][/URL]

[B]Antivirus error[/B]
If you discover a Antivirus error, you should ask the user to uninstall their current Antivirus, and ask them to install Microsoft Security Essentials. An antivirus should be uninstalled with the manufactures' software. Here's a list of uninstallers.

[URL="http://www.carrona.org/avuninst.html"][B]Uninstallers[/B][/URL] 

[B]Conclusion[/B]
There are much more ways to analyse dumps, much more advanced too, but this is just the general things I look for first. Somehow I find the pattern analyses quite irrelevant. Of course it can be used if the dump is a bit harder to analyse, but in most cases you can just pick another dump from the zip. I will probably make more detailed guides next time. For now, I hope you enjoyed it, and i'm sure that you can use it sometime. I totally understand if you find this hard and thinks there's a lot of writing, well, even the professionals can have trouble with all this. 

[B]Change-log[/B]
[I][CODE]- added malwarebytes option
- added sfc /scannow command
- added anitivirus
- added antivirus-uninstallers
- added goodies in the conclusion
- added lmntsm instead of lm t n
- added tip/warning

[/I]

Fred.

 

[Dinesh]

Great job mate.

 

[FredeGail]

Great job mate.

Thanks Dinesh!

 

[xxxdannyxxx]

Very interesting FredeGail especially for someone who doesn't know where to start like me lol

Danny

 

[FredeGail]

Very interesting FredeGail especially for someone who doesn't know where to start like me lol

Danny

Glad you also could use it Danny.
Thanks!

Fred.

 

[seavixen32]

Cheers Fred, BSOD analysis left me cold as I didn't know where to start.

Now I know where to start I need to find a road map for the rest of the journey!

 

[FredeGail]

Cheers Fred, BSOD analysis left me cold as I didn't know where to start.

Now I know where to start I need to find a road map for the rest of the journey!

Haha, glad you liked it seavixen!

Fred.

 

[FredeGail]

I updated some stuff. You can check the change-log in the end of the main post!

Fred.

 

[Dave76]

Nice tut Fred, good information.

It's actually pretty easy once you do it a couple times.

When looking for causes and clues, open the Event logs, $evtx_app_dump and $evtx_sys_dump, these are application and system event logs.
These are usually big files, so use the 'Find' in the 'EDIT' tab, enter 'error' (no quotation marks).
This will take you to all the errors and usually you will find some interesting information.

 

[SledgeDG]

Nice work !
Just a remark:
Instead of

lm t n

I use

lmntsm

which sorts by name and serves me better when looking for a specific driver.

-DG

 

[FredeGail]

Thank you guys!
This is what's keeps me motivated.

Sledge, I added your suggestion to the main post and the change-log. I was actually looking for something like this as you can't copy text from the Modules list.

Fred.

 

[Influx]

Great, now users only have to study further and gain experience in debugging crash dumps

 

[SledgeDG]

...as you can't copy text from the Modules list.

Fred.

In Windbg? Au contraire, my friend Try mark the modules in question with the mouse cursor and press CTRL-C. Now they should be in the paste-buffer and you can post them with CTRL -V. Tedious, I know but possible non the less.

-DG

 

[AllOnTheBus]

Nice tutorial- very helpful

Check for old drivers.

lmntsm

That's a command for showing drivers, but I certainly do not recommend it that way. Do it this way:

i) click Debug
ii) click Modules
iii) sort it by date

I am trying to learn the ins and outs of this as we speak.
I was wondering if you might be able to explain the above to me as I must be missing something here.

If I run the !analyze -v command it appears similar to a command line window. I then go back to the main GUI of the windbg program and click Debug Tab->Modules-> New window appears. From here, how do you arrange the items in date as you have mentioned and is it possible to determine from that output whether any of the drivers are indeed out of date and in need of updating - if so, how? Are the dates mentioned the driver release dates and one would simply find if there is a later driver through the appropriate search channel?

Thanks in advance.

 

[SledgeDG]

The "crux" is that an outdated driver doesn't necessarily have to be a bad driver.
But you can safely assume that drivers which publishing date lies before the release of Windows 7 are outdated.
I use above mentioned code to get an output sorted alpha-numerical.

-DG

 

[jcgriff2]

Windows OS Driver Base Timestamps - sysnative.com - MVP

 

[Gator]

Frede, didn't you make a youtube series on Windbg? I remember watching one a few years back but can't find it.