Good job on the approach. Looking at intelppm.sys wasn't really necessary since in this case when you look at the running thread for the faulting proc (proc 3) you can see that intelppm was not involved but rather nvlddmkm.sys, or the PCI-E bus, as the last few frames in the callstack show. In the specific situation I was dealing with in the OP, the amd chipset driver was responsible, but not in your case. I'll take a look at the kernel dump myself, but from what I see it looks like you'll want to ask the guy to remove the graphics card, clean up any foreign material that may be in the slot, and then reinsert it, as well as update graphics drivers if they haven't already.
I'm concerned about one thing though, in that you actually are retrieving a thread with all its info n stuff from the faulting proc, which isn't really supposed to happen if that proc was actually frozen. I would think what took place is the IRQL that proc was on at the time was higher than clock interrupt but not higher than the bugcheck, but if that was the case why didn't it save the IRQL (which shows up as 0), or if it
did successfully save it, then why on earth would a thread at IRQL 0 stop a clock interrupt?
Perplexing, but I'd like to look into it further. One of the things I'd like to do is check to see if anything in the callstack actually called to increase the IRQL (KeRaiseIRQL). There's a script someone made at
codemachine.com that will parse through a module to see if there's any calls it makes to a function name that you give it, which is very convenient. It's not perfect, but does the job well. There's other ways of approaching this as well, but I'll determine that to the best of my ability when I take a look at it.
