Re: Question Error Access violation in CoUninitialize() call

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance





Hi,

I am using code as shown below...
ClassName()
{
hResult = CoInitializeEx(0,COINIT_APARTMENTTHREADED);
if(SUCCEEDED(hResult))
{
Success = true;
}
else
{
Success = false;
}
}


~ClassName()
{
if(Success)
{
CoUninitialize();
}
}

this code takes care of the point u made. but i am still running into access
violation errors. is it safe to call coinitialize and Couninitialize from a
dll? The stack trace is the same as i posted above. Some times i also run
into stack overflow and heapcorruption exceptions. These errors occur in the
IPHLPAPI function call getadaptersinfo() or getadaptersaddresses().

Unhandled Exception: System.AccessViolationException: Attempted to read or
write
protected memory. This is often an indication that other memory is corrupt.
at GetAdaptersAddresses(UInt32 , UInt32 , Void* ,
_IP_ADAPTER_ADDRESSES_LH* ,
UInt32* )
at NetworkAdapter.GetAdapterIpAddress(NetworkAdapter* , UInt32 IfIndex,
Int32
Family, Void* Buffer, UInt32* SizeOfData)

this is the output from the system when the server crashes !!

the stack trace for the above exception is different. most of the times the
exception occurs in the ole32.dll!CCache::Flush() function.this is the output
from the system when the server crashes !! pls help me !!


"Paul Baker [MVP, Windows Desktop Experie" wrote:

This is not quite following the rules. When you call CoInitialize, you don't
know if someone else already called it for that thread. If they did,
CoInitialize may fail and if it does, you should not be calling
CoUninitialize. If the caller can call your function from any thread,
consider letting the caller call CoInitialize/CoInitialize rather than you.
If you decide you should be calling CoInitialize, check the result. If it
fails, do not call CoUninitialize. Note that S_FALSE is success. You can use
the SUCCEEDED macro. Some Shell functions call CoInitialize but they
presumably follow the above-mentioned logic.

Paul

"Vivek S" <VivekS@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6B089DD0-3213-4B8F-BDDE-435FA6CA993F@xxxxxxxxxxxxxxxx

Hi, thanks for the reply....i am calling Coinitialize and Couninitialize
in
the same function which happens to be in a dll that i have written. i have
released all interfaces before calling CoUninitialize. the function in the
dll works fine when it is called for the first time....but gives an
exception(access violation) when it is called the second time. each call
is
from a new thread. the stack trace is posted below. pls help me !

ole32.dll!CCache::GetElement() + 0xb2 bytes
ole32.dll!CComCatalog::GetClassInfoInternal() + 0xfd bytes
ole32.dll!CComCatalog::GetClassInfoW() + 0x22 bytes
ole32.dll!GetClassInfoFromClsid() + 0x2d bytes
ole32.dll!LookForConfiguredClsid() + 0x2f bytes
ole32.dll!ICoCreateInstanceEx() + 0xae bytes
ole32.dll!CComActivator::DoCreateInstance() + 0x2f bytes
ole32.dll!_CoCreateInstanceEx@24() + 0x23 bytes
ole32.dll!_CoCreateInstance@20() + 0x39 bytes
0112a6fa()
ntdll.dll!_RtlAllocateHeap@12() + 0xe2 bytes
ntdll.dll!_RtlpCoalesceFreeBlocks@16() + 0x96 bytes
010cef10()
ntdll.dll!_RtlAllocateHeap@12() + 0x50b bytes
ntdll.dll!_RtlEncodeSystemPointer@4() - 0xd7dc bytes
ntdll.dll!_RtlValidateUnicodeString@8() + 0x60 bytes

the error is no more in the CoUninitialize but in some other function
before
it.


"Paul Baker [MVP, Windows Desktop Experie" wrote:

If you are getting an Access Violation, or any error, calling
CoInitialize,
there are two things you should check.

1. That you are balancing calls CoInitialize(Ex)/CoUninitialize. For each
that that calls CoInitialize(Ex) successfully, the same thread should
call
CoUninitialize. Otherwise, make sure you're not calling it. also, make
sure
you are calling CoInitialize(Ex) from each thread that needs to use COM.
2. That all COM calls are complete and you have no reference to an
interface
before calling CoUninitialize. Make sure you reference counted your
interfaces (AddRef and Release) correctly.

Paul

"Vivek S" <VivekS@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:292931F3-C8F2-4DBE-B986-351B7D4D7860@xxxxxxxxxxxxxxxx
Hi !

I am writing a dll containing WMI code in vc++ to set static ip
address. I
am using visual studio 2005 SP1 on windows server 2003 SP2. I make use
of
the
win32_networkadapterconfiguration class and its enablestatic method.
The
ip
address is set properly but when i call CoUninitialize at the end to
cleanup
com it gives an access viiolation exception. i have setup a debugger
and
the
error is in OLE32!CCache::Flush function. pls help me out in this
regard.

thank you !






.



Relevant Pages

  • Re: Question Error Access violation in CoUninitialize() call
    ... What I was trying to explain was that there isn't a rule against calling ... CoInitializeand CoUninitialize from a DLL, but you had better make sure ... the stack trace for the above exception is different. ... CoInitialize may fail and if it does, ...
    (microsoft.public.win32.programmer.ole)
  • Re: Question Error Access violation in CoUninitialize() call
    ... CoInitialize may fail and if it does, ... If you decide you should be calling CoInitialize, ... fails, do not call CoUninitialize. ... released all interfaces before calling CoUninitialize. ...
    (microsoft.public.win32.programmer.ole)
  • CoUninitialize() and CComPtr<> object lifetimes
    ... I have tracked down a bug involving object lifetimes to a quirk in CComPtr<> ... help that CoInitialize() is being called somewhere in the app framework. ... CoUninitialize(); ... What is going on with this DLL? ...
    (microsoft.public.vc.atl)
  • Re: Windows Service & ADO problem
    ... As ADO is based on COM it needs to call coInitialize to initialize its ... Well, actually Microsoft recommends to ... if you don't call coUninitialize there is a lot of things not ... It also may be a problem with MDAC or COM corruption/bug. ...
    (borland.public.delphi.database.ado)
  • Re: Calling Coinitialize
    ... > Delphi 5 C/S compiled programs and use ADO. ... > the dll's doesn't seem to help) and then it will immediately crash ... not calling coInitialize and coUninitialize at all. ...
    (borland.public.delphi.database.ado)