Crash Dump Analysis Needed

dfnkt

Senior member
May 3, 2006
434
0
76
Anyone want to take a stab at this?

http://pastebin.ca/1765200

Had a 0x0A STOP code, It appears to be an issue with a driver or hardware using an incorrect or conflicting IRQ -- Anyway to find out which driver?
 

Intexity

Senior member
Jan 10, 2009
299
0
0
well...ummm sorta. what were you doing when it happened? does it happen frequently? have you updated all your drivers?
 

dfnkt

Senior member
May 3, 2006
434
0
76
Actually this is from my in laws computer. I'm not sure what was happening at the time. The computer was recently restored to factory settings. I will probably run through and check driver versions this coming weekend and update any old ones.

I only learned about doing Crash Dump analysis a month or so ago so I do not consider myself great at it.

I do know however that this was a single instance of the STOP code and that it hasn't been seen since.

IRQ 2 is cascaded with 8-15 so it makes it hard to pinpoint exactly what piece of hardware this might be. I found a mention online of IRQ 9 specifically being used as a substitute so I might look in the BIOS to see what is assigned to 8-15.

From PCHell:
9 This IRQ uses IRQ 2 to talk to the CPU, so it has a high priority. Its generally used for network cards.

^^ And the stack trace mentions "frames"

Hopefully I can post back with something useful.
 
Last edited:

RebateMonger

Elite Member
Dec 24, 2005
11,586
0
0
These might be of use to you:

Microsoft: The ABC opf Blue-Screen Dump Analysis. Note the "Memory Corruption" example, which is what you seem to have:

http://blogs.microsoft.co.il/blogs/.../28/the-abc-of-blue-screen-dump-analysis.aspx

This response to another "memory corruption" example might be helpful:

http://www.osronline.com/showThread.cfm?link=96641

"Memory corruption problems are extremely difficult to identify and
resolve. The only thing you can do (given that none of the drivers on
the system are yours) is to continue as you have been doing - try to
turn off various drivers.

Far less likely, but always possible, is that you have a hardware
related problem. Can you confirm that you have parity and/or ecc
memory? Have you looked at the event log to see if there are any
issues/errors reported?

Assuming it is driver related, you'll need to try to identify the likely
culprit by elimination - by the time the system crashes, the damage is
long since done.

As Max indicated, this type of problem is usually an indicator that
there is an MDL handling bug in a driver."


I'd:
0) Check the System Event Log for any error messages that might identify the device or driver that caused the error.
1) Do an extended Memtest86+ test.
2) Remove or disable all unnecessary devices and drivers.
3) Update remaining device drivers to the latest available.
4) If the system is now stable, add back the disabled devices one at a time.
 
Last edited:

dfnkt

Senior member
May 3, 2006
434
0
76
Probably a good plan RebateMonger. I'll run through the logs this week and run a memtest on it. I had a similar "IRQ_NOT_LESS_OR_EQUAL" BSOD that took me a month to trace back to faulty RAM.
 

Gamingphreek

Lifer
Mar 31, 2003
11,679
0
81
Actually this is from my in laws computer. I'm not sure what was happening at the time. The computer was recently restored to factory settings. I will probably run through and check driver versions this coming weekend and update any old ones.

I only learned about doing Crash Dump analysis a month or so ago so I do not consider myself great at it.

I do know however that this was a single instance of the STOP code and that it hasn't been seen since.

IRQ 2 is cascaded with 8-15 so it makes it hard to pinpoint exactly what piece of hardware this might be. I found a mention online of IRQ 9 specifically being used as a substitute so I might look in the BIOS to see what is assigned to 8-15.

From PCHell:
9 This IRQ uses IRQ 2 to talk to the CPU, so it has a high priority. Its generally used for network cards.

^^ And the stack trace mentions "frames"

Hopefully I can post back with something useful.

Ok first off, the frames that are mentioned in the stack dump are the stack (Activation Record) frames.

For instance, assuming you know what a stack is, when a new ARI must be created (assuming no optimizations) the ebp and esp (Base pointer and Stack pointer) point to the same memory address. The esp is then subtracted a certain number of bytes to create a sort of frame.

In your case you have:
ebp: 0xb5b3db58
(28 bytes later)
esp: 0xb5b3db30

Now what does this tell us - well, nothing to be honest. You would need a debugger and you would need the system in an identical state to have a shot debugging this program.

With that in mind, do what RebateMonger said. IRQL BSOD is almost always an underlying hardware/driver issue (Memory is normally a prime culprit). Just run Memtest or Prime95. If neither of those error, just leave it alone and hope it is a one time thing.

-Kevin
 

dfnkt

Senior member
May 3, 2006
434
0
76
Thanks gamingphreek. I am far and away from a programmer. I've been trying to dabble for the last 2-3 months and I've gained a little bit of knowledge but nothing yet related to the debugging code from the traces.

I will run memtest for sure, like I said, it happened to my computer at home awhile back.