Hi guys,
Is there a way to catch a user-process crash from the kernel debugger?
I’ve attached my kernel debugger and now I’d like it to breakpoint
when the user-process crashes so I can investigate more.
Thanks,
J
open up gflags.exe and set stop on exception in registry and kernel and
reboot the target
this will redirect all first chance exception to kernel debugger
you will have to find your needle in this haystack with this option (lots of
exceptions that get generated and handled automatically other wise will show
up in kernel debugger and you have to keep on telling windbg to go )
like below
kd> g
Integer divide-by-zero - code c0000094 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
001b:00401072 f7f1 div eax,ecx
kd> k
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012fff0 00000000 0x401072
kd> !analyze -v
Connected to Windows XP 2600 x86 compatible target at (Thu Feb 3
09:03:41.812 2011 (UTC + 5:30)), ptr64 FALSE
Loading Kernel Symbols
…
…
Loading User Symbols
…
Loading unloaded module list
…
*******************************************************************************
*
*
* Exception
Analysis *
*
*
*******************************************************************************
FAULTING_IP:
except1+1072
001b:00401072 f7f1 div eax,ecx
EXCEPTION_RECORD: ffffffff – (.exr 0xffffffffffffffff)
ExceptionAddress: 00401072 (except1+0x00001072)
ExceptionCode: c0000094 (Integer divide-by-zero)
ExceptionFlags: 00000000
NumberParameters: 0
ERROR_CODE: (NTSTATUS) 0xc0000094 - {EXCEPTION} Integer division by zero.
EXCEPTION_CODE: (NTSTATUS) 0xc0000094 - {EXCEPTION} Integer division by
zero.
or you can run the application with ntsd -d
for both this you would need windbg package on target if so then it would
be easy to debug it directly on windbg user mode i think
there is a kdbgctrl -eu for w2k3 and above but i have not messed with it yet
quote from help file
Windows can handle user-mode errors in a variety of ways. The following
sequence shows the precedence used for error handling:
- If a user-mode debugger is currently attached to the faulting process,
all errors will cause the target to break into this debugger.
As long as the user-mode debugger is attached, no other error-handling
methods will be used ? even if the *gn (Go With Exception Not
Handled)*<r16_cmds_c_3254135f-8902-45ee-a2dc-a52049ea903c.xml.htm>command
is used.
2. If no user-mode debugger is attached and the executing code has its
own exception handling routines (for example, try - except), this
exception handling routine will attempt to deal with the error.
3. If no user-mode debugger is attached, and Windows has an open
kernel-debugging connection, and the error is a breakpoint interrupt,
Windows will attempt to contact the kernel debugger.
Kernel debugging connections must be opened during Windows’ boot process.
If you are using Windows Server 2003 or a later version of Windows and wish
to prevent a user-mode interrupt from breaking into the kernel debugger, you
can use the KDbgCtrl utility with the -du parameter. For details on how
to configure kernel-debugging connections and how to use KDbgCtrl,
see Configuring
Software on the Target
Computer<bootini_pageone_dbg_06095f76-d8a9-4397-880e-d9d461b84904.xml.htm>
.
If Windows does attempt to contact a kernel debugger but there is no
debugger running at the other end of the connection, Windows will freeze
until kernel debugger is activated.
In the kernel debugger, you can use gh (Go With Exception
Handled)<r16_cmds_c_bb7ab8a9-efe6-4feb-b234-e94d27848769.xml.htm>to
disregard the error and continue running the target. You can use
gn (Go With Exception Not
Handled)<r16_cmds_c_3254135f-8902-45ee-a2dc-a52049ea903c.xml.htm>to
bypass the kernel debugger and go on to step 4.
4. If the conditions in steps 1, 2, and 3 do not apply, Windows will
activate a debugging tool. Any program can be selected in advance as the
tool to use in this situation. The chosen program is referred to as
the postmortem
debugger. This is also known as the just-in-time debugger or the JIT
debugger.
If the postmortem debugger is a standard user-mode debugger (such as CDB,
WinDbg, or Microsoft Visual Studio), this debugger will start up and break
into your application.
If the postmortem debugger is a tool for writing dump files (such as
Dr. Watson <drwatson_92d60a12-6577-4cd5-a02f-a1ea8204719a.xml.htm>), a
memory dump file will be created, and then the application will be
terminated.
so use user mode debugging in target will be much easier then debugging via
kernel mode debugger
thanks and regards
raj
On Thu, Feb 3, 2011 at 4:50 AM, Jonathon wrote:
> Hi guys,
>
> Is there a way to catch a user-process crash from the kernel debugger?
> I’ve attached my kernel debugger and now I’d like it to breakpoint
> when the user-process crashes so I can investigate more.
>
> Thanks,
> J
>
> —
> 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
>
–
thanks and regards
raj_r</drwatson_92d60a12-6577-4cd5-a02f-a1ea8204719a.xml.htm></r16_cmds_c_3254135f-8902-45ee-a2dc-a52049ea903c.xml.htm></r16_cmds_c_bb7ab8a9-efe6-4feb-b234-e94d27848769.xml.htm></bootini_pageone_dbg_06095f76-d8a9-4397-880e-d9d461b84904.xml.htm></r16_cmds_c_3254135f-8902-45ee-a2dc-a52049ea903c.xml.htm>