WinDbg hangs system

This seems like a pretty basic question, however I have not been able to find an answer on the web.

The app and driver does not crash the system normal. However, when I run it through WinDbg the system hangs as the application is exiting. I am running WinDbg on the Test System. It is running a released version of Win 7.

Any idea what I am doing wrong?

Does the whole system hang, or just the application?

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@intel.com
Sent: Thursday, October 21, 2010 7:35 PM
To: Kernel Debugging Interest List
Subject: [windbg] WinDbg hangs system

This seems like a pretty basic question, however I have not been able to
find an answer on the web.

The app and driver does not crash the system normal. However, when I run it
through WinDbg the system hangs as the application is exiting. I am running
WinDbg on the Test System. It is running a released version of Win 7.

Any idea what I am doing wrong?


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

When I run it on the Test System, it locks up the app. Hitting ‘g’ just gets a “No debuggee” message. At that point there is no way to recover other than closing WinDbg.

When running remotely, using either WinDbg connecting to test system, ‘ntsd’ on the test system with WinDbg on the host. The entire test system locks up, without any way of recovering other than a cold reset.

If you’re getting a ‘no debuggee’ message, that means that the application
either terminated or that you never were debugging it, I think.

When you say ‘remotely,’ you mean remote debugging the application of via
ntsd/windbg, correct?

Also, did you boot with kernel debugging enabled? If so, perhaps it’s
trying to breakin to the kernel debugger.

If you could describe your exact debugging setup - all command
lines/boot.ini/bcedit settings - that would be helpful.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@intel.com
Sent: Thursday, October 21, 2010 11:19 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] WinDbg hangs system

When I run it on the Test System, it locks up the app. Hitting ‘g’ just
gets a “No debuggee” message. At that point there is no way to recover
other than closing WinDbg.

When running remotely, using either WinDbg connecting to test system, ‘ntsd’
on the test system with WinDbg on the host. The entire test system locks
up, without any way of recovering other than a cold reset.


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

If you run an application under WinDBG, when you close the application
there’s a final breakpoint in NtTerminateProcess. Is this what you mean:

ntdll!NtTerminateProcess+0x12:
7753fc52 83c404 add esp,4
0:000> g
^ No runnable debuggees error in ‘g’

?

If so, this is expected behavior. The app drops into the debugger before
exiting and the only way to finish up is to end the debugging session. You
can do this either by closing WinDBG or pressing Shift+F5 (which terminates
the debugging session without closing WinDBG).

If you don’t want this to happen you can shut off the process terminate
breakpoint with the -G command line option.

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@windbg…
> When I run it on the Test System, it locks up the app. Hitting ‘g’ just
> gets a “No debuggee” message. At that point there is no way to recover
> other than closing WinDbg.
>
> When running remotely, using either WinDbg connecting to test system,
> ‘ntsd’ on the test system with WinDbg on the host. The entire test system
> locks up, without any way of recovering other than a cold reset.
>