Immediate Learning

Learning BSOD Analysis: Your first analysis in WinDbg

Learning BSOD Analysis: Your first analysis in WinDbg

Welcome to part two of Learning BSOD Analysis, in this post we will cover the basics of all the information you’ll get from reading a dmp file.

[alert-announce]If you have not read Learning BSOD Analysis: Getting Started then I would advice you to read it first![/alert-announce] [alert-warning]There will be a lot of images below, click on them to enlarge them![/alert-warning] [button-blue url=”http://windowsinstructed.com/learning-bsod-analysis-getting-started/” target=”_self” position=”left”]Previous Lesson[/button-blue] [alert-announce]Don’t forget to subscribe to WindowsInstructed! You can do this on the homepage or by registering an Account with WindowsInstructed. We won’t sent you spam, only the latest website updates, new content and from time to time helpful information![/alert-announce]

Opening your first BSOD file.

To begin debugging you’ll need a dmp file, So your system has to been crashed already, or Google it and download an example.

You will notice when you open the file that a lot of information will appear on your screen, this is normal, and has some useful information.

2014-05-30_11-59-37

As you can see it has the Windows version, the number of processors and the architecture of the processor. If you’re debugging your own system then you should already know this, but it could be useful when debugging other people their dmp files.

!Analyze -v

Now things are getting serious! We are going to read our first dump file, and find out what the problem is! To begin you’ll have to click the  !analyze -v link, now wait patiently, this can take some time!

Results from !Analyze -v

Whoa!!! Will be the first thing you think, but don’t worry! I will walk you through this! See the example below

2014-05-30_12-04-26

 

The first thing we have to do, is the find the main cause, what is the main problem. otherwise known as the bugcheck. You find this information in the first paragraph of the results.

2014-05-30_12-07-47

 

“Aha! A DRIVER_POWER_STATE_FAILURE…. What the hell is that? ” if that was the first thing that came to your mind, believe me it’s normal. You’ll first have to find the most common reasons for this to happen, Microsoft has been very nice for us, and you can do that here: http://msdn.microsoft.com/en-us/library/windows/hardware/hh994433(v=vs.85).aspx

Since it’s a driver problem we can normally find more information the dmp file itself, lets continue reading it.

2014-05-30_12-12-05

 

As you can see I’ve marked IMAGE_NAME yellow, the reason for this is that in most cases this can lead you to the real cause (not this time, we wont make it too easy would we…).

If you do some research on pci.sys you will discover the following (http://www.file.net/process/pci.sys.html) “The process known as NT Plug and Play PCI Enumerator belongs to software Microsoft Windows Operating System or PCI Bus Driver by Microsoft” most computer users will now know that this by itself could not cause the issue, since none of your PCI devices would work anymore (video card, network card and so on) so the cause of this BSOD has to be something else, but it does have to a PCI device. So the reason for this crash is either a driver issue or hardware malfunction… lets continue reading the BSOD.

2014-05-30_12-19-14

 

Now thats where the stack text and FAILURE_BUCKET will become your friend. We will need to find the precise device or driver that is causing the issue, try to look for things that come by multiple times and if possible in the stack_text and in the failure_bucket, if you looked good you will have seen that RT64WIN7 passes by a couple of times…

Perhaps its a good idea to analyse this file? Lets google RT64Win7 shall we? A site I like is File.net it shows the most helpfull information for a file.

If you did your research good you will have found that RT64Win7 belongs to Realtek (version 8136/8168/8169 PCI/PCIe Adapters), So we now have found the main problem, its the Realtek 8136…. PCI Adapters… Lets look what that is… And you will find that it’s the drivers for the Realtek networking card.

Conclusion

[alert-success]The solution to this BSOD was reinstalling the networking drivers for the customer and the BSOD have never come back.[/alert-success] [divider]

But there are more than just BSODs from Drivers…If you wish to learn more, then continue to the next lesson: Learning BSOD Analysis: What is going on?!

[button-blue url=”http://windowsinstructed.com/learning-bsod-analysis-going/” target=”_self” position=”left”]Next Lesson[/button-blue]

 

5 Comments

  • NBK*Twitch June 1, 2014

    Very nice guide!!

    • Yuri Pustjens June 1, 2014

      Thank you 🙂 Good to hear!

    • Yuri June 1, 2014

      Thank you 🙂

Leave a Reply to NBK*Twitch Cancel reply

Your email address will not be published. Required fields are marked *