Glad you guys like it so far!
One thing that was an eye opener for me was in Hardcore Debugging, where Andrew explained that when an interrupt occurs, it pretty much takes over the stack that's already being used at the time, and then cleans up and lets the original code continue. That was just something that didn't click to me before. I always thought stuff like that happened in its own environment, with its own stack and all, and it just switched to the original stack after it's done, but evidently that's not the case. That gives a whole new understanding to the Trap frames you see when you do a kv on a callstack. It means the portion before and after the trap frame aren't always related to each other. It could be something completely irrelevant that just butted in because it had higher IRQL. It's like someone asks you "I need to do something on your computer real quick" and then after done closes everything he did and lets you continue on with what you were doing. This is how when you see a 0x101 or 0x133 bugchecks that whatever callstacks are retained will often have timer functions at the end of a callstack, because the system butted in using a clock interrupt and did a checkup on all the CPUs to keep things in sync.
I've also noticed that sometimes the interrupt is relevant. It all really depends on looking at the stack and determining just what was going on at the time and making an educated interpretation.
