>>First-chance exception in bonder2.exe (GDI32.DLL): 0xC0000005: Access Violation.
Why would you want to do that?
'First-chance exception in xxx...' just means that a function from within the 'xxx' caused an access-violation exception that was handled successfully inside the SEH frame that was active when the exception occurred. You can think of it being the same as if you use code like this:
long l;
__try // set up current SEH frame
{
CopyMemory ( &l, 0, sizeof ( long)); // read from 0x00000000
}
__except( EXCEPTION_EXECUTE_HANDLER)
{
puts ( "We knew that this would go wrong...");
}
So let's hope that the MS progrmmer knew what they were doing ;-)
(Additional info: MS KB Article Q105675)
The article can be found at http://support.microsoft.c
A first chance exception is called so as it is passed to a debugger before the application 'sees' it. This is done by sending a 'EXCEPTION_DEBUG_EVENT' to the debugger, which can now decide whether it is passed to the apllication to handle it or 'ignore' it (e.g. like an 'EXCEPTION_BREAKPOINT' aka 'int 3'). If the exception isn't handled, it becomes a '2nd chance' exception, the debugger 'sees' it the 2nd time and will usually terminate the program (without using a debugger, these exceptions end up at 'UnhandledExceptionFilter(
In short: This message is only generated by a debugger & you can safely ignore it...
Main Topics
Browse All Topics
by: jtbaloghPosted on 2004-01-29 at 09:57:55ID: 10227617
>> only contains this message and not the others before ...
Not sure what you mean by this because the output window has the capability to hold thousands of previous messages.
>> ... find the place where this occurs ...
Its too bad this type of debugging can not benefit from adding try/catch() to your program because the error occurs in GDI32.DLL instead. You can however trace the program flow before and after it shows the error. It will lead you closer to finding the command you used that accessed the GDI DLL.
Like any type of debugging, start adding/manipulating code in each procedure you think was running at the time to give you indicators or markers of where its been or what it was recently doing. For example, one straightforward technique is to display information in the debug window periodically yourself to track code, with,
#include <crtdbg.h> // for assert, verify, rpt, etc.
And in your main startup procedure, add,
_CrtSetReportMode(_CRT_WAR
_CrtSetReportFile(_CRT_WAR
_CrtSetReportMode(_CRT_ERR
_CrtSetReportFile(_CRT_ERR
_CrtSetReportMode(_CRT_ASS
_CrtSetReportFile(_CRT_ASS
And in your procedures, add where you want to display data to the output window with,
void AnyProcedure()
{
// <-- some of your original code for the procedure here
_RPT4(_CRT_WARN,"%s, %s, %s, %s\n","1","","",""); // debug.print, #my name
// <-- some of your original code for the procedure here
_RPT4(_CRT_WARN,"%s, %s, %s, %s\n","2","","",""); // debug.print, #my name
// <-- some of your original code for the procedure here
_RPT4(_CRT_WARN,"%s, %s, %s, %s\n","3","","",""); // debug.print, #my name
// <-- some of your original code for the procedure here
// #my name only used to easy to globally search for the comment in the
// entire project and delete the related code. No use keeping it forever, I guess.
// Also using _RPT1, _RPT2, _RPT3, is an alternative.
}
Hope that helps lead you in a positive direction.
Joseph