QUOTE(Stalker @ 4 Sep, 2008 - 12:49 AM)
QUOTE(perfectly.insane @ 3 Sep, 2008 - 08:09 PM)
You can trap access violations with the __try/__except blocks in Microsoft C/C++. There are ways to do this in MinGW also, with some tricks.
I know, I tried that. I could encapsulate the entire program in a giant __try __except block, but it doesn't catch it. It's not the try block, because I can use throw and it will catch the same exception.
I'm using MVC++, btw.
That's strange. I never thought __try/__except worked with C++ exception handling. I have read that try/catch is supposed to implement SEH in Microsoft C++ though.
I've found times that SEH does not work properly for me, especially when the exception occurs during a message processing function (a window proc or a dialog proc). In that case, it seems like you need a __try/__except in that function also, possibly as there might be a handler installed in the API functions as well, handling the exception before your application gets a chance. But then again, that's been my experience with implementing a SEH library for MinGW, so it might not be entirely accurate.
QUOTE
It's not the code, I finally realized. I can recreate the exception in nearly any Open dialog in any program.
It's one of the following DLLs loading when I use GetOpeFileName()
'xpsp2res.dll'
'pdfshell.dll' -- Adobe reader
'msvcr80.dll'
I'm betting it's abobe.
Well, using a debugger would tell you for sure. A good debugger like WinDbg will break on an access violation, without having to step through everything to figure out where it is occurring. Visual C++ will also probably give the source, but then again, the problem could be more complicated and the module with the access violation may not be the actual module with the fault (passing a bad pointer to a function in another module, for example).
| 