Compartilhar via

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

  • Artigo

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

  • Anonymous
    January 30, 2004
    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.
  • Anonymous
    January 30, 2004
    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.
  • Anonymous
    January 30, 2004
    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?
  • Anonymous
    February 01, 2004
    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.
  • Anonymous
    February 02, 2004
    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.
  • Anonymous
    February 03, 2004
    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.
  • Anonymous
    February 15, 2004
    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.
  • Anonymous
    February 16, 2004
    The comment has been removed
  • Anonymous
    February 18, 2004
    The comment has been removed
  • Anonymous
    February 25, 2004
    Does some one know how to let VS debugger to stop on first chance Access Violations? It seems there is no such an option.
  • Anonymous
    February 26, 2004
    Yang Li: Open the Exceptions dialog, go to the Win32 item, open it, find Access Violation and change it to suit.
  • Anonymous
    April 28, 2004
    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.
    Thanks
    sam
  • Anonymous
    September 17, 2006

    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 ?