VS2010&OLE32.dll access violation problem with COM

[Arjay]

So we're back to my original question of how you are releasing the smart pointer.

[Note to self]Why does it take so long to pry info out of some posters?[/Note to self]

The code that you posted doesn't tell me anything on where you are releasing the com pointers because you don't show that part of the code.

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

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

     CoUninitialize();
  }
};

If you create the COM smart pointer where you have "// init skype api dll", then CoUnitialize is called before the smart pointer goes out of scope.

But rather than me guessing, can you just post the entire code?

[lightshield]

I've created COM smart pointers only in the main thread explicitly and above worker thread just using the skype's COM interface.

                void operator()(void)
		{
			error_message.clear();

			run = true;
			pause = false;

			theApp.LoadSkype4COMDLL();

			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 ){
				error_message += L"DispEventAdvise failed\n";
				//goto finalize;
			}
			// Attach to API
			hr = pSkype->Attach(5, VARIANT_TRUE);
			if( FAILED(hr) ){
				error_message += L"Attach failed\n";
				goto finalize;
			}

			xtime xt;
			MSG msg;
			while( run )
			{
				while( 
				  run
                                  && PeekMessage( &msg, NULL, 0, 0, PM_REMOVE )
				){
					TranslateMessage(&msg);
					DispatchMessage(&msg);
				}

				ThreadWait( xt, 50, 10 ); // wait
			}

finalize:
			// Disconnect events
			pSink->DispEventUnadvise(pSkype);
			// Cleanup
			pSkype = NULL;

			CoUninitialize();

			theApp.UnloadSkype4COMDLL();

			pause = true;
			run = false;
		}

And I've checked that COM pointers nullified correctly like below

class CMyView : public CView{
...
public:
  void CleanUPCOMPtr( void );
private:
  CComQIPtr<ISomeInterface> p; // declared as a class member variable
};

// called when closing this app
void CMyView::CleanUpCOMPtr( void )
{
  if( !(!p) ){
    p.Release();
  }
  ASSERT(!p);
}

On the above code, CleanUpCOMPtr called before CoUninitialize function and assertion didn't occur when I closing this application. These two things has exactly confirmed.
CoUninitialize function has been called in the CMyApp::ExitInstance function. CMyApp inherits CWinAppEx.


My entire code is very long and can't open to public.
I may create a solution to repro this bug as I possible.

[Arjay]

You need to read up on COM and understand what smart pointers do for you.

I say this because with COM, you don't need to explicitly load a COM dll.

So remove these two lines.

theApp.LoadSkype4COMDLL();
theApp.UnloadSkype4COMDLL();

Also, I finally get you to post the code because I needed to see what you are actually doing. And guess what? You are calling CoUninitialize before your smart pointers are going out of scope.

void operator()(void)
{
  theApp.LoadSkype4COMDLL();   // What's this?

  CoInitialize(NULL);

  // Create object
  ISkypePtr pSkype(__uuidof(Skype));

  // Create sink
  scoped_ptr<CSkypeEvents> pSink( new CSkypeEvents(man) );


  CoUninitialize();  // Whoops.  pSkype and pSink haven't gone out of scope yet.

  theApp.UnloadSkype4COMDLL();  // What's this?

}

Read up about COM smart pointers (or step through the smart pointer code). You'll see that smart pointers automatically call Release - that's why they're smart.

So, you don't need to do this.
// called when closing this app

void CMyView::CleanUpCOMPtr( void )
{
  if( !(!p) ){
    p.Release();
  }
  ASSERT(!p);
}

To fix this, just scope the COM pointers

CoInitialize(NULL);

