What is a First Chance Exception?

[Dave C]

If I create a new project in VS2008 and run it with all the debugger's exception breaks enabled I get a first chance exception thrown when the application starts up. The project is as created by the wizzard, with none of my own code added yet.

The same kind of project created in VC 6.0 and imported into VS2008 will also throw an exception, but the breakpoint I get is somewhere else. The exceptions are the typical 0xC000005 access violation writing location 0x0000010 that I see mentioned here often.

Is this indicating that something is actually wrong? Can someone explain why this happens?

The project is an MFC SDI exe with CFormView as the base class and MFC in a static library.

Thanks

[S_M_A]

First chance exeptions in other code than yours isn't anything to be bothered with. It only means that something happened in that module but the code took care of it.

Edit: Eh... I was obviously more tired than I thought yesterday...

[VladimirF]

I have just created a few MFC projects in VS 2008, and none of them has Access Violation.
First – of course, it’s a problem! Yes, the “first-chance” simply means that an exception was thrown, and likely caught later (or else you would have a more serious “uncaught exception”). But what would be a reason for someone to write at the unknown (NULL?) memory location?
You could use this as a test, just like MS does in its IsBadPtr family of functions: see if it throws, than it’s bad. I don’t think that this is a good practice.
Anyway, catching an exception is NOT an equivalent of “handling” the situation. Was something done to recover and reattempt the failed action? Or was some piece of data lost?

[Dave C]

The point where the debugger breaks is within ntdll (I get the disassembly window) in one case, and in _mtinitblocks() (mlock.c) in the other case. I'm trying to understand if there's something wrong with my development environment that causes "bad" code to be created right from the start. My development machine has multiple versions of Visual Studio, from 6.0 through VS2008. They have always seemed to coexist without any problems and I have no idea if there could be any conflicts in libraries or something.

If you could create this type of project without any first chance exceptions, why cant I?

[VladimirF]

The point where the debugger breaks is within ntdll...

That only means that you fed bad data to ntdll.

If you could create this type of project without any first chance exceptions, why cant I?

I don’t know. But I could look into your project if you zip it (no Debug/Release and intermediate stuff) and attach here.

[Dave C]

Thanks. Zip attached. I had to delete the .ncb file to stay within size limits.

[Paul McKenzie]

Thanks. Zip attached. I had to delete the .ncb file to stay within size limits.

I built your program using VS 2008, ran it, no exceptions occur.

Regards,

Paul McKenzie

[John E]

If an exception occurs while you're running your app in the debugger, the debugger offers your app a "first chance" at handling the exception. Or to put it another way, you can set up a handler in your app to intercept exceptions before they get passed to the 'C' runtime (which then tries to pass them to a conventional handler mechanism, such as catch). If nothing handles the exception you get the dreaded "unhandled exception" error.

A first chance exception doesn't necessarily indicate a problem in your code. It might do or it might not - which is one reason why you might want to intercept all exceptions, so you could examine them and find out.

[Dave C]

I built your program using VS 2008, ran it, no exceptions occur.

Regards,

Paul McKenzie

Paul -

Thank you very much for taking the time to do that. But now I'm even more baffled, because that project throws an exception on startup on both of my two development PCs.

Very odd.

[VladimirF]

But now I'm even more baffled, because that project throws an exception on startup on both of my two development PCs.

I too ran you project (both Debug and Release) on Win 7 - no exception.
When you do break on that exception, what is in the call stack?