During debugging, when fatal error happens in target, what to do ?

NTDEV
1

For now, if windbg says fatal error,
i basically hit “go” and crashes the target then reboot.

Really wasting time, so what’s the correct way pls ?

thanks !

2

Understanding what’s the crash or and taking care of it is the best way.
What you can also do is ‘.reboot’

Shay

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, July 05, 2010 10:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] During debugging, when fatal error happens in target,
what to do ?

For now, if windbg says fatal error,
i basically hit “go” and crashes the target then reboot.

Really wasting time, so what’s the correct way pls ?

thanks !

NTDEV 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

3

On Mon, 5 Jul 2010 10:04:45 -0400 (EDT)
xxxxx@hotmail.com wrote:

For now, if windbg says fatal error,
i basically hit “go” and crashes the target then reboot.

Really wasting time, so what’s the correct way pls ?

When a fatal error occurs, WinDBG stops to give you a chance to examine
the stack trace and analyze the crash. Continuing causes the memory
dump to start so you can do postmortem debugging when Windows reboots.
If you don’t want to do online debugging, you probably shouldn’t have
WinDBG attached to the target.

–
Bruce Cran

4

Thanks for the replies, now say i quickly find my bug, and want to try the new fix.
Do i still have to reboot the target ?
Is there any other ways like change the target memory from windbg, roll back to the previous instructions etc.
so target doesn’t need to reboot ?

5

The simplest is to reboot. You are too far into the crash to easily
back out. Note: also, if you find the problem, you can easily on your
development/debug system modify your driver to fix the error, then
reboot and with .kdfiles set right, get your new driver loaded when the
system reloads.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Posted At: Monday, July 05, 2010 11:27 AM
Posted To: ntdev
Conversation: During debugging, when fatal error happens in target,
what to do
?
Subject: RE: During debugging, when fatal error happens in target,
what to do
?

Thanks for the replies, now say i quickly find my bug, and want to try
the new
fix.
Do i still have to reboot the target ?
Is there any other ways like change the target memory from windbg,
roll back
to the previous instructions etc.
so target doesn’t need to reboot ?

__________ Information from ESET Smart Security, version of virus
signature
database 5252 (20100705) __________

The message was checked by ESET Smart Security.

http://www.eset.com

6

The only case when you can “recover” is to have assertions in your code.
If assertion is hit you can usually skip

-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Posted At: Monday, July 05, 2010 4:27 PM
Posted To: ntdev
Conversation: During debugging, when fatal error happens in target, what
to do ?
Subject: RE: During debugging, when fatal error happens in target, what
to do ?

Thanks for the replies, now say i quickly find my bug, and want to try
the new fix.
Do i still have to reboot the target ?
Is there any other ways like change the target memory from windbg, roll
back to the previous instructions etc.
so target doesn’t need to reboot ?

7

Please ignore my last post. My NNTP client went crazy for some reason.

Kris

8

!analyze -v is always your friend. It may give you the line of code in your
driver that faulted and caused the system to panic. Look around and see what
you can see. Check out any WDF objects you may have. Run the IRP chains you
may find using !process. Oh, just because YOUR driver may not be in the call
stack, never assume it was NOT your driver. Given a functional system and
your driver, it most likely IS your driver incorrectly completing an IRP or
d’refing a NULL pointer.

If you can, enable Driver Verifier and, if a KMDF driver, WDF Verifier
before the next crash.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Monday, July 05, 2010 9:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] During debugging, when fatal error happens in target, what
to do ?

For now, if windbg says fatal error,
i basically hit “go” and crashes the target then reboot.

Really wasting time, so what’s the correct way pls ?

thanks !

NTDEV 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

9

Nope. The system is going to crash and there is little you can do about it,
except either hit GO, .reboot, or power down. You can set .kdfiles so it
replaces the faulting version of your driver with the re-built version.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Monday, July 05, 2010 10:27 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] During debugging, when fatal error happens in target,
what to do ?

Thanks for the replies, now say i quickly find my bug, and want to try the
new fix.
Do i still have to reboot the target ?
Is there any other ways like change the target memory from windbg, roll back
to the previous instructions etc.
so target doesn’t need to reboot ?

NTDEV 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

10

On 05/07/2010 17:27, Krzysztof Uchronski wrote:

Is there any other ways like change the target memory from windbg, roll
back to the previous instructions etc.
so target doesn’t need to reboot ?

Here’s a bit of basic information. For more info, go to the WinDbg list,
or read the WinDbg help file, which is pretty comprehensive.

If the error is small, then there are some strategies:

  • For functions which return a status value, use ?? to modify the return
    value of a function:

e.g, for function: NTSTATUS foo() {
NTSTATUS status;
}

in the debugger, before the function exits, type: “?? status = 0xC0000001”,

which will fake up a STATUS_UNSUCCESSFUL return.

You can change arbitrary variables using ??, or change memory directly
using the “d” and “e” commands.

Another option is to use “Ctrl-Shift-I” keyboard shortcut, or “Set
Current Instruction” menu command to skip over code that is clearly bad

  • you put the cursor on the source line you want to go to an invike the
    command. You can also do this by setting the instruction pointer
    register in the debugger using the “r” register command:

“r eip= ”

Of course, this should be used with care, it’s rather easy to crash the
machine - try to skip only to a point that expects the same context and
stack state (i.e. same function, same block level).

MH.

11

Martin,

thanks very much for the hint, this is exactly i’m looking for !