Acces Violation with oledb CoUninitialize() instruction
-
Hi, I use Visual C++ 6.0 SP 4 , SQL Server and oledb I create a class to connect to my database. In my constructor i initialize com library like this : CoInitialize(NULL); In my destructor i release com library like this : CoUninitialize(); If i use this class to execute for exemple an sql query ( store procedure), my functions open, execute, close,... work. But if i close my application ( OnOK ) , two seconds later i obtain the following acces violation message : EXCEPTION(c0000005 acces,@40f919) EBP184f0b8 EIP40f919) ASM 45 fc 8b 08 8b 01 52 ff 50 08 8b e5 5d c3 cc cc cc cc cc cc EAX:184f618 EBX:dc0110 ECX:383439 EDX:383439 ESI:dc0064 EDI:184f664 ESP:184f0b4 The suspect function is _Release() throw() which is in a Visual C++ include file ( in Include\COMIP.H ) // Releases only if the interface is not null. // The interface is not set to NULL. void _Release() throw() { if (m_pInterface != NULL) { m_pInterface->Release(); } } But if i comment out CoUninitialize() instruction, my code work without acces violation. Can anybody help me? Best regards, Cheickna:confused:
-
Hi, I use Visual C++ 6.0 SP 4 , SQL Server and oledb I create a class to connect to my database. In my constructor i initialize com library like this : CoInitialize(NULL); In my destructor i release com library like this : CoUninitialize(); If i use this class to execute for exemple an sql query ( store procedure), my functions open, execute, close,... work. But if i close my application ( OnOK ) , two seconds later i obtain the following acces violation message : EXCEPTION(c0000005 acces,@40f919) EBP184f0b8 EIP40f919) ASM 45 fc 8b 08 8b 01 52 ff 50 08 8b e5 5d c3 cc cc cc cc cc cc EAX:184f618 EBX:dc0110 ECX:383439 EDX:383439 ESI:dc0064 EDI:184f664 ESP:184f0b4 The suspect function is _Release() throw() which is in a Visual C++ include file ( in Include\COMIP.H ) // Releases only if the interface is not null. // The interface is not set to NULL. void _Release() throw() { if (m_pInterface != NULL) { m_pInterface->Release(); } } But if i comment out CoUninitialize() instruction, my code work without acces violation. Can anybody help me? Best regards, Cheickna:confused:
Yeah, I think, the problem is the following: when you call a destructor, the code within the destructor is executed, then the destructors of the base classes (reverse order of constructors). So when a base class calls Release or any COM function, the Com Library is not available any more and the code GPFs. I solved the problem like this: struct ComStarter { ComStarter() { CoInitialize(NULL); } ~ComStarter() { CoUninitialize(); CoFreeUnusedLibraries(); } } class MyConnection: public ComStarter, public _ConnectionPtr /*or whatever*/ { // here your code ~MyConnection() { ... } }; This guarantees that CoInitialize() is called as the very first, and CoUnitialize() as the very last function.
-
Hi, I use Visual C++ 6.0 SP 4 , SQL Server and oledb I create a class to connect to my database. In my constructor i initialize com library like this : CoInitialize(NULL); In my destructor i release com library like this : CoUninitialize(); If i use this class to execute for exemple an sql query ( store procedure), my functions open, execute, close,... work. But if i close my application ( OnOK ) , two seconds later i obtain the following acces violation message : EXCEPTION(c0000005 acces,@40f919) EBP184f0b8 EIP40f919) ASM 45 fc 8b 08 8b 01 52 ff 50 08 8b e5 5d c3 cc cc cc cc cc cc EAX:184f618 EBX:dc0110 ECX:383439 EDX:383439 ESI:dc0064 EDI:184f664 ESP:184f0b4 The suspect function is _Release() throw() which is in a Visual C++ include file ( in Include\COMIP.H ) // Releases only if the interface is not null. // The interface is not set to NULL. void _Release() throw() { if (m_pInterface != NULL) { m_pInterface->Release(); } } But if i comment out CoUninitialize() instruction, my code work without acces violation. Can anybody help me? Best regards, Cheickna:confused:
I have had this symptom before, and my problem was that I had amulti-thread app and I didn't Always marry the CoInit with the CoUninit. I had two solutions, make sure every thread calls Coinit and CoUninit correctly (as I had a bug) and use CoInitializeEx(Multithread)! This my be a different problem to yours, but then again it may not! Jules.