sx,
sxd, sxe, sxi, sxn, sxr, sx- (Set Exceptions)
The sx* commands control the action that the debugger takes
when an exception occurs in the application that is being debugged, or when
certain events occur.
Remarks
The sx command displays the list of exceptions for the current process
and the list of all nonexception events and displays the default behavior of the
debugger for each exception and event.
The sxe, sxd, sxn, and sxi commands control the
debugger settings for each exception and event.
The sxr command resets all of the exception and event filter states to
the default settings. Commands are cleared, break and continue options are reset
to their default settings, and so on.
The sx- command does not change the handling status or the break
status of the specified exception or event. This command can be used if you wish
to change the first-chance command or second-chance command associated with a
specific event, but do not wish to change anything else.
If you include the -h option (or if the cc, hc,
bpec, or ssec events are specified), the sxe, sxd,
sxn, and sxi commands control the handling status of the exception
or event. In all other cases, these commands control the break status of the exception or
event.
When you are setting the break status, these commands have the following
effects.
Command |
Status name |
Description |
sxe |
Break
(Enabled) |
When this exception occurs, the target immediately breaks into the debugger
before any other error handlers are activated. This kind of handling is called
first chance handling. |
sxd |
Second chance break
(Disabled) |
The debugger does not break for a first-chance exception of this type
(although a message is displayed). If other error handlers do not address this
exception, execution stops and the target breaks into the debugger. This kind of
handling is called second chance handling. |
sxn |
Output
(Notify) |
When this exception occurs, the target application does not break into the
debugger at all. However, a message is displayed that notifies the user of this
exception. |
sxi |
Ignore |
When this exception occurs, the target application does not break into the
debugger at all, and no message is displayed. |
When you are setting the handling status, these commands have the following
effects:
Command |
Status name |
Description |
sxe |
Handled |
The event is considered handled when execution resumes. |
sxd,sxn,sxi |
Not Handled |
The event is considered not handled when execution
resumes. |
You can use the -h option together with exceptions, not events. Using
this option with ch, bpe, or sse sets the handling status
for hc, bpec, or ssec, respectively. If you use the -h
option with any other event, it has no effect.
Using the -c or -c2 options with hc, bpec, or
ssec associates the specified commands with ch, bpe, or
sse, respectively.
In the following example, the sxe command is used to set the break
status of access violation events to break on the first chance, and to set the
first-chance command that will be executed at that point to r eax. Then
the sx- command is used to alter the first-chance command to r
ebx, without changing the handling status. Finally, a portion of the
sx output is shown, indicating the current settings for access violation
events:
|
0:000> sxe -c "r eax" av
0:000> sx- -c "r ebx" av
0:000> sx
av - Access violation - break - not handled
Command: "r ebx"
. . . |
disable : sxi bpe
enable : sxi bpe
http://stackoverflow.com/questions/9099586/how-can-i-remove-breakpoint-ntdlldbgbreakpoint0x1-in-windbg