FIX: Access Violation in MSDAER.DLL with _com_error Exceptions

This article was previously published under Q173645
This article has been archived. It is offered "as is" and will no longer be updated.
When using the compiler #import feature, ADO, the OLE DB 1.1 ODBC Provider,and trapping _com_error exceptions, an access violation occurs inMSDAER.DLL when closing an application.
A method created with #import can throw a _com_error exception. When itthrows the exception, Release() is not called on the IErrorInfo pointerwhich is returned from GetErrorInfo(). This leaves the internal errorobject in the OLEDB ODBC Provider stranded which causes the accessviolation to occur as the application shuts down.
Create a macro which can be used to Release() the IErrorInfo interface atthe end of the "catch" block. For example:
   #define BUGFIX_RELEASE_IERRORINFO(error) \            IErrorInfo * pErr = error.ErrorInfo();  \            pErr->Release();                        \            pErr->Release();				
Here is an example of how you would use it:
   try   {     //.... call a #import generated method     if ( m_connection == NULL )   {      if(S_OK == m_connection.CreateInstance("ADODB.Connection.1", NULL,   CLSCTX_INPROC_SERVER))         m_connection->Open(varDataSource, varUserId, varPwd);      }   }   catch(_com_error & err)   {     // Error handling code...     ::MessageBox(NULL, (LPCSTR)err.Description(), _T("ADO Error"), MB_OK);     BUGFIX_RELEASE_IERRORINFO(err);   }				
Microsoft has confirmed this to be a bug in the Microsoft products listedat the beginning of this article. This bug has been fixed in Visual Studio97 Service Pack 3 and Visual C++ version 6.0.

For more information, please see the following article in the MicrosoftKnowledge Base:
170365INFO: Visual Studio 97 Service Packs - What, Where, and Why
unhandled exception AV

Article ID: 173645 - Last Review: 11/01/2013 20:59:00 - Revision: 2.0

Microsoft Visual C++ 5.0 Enterprise Edition

  • kbnosurvey kbarchive kbbug kbvc600fix kbvs97sp2fix KB173645