Please help. I've got a serious system problem and I'm out of ways to debug it...
I've been posting lots of stuff to the NTDEV list so you can look there if you want to see some past history.
At the moment, I have written a kernel driver and a user app to exercise it. Running the up causes the computer to freeze up after a variable amount of time, usually within a minute. I'm running windbg on a host over ethernet, and the break command doesn't produce any response.
I know I've got things connected right because I CAN run the break command before I run my app on the target, and verify that the target becomes unresponsive untill pressing F5 on the host.
The Ctrl+ScrLock+ScrLock doesn't work either. So I can't get a memory dump. All I can do is pull the plug on the PC and reboot it.
Any suggestions as to how to see what's happening leading up to the freeze or during the freeze. This could involve some hardware, such as connecting a switch to the NMI pin on the CPU, provided that I can install something on the system that will respond to the NMI by doing a bugcheck, rather than simply rebooting. I believe the CPU has some debugging interface pins and perhaps if I can get to them via the MB, I can find out what the CPU is actually doing.
I'm surmising that during the freeze, one of three things might be happening. 1. Interrupts are turned off on all CPUs (as when the debugger breaks into the system). 2. The IRQLs are all >= that of the windows debug enthernet device. 3. The processor is actually halted or in some other way locked up. For a start, I'd at least like to know if the CPUs are running.
Any way I could get windows to entirely reserve one of the CPUs for just the debug driver, so that it could take the interrupts from the ethernet?
I'm going to look into event logging. I've heard that in the event of a bugcheck, events that haven't yet been saved to disk can be retrieved from the memory dump file. Any details on this? Can windbg capture event logging and display or save the events over on the host? This might be useful for getting the last events that didn't make it yet to the disk but did get sent to the debugger. I'm assuming that then the system freezes, the event logger will stop writing data to the log on the disk, too.