New
#11
Thanks H2SO4! I'm learning a whole lot from your explanations!
The chances of finding any reference to the driver (culprit) in my mind would be very miniscule, since the driver arbitrarily overwrote that section of memory that the memory manager is trying to dereference with garbage. Where you able to find any reference? Maybe show Usasma the procedure so that he can be informed.Yes, you're right about the mechanics of what happened, but sometimes it's possible to get lucky in "pool corruption" situations and actually spot some clues as to who (what driver) did the corrupting. (That's why I requested the minidump.) The top 5 stack frames:
Last edited by shuster; 16 Oct 2009 at 09:28.
True, absolutely true, especially in a minidump. It's most likely that the memory in question won't even fit the criteria for what gets included in the minidump. Hence, even if one knew precisely where to look - it would be impossible without a full kernel dump.
However, there's at least one alleviating factor. Pool corruption is frequently an overrun/underrun, and that's not entirely arbitrary. The corruptor driver can have its own alloced regions of pool right next to the corrupted bit. Hence, by studying the order of the pool allocs at the time and their metadata, it's sometimes possible to make rather accurate guesses about whodunnit.
Entirely wild stabs across the kernel-mode address space are a mechanically different problem. They're very difficult to catch, unless you get lucky and the destination happens to trip some sort of guard page, and not likely detected by special pool either. Those are some of the most nasty issues to "debug".
Nope. Not that time. Enabling special pool should be the OP's next course of action.
I absolutely agree. It is worthless to try and analyze a minidump after a protection violation exception. The information is incomplete and in most cases irrelevant to the situation that caused the memory corruption in the first place.True, absolutely true, especially in a minidump. It's most likely that the memory in question won't even fit the criteria for what gets included in the minidump. Hence, even if one knew precisely where to look - it would be impossible without a full kernel dump.
Many of the bsods you see in this forum and other forums are directly or indirectly related to system protection violations. This leads the OP down the wrong path and only increases the level of frustration which is not conducive to the problem-solving process.
The hypotheticals that you mention are rarely the case in the real world.
Wading through a full kernal memory dump can cause even the most seasoned programmer to age before his time and in most cases will not reveal what you were looking for in the first place.
I keep on hearing about this "real world" concept.
Out of curiosity, which of the hypotheticals I mentioned are rarely the case?
"Wading" would indeed be pointless. However, in the hands of somebody with a very solid grasp of OS internals - and I don't mean me - a kernel dump will more often than not provide the means to gauge what is wrong, or at least where to go next. It depends of course on the type of problem and the level of information available - do they have symbols for a given driver? Public-only or private? Source access? A repro sitting on the desk in front of them? A kernel debugger hooked up and broken in at the point of the crash?
It's not quite so bleak as some would have you believe