COM method call returns Catastrophic Failure when BSTR is passed

▲
1
▼

Revised from previous question

Note:

  • Pass BSTR variable to COM method, HRESULT return is 8000FFFF
  • Previous calls with interface pointer, was successful: HRESULT is 0
  • Execution, inside Visual Studio succeeds, outside fails - release and debug

Illustration:

BSTR raw_sim_Open = SysAllocString (L"c:\\example.S8");

hresult = pis8->raw_Open (raw_sim_Open); //0x8000FFFF returned

Edit - WinDbg:

First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=003a5be8 ebx=00009000 ecx=003a0208 edx=77606e00 esi=0012ec90 edi=00191b14
eip=003a0283 esp=0012ec34 ebp=0012ecb4 iopl=0         nv up ei ng nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010296
Missing image name, possible paged-out or corrupt data.
Missing image name, possible paged-out or corrupt data.
<Unloaded_PI32.dll>+0x3a0282:
003a0283 0080023a0088    add     byte ptr [eax-77FFC5FEh],al ds:0023:883a95ea=??
c++
windows
visual-studio-2008
com
asked on Stack Overflow Mar 21, 2009 by Aaron • edited May 23, 2017 by Community

3 Answers

▲
1
▼

One of the most noteable differencies between a debug build and a release build is that the debug libs initializes memory to zero while the release libs don't. So if something works in a debug build but fails in a release build, a possible cause is one or more uninitialized variable(s).

answered on Stack Overflow Mar 21, 2009 by Dan Byström
▲
1
▼

Like danbystrom mentiones, the difference may be in initialization. But this can affect execution indirectly too. For example, what if the method doesn't call SysStringLen to determine the length of the string but instead tries to use it as a null-terminated string? That's unlikely the cause of problem, but worth checking.

If that the case the following will help. Use SysAllocStringLen() to get a BSTR which has a trailing null character.

answered on Stack Overflow Mar 24, 2009 by sharptooth
▲
0
▼

A return of E_UNEXPECTED does not directly imply anything in general.

More COM runtime errors are more specific (e.g. loss of DCOM connection), so likely it is the COM component itself that is returning E_UNEXPECTED.

You need to review or debug into the implementation of the COM component itself.

answered on Stack Overflow Mar 21, 2009 by Richard • edited Jul 27, 2016 by Ian Boyd

User contributions licensed under CC BY-SA 3.0