Debugging a bluescreen at home

re: Debugging a bluescreen at home

molotov — Fri, 28 Mar 2008 18:45:07 GMT

Chad,

Thanks for the great post! I enjoy reading walkthroughs of a bugcheck analysis like this - has me trying to think "what's the next step" each step of the way...

re: Debugging a bluescreen at home

Brad — Fri, 28 Mar 2008 19:28:21 GMT

Nice post. Thanks for sharing your analysis...

re: Debugging a bluescreen at home

Gilbert Verdian — Fri, 28 Mar 2008 20:13:17 GMT

Good write up Chad, had a similar problem a few years back with constant bluescreens as soon as the cpu started doing some heavy work... turns out forgot to add the heatsink thermal gel to spread the heat from the cpu...

Funny how we always think it's always a software problem!

re: Debugging a bluescreen at home

Steve — Fri, 28 Mar 2008 23:13:04 GMT

I just wanted to say THANK YOU for writing articles like this. I often wonder how to analyze crash output to better my understanding of Windows OS troubleshooting.

-Steve

re: Debugging a bluescreen at home

steve — Sat, 29 Mar 2008 00:56:59 GMT

Oh also if possible could you include a link to your dump files so we can download, import and !analyze like you do? Using your post and comments as a guide to the thought process.

Thanks again!

[That would be nice, but remember that memory dumps contain the entire contents of memory at the time they are created. As such, they always have potential to contain sensitive personal information. I wouldn’t ever feel comfortable posting a memory dump from my own personal machine (or any machine in a real production environment) on the web for the general public to see. Sorry!]

re: Debugging a bluescreen at home

David Moisan — Sat, 29 Mar 2008 04:43:51 GMT

In the crash dump, there's a reference to nikonscan:

NikonScan4!GetSource+0x21e93

Where does the GetSource symbol come from? I have never seen a third-party driver in the wild with symbols included.

re: Debugging a bluescreen at home

Craig Hildebrandt — Sat, 29 Mar 2008 08:36:27 GMT

Chad,

Excellent article and writeup, and thanks for sharing this information and experience. While the !analyze -v in this example could have easily led you astray in the early stages of analysis by the bucket ID being "Driver_Fault" is it not often when you see this string in a debug output "EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s"." a clue that you should verify memory, hardware, etc. is not the culprit. I know bad drivers can cause bit flips, corrupt memory, etc. and things like that sometimes, but many of the Hardware related bugchecks will typically have this in them from my experience. I am open to your thoughts and comments regarding this. Anyways I can see how this could have been a very tricky one to pinpoint, so good job of taking a perhaps nebulious bugcheck to root cause. With many PCs trying to get more horsepower out of a box with smaller space, this is a great thing to keep in mind as cooling technology designs can be challenging, and dust buildup can negatively impact the capabilities of the cooling system.

re: Debugging a bluescreen at home

Mike — Sun, 30 Mar 2008 03:37:57 GMT

Hi, i'm learning a lot with your blog. I have a question, what does the 0x90909090 that is at the bottom of the stack trace mean? I suppose it's an address that the debugger couldn't match with any loaded symbol, but why?

Thanks,

[The debugger doesn’t have any symbols for Nikonscan4.dll. When it doesn’t have symbols for a module, it will try to keep following the stack anyway, but it’s not always capable of doing so. In this case, it got confused (possibly because this function was compiled using Frame-Pointer Omission) and picked the wrong EBP for the next stack frame, leading to bad results.

In a case like this, if you can’t get hold of the symbols for the module, you can dump out the contents of the stack manually by using a command like “dps esp” and try to walk further back through the stack on your own.]

re: Debugging a bluescreen at home

molotov — Mon, 31 Mar 2008 16:11:22 GMT

@ David Moisan:

GetSource is probably an exported function from NikonScan4.sys; the symbol engine probably resolved to the nearest export, given the (likely) unavailability of a PDB, and the large offset (0x21e93).

[Yes, this is correct.]

¿Cuánto hace que no miras los disipadores de calor por si han acumulado polvo?

Apuntes de un loco — Mon, 31 Mar 2008 20:59:14 GMT

Ha transcurrido un mes y medio desde mi último post , ya me vale. Hace unos días, en el blog de solución

Interesting Finds: 2008.03.31

gOODiDEA — Tue, 01 Apr 2008 03:12:51 GMT

.NET:Improving.NetPerformanceWithNgen:TheNativeImageGeneratorDefiningRoutesusingRegul...

re: Debugging a bluescreen at home

czth — Wed, 02 Apr 2008 21:10:59 GMT

Mike: I have a question, what does the 0x90909090 that is at the bottom of the stack trace mean? I suppose it's an address that the debugger couldn't match with any loaded symbol, but why?

0x90 is the x86 NOP (no-operation) opcode; could be the top frame was a region of NOPs.

re: Debugging a bluescreen at home

BW — Wed, 09 Apr 2008 18:10:19 GMT

I had a similar problem with my video cards overheating. Dust and lint were cause.

NTDebugging Puzzler 0x00000004: This didn’t puzzle the Debug Ninja, how about you?

Microsoft Advanced Windows Debugging and Troubleshooting — Fri, 02 May 2008 16:49:53 GMT

Hello NTDebuggers, we have been very impressed with the responses we’ve gotten to our previous puzzlers

re: Debugging a bluescreen at home

Sushant — Tue, 02 Dec 2008 06:57:41 GMT

Indeed a beautiful post. A great learning especially those who are starters.

Good Work shown Chad.. Hoping to see more from you.