Disabling stopping at first chance exceptions in Windbg

[Mark C]

Hi,

I'm using WinDbg 6.6.0007.5 (the only one I can find to download on
Microsofts site) and I'm trying to debug an application. I need to
disable stopping at all first chance exceptions in WinDbg (as we are
not interested in these, and having WinDbg halt the application when
these occur is causing the application being debugged to stop working
(even after resuming the debugging)). I am currently using the
following command line to run WinDbg (because the application I'm
looking at is on a virtual server 2005 image):

"C:\Program Files\Debugging Tools for Windows\windbg.exe" -xd av -xd ch
-xd sov -g -G -k com:port=\\.\pipe\com2,pipe,resets=0,reconnect"

I still get first chance exceptions shown for NULL and Invalid Handle
exceptions (I know these are caught in the code).

The help file for Application Verifier, mentions that "-xd av -xd ch
-xd sov" should work, but WinDbg still halts at first chance
exceptions. I can't find anything in the Windbg help about this and the
only help I can find in Microsofts' KB site are for an older version of
WinDbg that has an 'Options' menu, which this version of WinDbg does
not have. I cannot see any way of easily telling WinDbg not to halt on
First Chance Exceptions.

Any help on configuring WinDbg to NOT stop at first chance exceptions
would be greatly appreciated.

Thanks in Advance,

Mark Crossland
QA Engineer,
C2C Systems Ltd

[Pavel Lebedinsky [MSFT]]

Looks like you're doing kernel debugging. By default (unless
the "stop on exception" flag has been enabled using gflags.exe)
windbg should not stop on user mode access violations or stack
overflows. I think only breakpoint exceptions are automatically
caught by kernel debugger in the default configuration.

Do you have apverifier enabled for your application? If yes
then you're probably seeing verifier stops which are basically
breakpoints.

If appverifier is not enabled, can you paste the output you
get in windbg when you hit a 1st chance AV?

--
This posting is provided "AS IS" with no warranties, and confers no
rights.

[Mark C]

Thanks for the response. I am doing kernel mode debugging of my
application and it looks like they are indeed Verifier Stop messages.
An example is below:

"Page heap: pid 0x930: page heap enabled with flags 0x3.
AVRF: AOnePolService.exe: pid 0x930: flags 0x80000001: application
verifier enabled
AVRF: failed to initialize verifier logging (C000003A).
AVRF: verifier.dll provider initialized for AOnePolService.exe with
flags 0x80000001

=======================================
VERIFIER STOP 00000303 : pid 0x930: NULL handle passed as parameter. A
valid handle must be used.
00000000 : Using NULL handle.
00000000 : Not used.
00000000 : Not used.
00000000 : Not used.
=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.
=======================================
Break instruction exception - code 80000003 (first chance)
7c822583 cc int 3"

and

"=======================================
VERIFIER STOP 00000300 : pid 0x930: Invalid handle exception for
current stack trace.
C0000008 : Exception code.
046FF6A0 : Exception record. Use .exr to display it.
046FF3C4 : Context record. Use .cxr to display it.
00000000 : Not used.
=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.
=======================================
Break instruction exception - code 80000003 (first chance)
7c822583 cc int 3"

Is there any way to stop App Verifier issuing this stop on a global
basis (I'm using App Verifier 3.3.0045)?

Thanks again,
Mark

[Mark C]

The following is in the help for AppVerifier:

"Some Application Verifier actions can result in an exception being
raised. The debugger must be set to catch these exceptions on the
second chance, because Application Verifier itself will be handling the
first chance exceptions.

The exceptions raised are of three types:

* An access violation exception (0xC0000005) is generated if the heap
option detects a heap buffer overrun. In some cases, the Check system
path usage option can cause an access violation as well.

* An invalid handle exception (0xC0000008) is generated when the Detect
invalid handle usage option detects an invalid handle operation.

* A stack overflow exception (0xC00000FD) is generated when the Check
for adequate stack option detects that the initial stack was too short.

The easiest way to prepare for these events is to start the debugger on
a command line as follows:

windbg -xd av -xd ch -xd sov ApplicationCommandLine"

[Pavel Lebedinsky [MSFT]]

Is there any particular reason why you're using kernel debugger
for this? User mode issues are usually a lot easier to debug
from user mode. Appverifier help that you quoted in another
reply certainly talks about windbg running as a user mode
debugger.

Regarding the breaks, the best course of action here would
be to fix the issues appverifier complains about. Invalid handle
exceptions in particular are very bad. Without verifier they
can result in all kinds of undefined behavior.

If you can't fix the breaks (for example, if they happen in 3rd
party code), try disabling them using "Verified Stop Options"
in appverifier UI.

[Mark C]

Yes. There is a reason for using Kernal Mode debugging. The application
in question consists of 5 separate executables that run concurrently on
the same system. 3 of them are services and I need to be debugging them
as they start and stop - they cannot be started from a command line. So
if I use user mode debugging, I must either start the application via
the command line (which isn't possible) or attach WinDbg to an already
running process which means that I can't debug startup of the services.
Thus it was easier to set up kernal mode debugging than user mode
debugging.

Oh, and I'd like to point out that some of the first chance errors
occur when I open and close the MMC to look at the services manager. I
can't fix those, but I can't turn them off either as another part of
the application uses the MMC in order to talk to the services. If I
went and turned them off for each process, I would have to perform 1700
mouse clicks through the GUI (4 for each of the 85 stop options because
the AppVerifier GUI isn't smart enough the remember my settings if I
click on another Verifier Stop option within the same dialog before
clicking OK, times 5, once for each application).

Any more suggestions would be greatly appreciated.

Mark

On 24 Jan, 07:32, "Pavel Lebedinsky [MSFT]" <p...@online.microsoft.com>
wrote:

> > basis (I'm using App Verifier 3.3.0045)?- Hide quoted text -- Show quoted text -

[Pavel Lebedinsky [MSFT]]

"Mark C" wrote:

> Yes. There is a reason for using Kernal Mode debugging. The application
> in question consists of 5 separate executables that run concurrently on
> the same system. 3 of them are services and I need to be debugging them
> as they start and stop - they cannot be started from a command line. So
> if I use user mode debugging, I must either start the application via
> the command line (which isn't possible) or attach WinDbg to an already
> running process which means that I can't debug startup of the services.

Another option is to use Image File Execution Options as described here:

http://support.microsoft.com/kb/824344

(if your services are not running as System which means you can't make
them run on the interactive desktop for debugging, you'll also need to
use -server switch with cdb/ntsd and then connect with windbg -remote)

Or you could attach to services.exe and do ".childdbg 1". Then every
process started by the SCM will automatically be debugged (once all
your services are started, you can use .detach to detach from the
processes you don't actually want to debug, including services.exe itself).
If I had to debug 3 separate services I would probably use this method.

> Oh, and I'd like to point out that some of the first chance errors
> occur when I open and close the MMC to look at the services manager. I
> can't fix those, but I can't turn them off either as another part of
> the application uses the MMC in order to talk to the services. If I
> went and turned them off for each process, I would have to perform 1700
> mouse clicks through the GUI (4 for each of the 85 stop options because
> the AppVerifier GUI isn't smart enough the remember my settings if I
> click on another Verifier Stop option within the same dialog before
> clicking OK, times 5, once for each application).

IIRC, MMC used to generate (and handle) some 1st chance AVs.
If that's what you're seeing, you can disable "exceptions" test for
mmc.exe. This should fix verifier breaks. A user mode debugger
would still break on those AVs but this can be suppressed with -xd av.

If you're seeing something else (for example, invalid handle
exceptions) you should investigate what causes them.