Why the VS Debugger does not stop on first chance Access Violations (by default)

Today we got some alpha feedback about “Whidbey” regarding the debuggers default choice of exception handling for certain win32 exceptions, specifically access violation. The customer had an access violation in some native code, which ended up being caught by the COM interop layer and translated into a managed exception in his C# code. He didnt realize this was the cause for the longest time, all he saw was the unexplicable managed exception, so he opened a bug for us to change the default.

The reason the default for first-chance AVs does not stop is that sometimes Windows calls will AV, and then catch the exception themselves and carry on happily. If we did default to stopping on first chance AVs we would stop users in some strange place in say kernel32.dll and many would be very confused.

We know this from the multifarious newsgroup postings from users hitting a “hard-coded breakpoint” in NTDLL, despite them never having set such a breakpoint. This is really an int 3 deliberately executed by the debug version of NTs heap manager. It results in very confused users, as the callstack often shows nothing except a couple of hex addresses in ntdll. If they installed system symbols, they would get a fuller and more useful callstack which would include their app code, giving them more of a clue, but many users dont know about this.

Expert users can of course change the AV exception to break on first chance, and these users stand less of a chance of being confused by a mystery AV down in the bowels of Windows, and they probably have symbols installed too.

In the end I explained this to the customer and resolved the bug as By Design.

MSFT disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights.

Comments (13)

  1. Michael Ruck says:

    I think a more appropriate solution would be to force an installation of debug tools (including VS.NET) to include system symbols and to turn on these exceptions by default.

    If I remember right even the heap manager only breaks for heap corruptions and other memory errors.

  2. Andy Pennell says:

    VC6 used to ship system symbols, but they became out of date once the next SP shipped for NT4. Symbol server means that once set up, users can always get matching symbols and keep them up to date automatically.

  3. Woo Seok Seo says:

    Right, every developer should set up their symbol server. Why don’t you set up symbol server during VS.NET installation or as a option?

  4. Stefan Niermann says:

    I don’t need the debug symbols for the os libraries when I have an exception in my own code (I have them installed, because I want to see what’s on my call stack! That’s an important information). The exception occured in my native dll (I am that customer), the interop layer caught it and I got a null reference exception in the Main() of my application. The information content of that is just: "There is a bug somewhere in your code!"

    When I debug managed AND unmanaged code, the debugger must break for every exception of that kind like VC 6 did. I’m used to that behaviour and it took me some hours to find out that I have to change settings of my debugger.

  5. Dmitriy Zaslavskiy says:

    I actually like current default setting in Whidbey and when I need to I change the defaults.

    The feature I would like to see in the debugger is to able specify in which .dll(s) to break on first chance exceptions.

  6. Andy Pennell says:

    The replies indicate the difficulty of choosing the "correct" default: you can’t please all of the users all of the time.

    Dmitry has hit the "real" solution: using the DLL name as a criteria when deciding whether to break on exceptions or not.

    VS "Whidbey" does have an improved level of control over managed exceptions, but native exception handling is essentially unchanged.

  7. Pavel Lebedinsky says:

    Stefan: I don’t think VC6 would break on 1st chance AVs by default, either. Also, in this particular case you might not need OS symbols but in general it’s better to have them. Quite often a problem in user program manifests itself as an AV deep in the OS code.

    The right thing to do IMO would be something like !analyze -c command in windbg. It basically allows you to ignore known breaks based on various conditions. But unknown AVs should break on 1st chance by default.

  8. Stefan Niermann says:

    Pavel: VC6 doesn’t stop on all 1st chance exceptions by default. I have written COM servers for use with VB6. VB6 throughs some exceptions during debugging and VC6 doesn’t stop. But it stops when I’m using invalid pointers in my own code! I don’t need the OS debug symbols for that(although I have them and find them very usefull!!). What I mean is that the debugger should stop for the exceptions in my own code like it did before regardless if it is a "mixed" or a managed solution.

  9. Pavel Lebedinsky says:

    Stefan: I’m almost 100% sure that VC (any version) doesn’t behave this way. It has no concept of "your code" vs. "OS code". With default settings, it doesn’t stop on 1st chance AVs regardless of where they occur.

    Most likely when you were using invalid pointers yourself the process would just crash, so it was a 2nd chance AV. It’s also likely that VB6 and/or COM runtime was handling 1st chance AVs and returning an error in which case debugger wouldn’t stop because there was no 2nd chance notification.

    Also, consider the case where your code passes an invalid pointer to a system API. The bug is clearly in your code but the crash will happen in the system API, sometimes several levels deep. There is no way the debugger can know where the bug comes from.

  10. Yang Li says:

    Does some one know how to let VS debugger to stop on first chance Access Violations? It seems there is no such an option.

  11. Andy Pennell says:

    Yang Li: Open the Exceptions dialog, go to the Win32 item, open it, find Access Violation and change it to suit.

  12. Sam says:

    How can i make my app know where the error is. I am experiencing the same problme as discussed above and I want to know the VC settings for my DLL, so that I can pinpoint the problem.



  13. Abhijeet Nevaskar says:

    I enabled all Win32 exceptions to break in debug. still I am getting AV exception in my app which is not breaking in VS 2005 .

    can anybody help ?

Skip to main content