Hi Hugo,
Thank you for the link - I definitely will read it later today.
> [...] I would put my money on the debugger actually generating the exception.
My understanding is that it is OS that detects illegal operation (access to the protected memory, in our case) and throws the exception to give a chance for the software to handle this gracefully. If this first chance exception is not handled, then OS throws second chance exception that usually terminates the application.
I think that practically the same is said on the article that I referenced:
http://support.microsoft.com/kb/105675/en-usA quote from there:
==========
[...] if the application is being debugged, the debugger sees all exceptions
before the program does. This is the distinction between the first and second chance exception: the debugger gets the first chance to see the exception (hence the name). If the debugger allows the program execution to continue and does not handle the exception, the program will see the exception as usual. If the program does not handle the exception, the debugger gets a second chance to see the exception. In this latter case, the program normally would crash if the debugger were not present.
==========
Actually, assumption that the tested application did not crash and the quoted excerpt was the reason of why I wrote that the reported first chance exception may be ignored if it is expected by the tested application's design.
Do you think that I am wrong somewhere? (I am not exceptions guru and would like to get some knowledge in this area, that is why I am wondering about your opinion...)
