VC Language - Best way to handle SEH and COM Exceptions

Author

Best way to handle SEH and COM Exceptions

pmac

2005-06-03, 4:02 pm

Not sure if this is the right section of the forums to post but here goes.

I work as an escalation engineer and we have an application that is using VB
and C++ dll. The VB app passes in some XML to the C++ code which calls a
database using ADO with the #import statement. The #import looks like this:

#import "C:\Program Files\common files\system\ado\m

o15.dll" no_namespace
rename("EOF","adoEOF")

If I understand everything the #import statement generates some .tlh and
..tli files that wrap ADO. Also adding error handling by calling
_com_raise_error which throws internaly _com_errors.

My problem is this. The app is throwing (maybe better to say raising) an
exception inside a C++ try block that was being eaten by the catch(...). Not
good because we are losing the exception. So I removed the catch(...) and
added a SetUnhandledExceptionFilter( HandleCrash ) in the DLLMain. When the
HandleCrash exception filter is call I call MiniDumpWriteDump which seems to
be working fine.

Is this good programming practice and will it produce the most reliable
code? When the HandleCrash is call I believe the only thing I can really do
is write a minidump and end the program. Is this write? And now the code :)

Thank you in advance for your help!

// in dllmain

SetUnhandledExceptionFilter( HandleCrash );

//
LONG WINAPI HandleCrash( LPEXCEPTION_POINTERS pExs ) {
// format file name app and date time of dump
FormatFileName( _T("app"), _T(""), file );

// message box to tell user they crashed and dump file has been writen
::MessageBox(...

// dump minidump
HANDLE hFile = CreateFile( file, GENERIC_READ | GENERIC_WRITE, ...
if( ( hFile != NULL ) && ( hFile != INVALID_HANDLE_VALUE ) ) {
MINIDUMP_EXCEPTION_INFORMATION mdei;

mdei.ThreadId = GetCurrentThreadId();
mdei.ExceptionPointers = pExs;
mdei.ClientPointers = FALSE;

MINIDUMP_TYPE mdt = MiniDumpNormal;

BOOL rv = MiniDumpWriteDump( GetCurrentProcess(), GetCurrentProcessId(),
hFile, mdt, (pExs != 0) ? &mdei : 0, 0, 0 );

if( !rv )
_tprintf( _T("MiniDumpWriteDump failed. Error: %u \n"), GetLastError() );
else
_tprintf( _T("Minidump created.\n") );

// Close the file
CloseHandle( hFile );

} else {
_tprintf( _T("CreateFile failed. Error: %u \n"), GetLastError() );
}

return EXCEPTION_EXECUTE_HANDLER;

}

try
{
// setup connection...
hr = pConnection.CreateInstance( __uuidof(Connection) );

// ... code and error checking removed for breviety ...

// setup command and parameters ...
hr = pCommand.CreateInstance( __uuidof(Command) );

// ...

// exception occuring here
hr = pCommand->Execute( NULL, NULL, adExecuteStream );

// ...

} catch( _com_error &e ) {
// log error in log file and continue...

} catch( std::exception& e ) {
// log error in log file and continue...

}
// this was originally in the code
// but was removed because the exception was being lost
catch( ... ) {
//do nothing :(
}

Doug Harrison [MVP]

2005-06-03, 4:02 pm

On Fri, 3 Jun 2005 08:01:11 -0700, pmac wrote:

> Not sure if this is the right section of the forums to post but here goes.
>
> I work as an escalation engineer and we have an application that is using VB
> and C++ dll. The VB app passes in some XML to the C++ code which calls a
> database using ADO with the #import statement. The #import looks like this:
>
> #import "C:\Program Files\common files\system\ado\m

o15.dll" no_namespace
> rename("EOF","adoEOF")
>
> If I understand everything the #import statement generates some .tlh and
> .tli files that wrap ADO. Also adding error handling by calling
> _com_raise_error which throws internaly _com_errors.
>
> My problem is this. The app is throwing (maybe better to say raising) an
> exception inside a C++ try block that was being eaten by the catch(...). Not
> good because we are losing the exception. So I removed the catch(...) and
> added a SetUnhandledExceptionFilter( HandleCrash ) in the DLLMain. When the
> HandleCrash exception filter is call I call MiniDumpWriteDump which seems to
> be working fine.
>
> Is this good programming practice and will it produce the most reliable
> code? When the HandleCrash is call I believe the only thing I can really do
> is write a minidump and end the program. Is this write? And now the code :)

If you're sure it's a structured exception and not a legitimate C++
exception, you're right, you probably can't proceed safely. For more on all
this, see:

http://members.cox.net/doug_web/eh.htm

Note that the next version of VC++ will fix catch(...) for the
"synchronous" model (/EHs), so you'll be able to write catch(...) without
fear of eating SEs.

--
Doug Harrison
Microsoft MVP - Visual C++

pmac

2005-06-03, 8:59 pm

Thanks for the reply!

Still working through the /EH switches and wrapping my head around that :)

I post back if I have questions.

# Peter

"Doug Harrison [MVP]" wrote:

> On Fri, 3 Jun 2005 08:01:11 -0700, pmac wrote:
>
>
> If you're sure it's a structured exception and not a legitimate C++
> exception, you're right, you probably can't proceed safely. For more on all
> this, see:
>
> http://members.cox.net/doug_web/eh.htm
>
> Note that the next version of VC++ will fix catch(...) for the
> "synchronous" model (/EHs), so you'll be able to write catch(...) without
> fear of eating SEs.
>
> --
> Doug Harrison
> Microsoft MVP - Visual C++
>

Sponsored Links