{ // Scoping block

  ISkypePtr pSkype(__uuidof(Skype));
  scoped_ptr<CSkypeEvents> pSink( new CSkypeEvents(man) );

  HRESULT hr(S_OK);
		
  // Connect events
  hr = pSink->DispEventAdvise(pSkype);
  if( NULL == pSkype )
  {
    error_message += L"DispEventAdvise failed\n";
    //goto finalize;
  }
  // Attach to API
  hr = pSkype->Attach(5, VARIANT_TRUE);
  if( FAILED(hr) )
  {
    error_message += L"Attach failed\n";
    goto finalize;
  }

  xtime xt;
  MSG msg;
  while( run )
  {
    while( run && PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
    {
      TranslateMessage(&msg);
      DispatchMessage(&msg);
    }

    ThreadWait( xt, 50, 10 ); // wait
  }

finalize:

  // Disconnect events
  pSink->DispEventUnadvise(pSkype);
} // End of scoping block (causes smart pointer to release their interfaces)

CoUninitialize();

[lightshield]

Thanks Arjay
But if I didn't run this code at least once this issue will occurs.

CoInitialize(NULL);
{
   ISkype *pSkype(NULL);
   
   // do something
}
CoUninitialize();

Is the above code ok ?

theApp.LoadSkype4COMDLL and theApp.UnloadSkype4COMDLL will do that 'regsvr32 /s skype4COM.dll' and 'regsvr32 /s /u skype4COM.dll'.
These processes may be needed on my sense if we want complete nullification.


CComPtr holder are CView and CDocument inherited class on myprogram , and I've checked that these destructors will be called before CoUninitialize.
So all of CComPtr's destructors will be proceeded.
Then, how can we suspect about an access violation in the ntdll.dll ?

[Arjay]

theApp.LoadSkype4COMDLL and theApp.UnloadSkype4COMDLL will do that 'regsvr32 /s skype4COM.dll' and 'regsvr32 /s /u skype4COM.dll'.
These processes may be needed on my sense if we want complete nullification.

Then, how can we suspect about an access violation in the ntdll.dll ?

instead of calling those methods Loadxxx, you should call them Registerxxx. Actually you should let a setup program handle the COM registration. With your program, what happens if the skype dll is already registered? Your program will break the next guy.

I have no idea what nullification is.

The problem with your program is in your code, not in ntdll.dll.

[lightshield]

Yes, the problem is in my code exactly, but access violation exception message pumped up in the ntdll.dll.

[Igor Vartanov]

These processes may be needed on my sense if we want complete nullification.

Okay, this is where you're wrong. Sorry, but your COM knowledge seems rather poor. I'd recommend to start learning COM from very basics.

Regarding nullification, it was said exclusively about smart pointers, as this is a common practice for releasing interface before the moment the smart pointer leaves its scope:

ISomePtr p = NULL;
HRESULT hr = p.CreateInstance(__uuidof(Some));
. . .
p = NULL;
. . .

[lightshield]

I mean the nullification as the uninstallation of software modules.
I've known about the nullification of pointers of COM interfaces in terms of 'SafeRelease'.

By the way, therefor I've deleted sources that use CComQIPtr(s) completely, an exception in the ntdll.dll occurs.

It seems a problem that should be solved by myself.
Thanks all.

[Arjay]

I mean the nullification as the uninstallation of software modules.
I've known about the nullification of pointers of COM interfaces in terms of 'SafeRelease'.

By the way, therefor I've deleted sources that use CComQIPtr(s) completely, an exception in the ntdll.dll occurs.

It seems a problem that should be solved by myself.
Thanks all.

You're going the wrong direction. All your COM interfaces should use a COM smart pointer like CComQIPtr.

[Igor Vartanov]

I mean the nullification as the uninstallation of software modules.

And what's the idea behind? Why do you need that?

By the way, therefor I've deleted sources that use CComQIPtr(s) completely, an exception in the ntdll.dll occurs.

Therefore? Afraid, I don't follow you. What's wrong with CComQIPtr? In terms of 'safe release' CComQIPtr has no difference compared with other COM smart pointers.

[lightshield]

There are users who think like that some software are not uninstalled after uninstallation if some COM components don't unregistered. So I do these things in my program.

And sorry for my poor English skill.


But I really wonder that this issue doesn't occurs in VS2008.

[lightshield]

You're going the wrong direction. All your COM interfaces should use a COM smart pointer like CComQIPtr.

No, it's a special case. I'll use COM smart pointers mainly. it's just a test case.
I found the problem in implementations in basic MDI-frameworks( CMainframe, CChildFrame, CMyApp, CMyDoc, CMyView).
Maybe I can find the affected part soon.

[Arjay]

There are users who think like that some software are not uninstalled after uninstallation if some COM components don't unregistered. So I do these things in my program.

And sorry for my poor English skill.


But I really wonder that this issue doesn't occurs in VS2008.

Those users would be wrong with that assumption and you would be wrong for coding it that way. Look there is a defined system for software installations/uninstallations that involved reference counting of components? Why not learn how to follow the recommended way to install apps instead of your hacked way?

In terms of your program appearing to run on 2008 - by the looks of code you posted and your understanding of COM, I'd say you got lucky.

[lightshield]

Those users would be wrong with that assumption and you would be wrong for coding it that way. Look there is a defined system for software installations/uninstallations that involved reference counting of components? Why not learn how to follow the recommended way to install apps instead of your hacked way?

In terms of your program appearing to run on 2008 - by the looks of code you posted and your understanding of COM, I'd say you got lucky.

I have to unregister my COM component for the special reason that related to the running state of my application( running or shutting down. e.g. DirectShow filters). So I handling the registration of my COM components in my program. I think that it is necessary to fulfill the software requirement and it's not suitable for the installation system. Skype-API will not be involved in this requirement, so this may not be unregistered.

As I wrote in previous posts, this issue occurs after I deleted sources that use COM smart pointers.
I've screwing up now. COM related libraries that I using are below..

-Direct2D
-DirectShow(MicrosoftSDK v7.1)

But I found some lights to solve this issue. I'll try to resolve by myself. thanks all

[Vi2]

Try to use SetErrorInfo(0,NULL) before CoUninitialize() if you sure that there are no active smart-pointers. It may help.