Diagnosing computer freeze when windbg can't break in

Hi,
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.

Thanks.

Michael

Tim Roberts gave you some good suggestions in his response over on NTDEV.
To that i will add

  • Turn on driver verifier for your driver. If the computer is freezing verifier probably will have something to say and might cause a bugcheck for you before everything freezes up. Plus its just good practice to have verifier enable when you are developing a driver.
  • As Tim said, put some debug messages in the code. Take a look at DbgPrintEx. Once setup, it will send messages straight to your windbg window. Sprinkle some debug statements through your code and follow the trail.
  • Do both your systems have USB 3.0 ports? If so i would suggest using windbg over USB3. I’ve had better luck with that than with ethernet although i admit its been a while since i tried windbg for kernel driver over ethernet.

Hope that helps
Eric

I do have driver verifier enabled.  What does “have something to say”
mean, and how would I read any such information?

Regarding USB 3.0, don’t I need a special debug cable, and would it be
readily available at a place like BestBuy, Walmart, or Fry’s?  I’d
rather go out and buy a cable in person than order it online and have to
wait for delivery, and if it isn’t useful, it would be easier to return
to a store than online.

Are you saying that possibly the USB debug driver might be better at
responding to the host debugger than the Ethernet debug driver?

On 3/7/2018 9:55 PM, "xxxxx@yahoo.com windbg"@lists.osr.com wrote:

Tim Roberts gave you some good suggestions in his response over on NTDEV.
To that i will add

  • Turn on driver verifier for your driver. If the computer is freezing verifier probably will have something to say and might cause a bugcheck for you before everything freezes up. Plus its just good practice to have verifier enable when you are developing a driver.
  • Do both your systems have USB 3.0 ports? If so i would suggest using windbg over USB3. I’ve had better luck with that than with ethernet although i admit its been a while since i tried windbg for kernel driver over ethernet.

Hope that helps
Eric


WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:
>


Michael Rolle
xxxxx@rolle.name
408-313-8149</http:></http:>

"xxxxx@yahoo.com windbg"@lists.osr.com wrote:

  • Do both your systems have USB 3.0 ports? If so i would suggest using windbg over USB3. I’ve had better luck with that than with ethernet although i admit its been a while since i tried windbg for kernel driver over ethernet.

That’s the first time I’ve ever heard anyone praise WinDbg over USB.  I
have always preferred 1394, and now with Win 10 Ethernet always seems to
work.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.