Re: Application crash on calling a COM method

From:

Scot T Brennecke <ScotB@Spamhater.MVPs.org>

Newsgroups:

microsoft.public.vc.atl

Date:

Sat, 15 Aug 2009 04:56:03 -0500

Message-ID:

<#J6oa6YHKHA.4092@TK2MSFTNGP02.phx.gbl>

I don't understand why you'd be calling the COM initialize and uninitialize methods in a wrapper class. This is something that is
typically done only once each for the entire application, not for each created COM object.

Gopal wrote:

Its a typo ... apologies ... the code should look like
CString function(char *c)
{
   _bstr_t ret;
    ret = pIntf->func(_bstr_t(c));
    CString csRet (ret.operator char *());
    return csRet;
}

The design of my app is such that when the end user selects a particular
option, I instantiate a C++ class which is kind of a wrapper interface to the
com object. The constructor then calls cocreateinstance. There is a method to
make com calls. When the user chooses to exit that option (not the
application) I destroy the object of the wrapper class. the counintialize()
happens in the destructor.

My first posting said that this was all working fine with VC6 compile. I
ported the code to compile with VS2005 and thats when the crash started
happening.

I know the _bstr_t destroys the BSTR using sysfreestring. But I think for
some wierd reason (optimized code maybe) this was happening late ... after my
CoUninitialize.

"Scot T Brennecke" wrote:

Well, CString has built-in conversions from BSTR, so that shouldn't have been a problem. Also, the _bstr_t destructor handles the
SysFreeString bit. Wait... now I see in your code you were returning "ret instead of csRet... what's that about?
I don't think you ever told us what version of VC++ you're using.
Your CoUninitialize shouldn't be happening anywhere near here; not until you're ready to shut down your app.

Gopal wrote:

What I meant by crash was application goes out of memory due to an unhandled
exception.

Ok so here is what fixed that problem for me. Now I am trying to understand
what was going wrong in the first place.

The return value for the COM call was a _bstr_t. So here is how my code went

CString function(char *c)
{
   _bstr_t ret;
   ret = pIntf->func(_bstr_t(c));
   CString csRet (ret.operator char *());
   return ret;
}

I changed this to use the raw_method exposed by the interface, which uses
BSTRs.
void function(char *c)
{
   BSTR ret;
   ret = pIntf->raw_func(_bstr_t(c).GetBSTR());
   sysfreestring(ret);
}

This seem to solve the crash for me. I had to remove CString as return type,
as I could not get a good way of converting from BSTR to CString w/o using
_bstr_t.

The only reason I can think of for this is, using bstr_t was causing the
sysfreestring to happen after my CoUnInitialize(). By explicitly calling
SysFreeString, I ensured that does not happen.

Does this make sense?

~GOpal

"Scot T Brennecke" wrote:

Define "crash". This is an overused term. The typical definition of crash is to be terminated abnormally because of an unhandled
fatal exception. Other people have used the term to mean "starts doing really unpredictable and destructive things" or "displays an
error message before terminating gracefully" or "displays an assertion failure warning box" or "terminates without completing the
expected action and without warning" or ....

DebugDiag and ADPlus should both capture process dumps in the case of an unhandled fatal second chance exception. Do you have any
doubts about whether you are using them correctly, or maybe your definition of crash is different from mine?

Gopal wrote:

I followed your mentioned steps. Also tried to use DebugDiag, but still no
concrete clues. The more I dig the more I feel that its the function which
makes the COM call, when it returns, crashes my application.

I had a question around this. All Com calls are stdcalls but my application
is compiled with _cdecl as default. Will this cause any problem? What I mean
is

CString MyClass::CallComFunc()
{
      BSTR result = pIntf->ComCall();
      CString ret;
      ret.Format("%s", (LPCTSTR)result);
     return ret;
}

When CallComFunc exits, will it try to clean up the Stack resulting in a
exception?

This might be a dump question... but I am really trying hard to get to the
bottom on this.

Thanks again,
~GOpal

"Scot T Brennecke" wrote:

Use the /Zi (Program Database) switch on compile to generate the debug info. Then put the /DEBUG (Generate debug info) switch on
the link to create the PDB. Note that this is the default in newer versions of VS. Some people think the words "debug" imply it
can't be done with "release" builds, and that leads people (mistakenly) away from building PDBs with their release configs.

Gopal wrote:

Thanks Scot, I will use these tools. Help me answer your question please. How
do I ensure that all my binaries are being built with matching symbols?

regards,
~GOpal

"Scot T Brennecke" wrote:

Since Brian has given you very good answers so far, I will only add that you can still attach something like DebugDiag or the ADPlus
script to your release execution and capture crash dumps with those. Have you built all your binaries with matching symbol files
(PDBs)?

Gopal wrote:

Thanks for your reply Scot. Here are additional details.

This is how the function inside my win32 dll looks like:
*********************************************************
void MyClass::FuncInsideWin32DLL(const char * p1, const char * p2,
    const char * p3, const char * p4, const char * p5)
{
    _bstr_t result;

       result = pIntf->Func(_bstr_t(p1),
        _bstr_t(p2),
                _bstr_t(p3),
                _bstr_t(p4),
                _bstr_t(p5));

}
******************************************************
And here is how the interface is defined inside the tlh file

*******************************************************
IMyInterface : IDispatch
{
    //
    // Wrapper methods for error-handling
    //

    _bstr_t Func (
        _bstr_t CmdName,
        _bstr_t Param1,
        _bstr_t Param2,
        _bstr_t Param3,
        _bstr_t Param4 );

    //
    // Raw methods provided by interface
    //

      virtual HRESULT __stdcall raw_Func (
        /*[in]*/ BSTR CmdName,
        /*[in]*/ BSTR Param1,
        /*[in]*/ BSTR Param2,
        /*[in]*/ BSTR Param3,
        /*[in]*/ BSTR Param4,
        /*[out,retval]*/ BSTR * __MIDL_0011 ) = 0;
};
*******************************************************

The crash usually occurs in the destruction of MyClass where I call
pIntf->Release() and CoUnintialize(). The Constructor of my MyClass calls
CoCreateInstance().

For environment constraint, I can only test with release binaries and hence
I am unable to get to the cause of this. I have COM exception handlers but
none of them are getting hit. My application freezes and dies.

Let me know if you need more information.

regards,
~GOpal

"Scot T Brennecke" wrote:

Gopal wrote:

At the outset, apologies for not providing the exact code. I cannot share the
code snippets here.

I have an MFC application which uses a normal win32 helper DLL. This DLL
inturn #imports a COM server (out of process EXE) which has a an interface
derived from IDispatch. Now all I do in the win32 dll is
- CoCreateInstance
- Addref
- Intf->function()
- Release

The above code worked perfectly fine when I was compiling it in VC6. The
moment I moved the MFC app and the win32 to VS2005, my application crashes
randomly after the function is called. This may happen at the first instance,
or sometime it takes 10-15 tries to get it to crash.

I suspect some kind of memory corruption because of marshalling, but haven't
quite been able to catch the culprit.

Any pointers would be of immense help.

regards,
~GOpal

So, tell us what is involved in the function call; are you passing any objects in either direction? Where does your app crash;
i.e., what code is executing when the crash occurs? Is it an access violation? Are you able to make it happen with a debugger (VS,
WinDbg, ADPlus, DebugDiag, etc.) attached?