• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Crash Dump Analysis Needed

well...ummm sorta. what were you doing when it happened? does it happen frequently? have you updated all your drivers?
 
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:
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:
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.
 
dfnkt said:
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.
Click to expand...

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
 
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.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top