VS2010&OLE32.dll access violation problem with COM

[lightshield]

My program using COM and some DLLs and this program invokes access violation exception when I close the application. I've grabbing information below


- dli {cb=36 pidd=0x5caf5a1c ppfn=0x5cb175e4 ...} DelayLoadInfo
cb 36 unsigned long
+ pidd 0x5caf5a1c __DELAY_IMPORT_DESCRIPTOR_ole32_dll {grAttrs=1 rvaDLLName=429088 rvaHmod=5561600 ...} const ImgDelayDescr *
+ ppfn 0x5cb175e4 __imp__CoUninitialize@0 int (void)* *
+ szDll 0x5c638c20 "ole32.dll" const char *
+ dlp {fImportByName=1 szProcName=0x5caf627a "CoUninitialize" dwOrdinal=1554997882 } DelayLoadProc
+ hmodCur 0x74df0000 {unused=9460301 } HINSTANCE__ *
pfnCur 0x00000000 int (void)*
dwLastError 0 unsigned long
- dli.dlp {fImportByName=1 szProcName=0x5caf627a "CoUninitialize" dwOrdinal=1554997882 } DelayLoadProc
fImportByName 1 int
- szProcName 0x5caf627a "CoUninitialize" const char *
67 'C' const char
dwOrdinal 1554997882 unsigned long
- dli.dlp.szProcName 0x5caf627a "CoUninitialize" const char *
67 'C' const char

it seems CoUninitialize method involves some bad memory manipulations.
This problem does not occurs on the VS2008.
Why does this occurs ?

[Arjay]

If you are using COM smart pointers and calling CoUninitialize before the smart pointer goes out of scope, you can see a similar issue.

[lightshield]

But, I hadn't saw this problem on VS2008.

[Igor Vartanov]

Well, it doesn't matter, had you or had not. What matters is to call CoUnintialize only after all smartpointers left their scopes, or were nullified to the moment otherwise. You make sure this is done and see if the problem has gone.

[lightshield]

Do you mean the 'smart pointer' as COM's smart pointers ?
How is the boost::shared_ptr ?

[Igor Vartanov]

Okay. The problem mentioned by Arjay relates to having non released COM interfaces while CoInitialize gets called. Now it's up to you to get what kind of smart pointers it's about.

[lightshield]

Ｔｈａｎｋｓ.
I'm using many CComQIPtr(s) and released all of them before CoUninitialize and checked timing of release, therefor I couldn't resolve this issue. Why?

[Igor Vartanov]

So you are sure about interfaces being timely released. Then another suspect (pretty obvious, I'd say) is delayed load. Did you try to remove it?

[lightshield]

I've known the delay load of DLL but have not known the delay load around COM and CComPtr(or CComQIPtr). What is that ?
I haven't using delay loaded DLL(s).

Additionally, I've using Skype4COM.dll by '#import' pragma to communicate with the SkypeAPI and running the initialization process like below on the beginning of a worker thread

CoInitialize(NULL);
// Create object
ISkypePtr pSkype(__uuidof(Skype));
// Create sink
scoped_ptr<CSkypeEvents> pSink( new CSkypeEvents(man) );
HRESULT hr(S_OK);
// Connect events
hr = pSink->DispEventAdvise(pSkype);
if( NULL == pSkype ){
}
// Attach to API
hr = pSkype->Attach(5, VARIANT_TRUE);
if( FAILED(hr) ){
}

But, ntdll.dll issue will occurs if I will not run this procedure.

[Arjay]

I've known the delay load of DLL but have not known the delay load around COM and CComPtr(or CComQIPtr). What is that ?
I haven't using delay loaded DLL(s).

Additionally, I've using Skype4COM.dll by '#import' pragma to communicate with the SkypeAPI and running the initialization process like below on the beginning of a worker thread

CoInitialize(NULL);
// Create object
ISkypePtr pSkype(__uuidof(Skype));
// Create sink
scoped_ptr<CSkypeEvents> pSink( new CSkypeEvents(man) );
HRESULT hr(S_OK);
// Connect events
hr = pSink->DispEventAdvise(pSkype);
if( NULL == pSkype ){
}
// Attach to API
hr = pSkype->Attach(5, VARIANT_TRUE);
if( FAILED(hr) ){
}

But, ntdll.dll issue will occurs if I will not run this procedure.

In the code above, where does CoUninitialize get called?

[lightshield]

The above code is just the initializing part. CoUninitialize is used in my program.

[Arjay]

The above code is just the initializing part. CoUninitialize is used in my program.

Look, you've got a problem that we suspect is due to the scoping of the COM smart pointers getting released after your call to CoUninitialize. Of course, we don't know for sure until we see your code.

So can we just save time here and have you post the complete code from CoInitialize to CoUninitialize?

[lightshield]

My worker thread routine is as below.

class Worker{
  Worker(){}
  void operator()(void)
  {
     CoInitialize(NULL);

     // init skype api dll
     
     while(true){
          // skype api procedures using Skype4COM.dll
     }

     CoUninitialize();
  }
};

This is a worker thread and this thread will only uses skype-api's produced by Skype's DLL.
BUT I've unloading Skype-DLL on the main thread. This procedure maybe the cause of this problem. I'll try to remove this procedure to detect an affected part of my sources.

Sorry Igor, I might have using delayed load.

[Arjay]

Please use [Code][/Code] tags.

What does the following mean?

          // skype api procedures using Skype4COM.dll

Are using COM to access this dll? Or do you call LoadLibrary?

If Skype4Com.dll is a COM dll, then you don't need to call LoadLibrary ANYWHERE (because the COM subsystem handles that for you).

[lightshield]

skype4COM is a COM library.
I didn't use LoadLibrary so I didn't use delayed load.

I've using '#import' pragma to import Skype's class information like below in the cpp file that implementing Skype client functionalities.

#import ".\\Skype4COM.dll" named_guids