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.