views:

400

answers:

3

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=??
A: 

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

More COM runtime errors are more specific (e.g. loss of DOCM 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.

Richard
Inside VS, no problems?
Aaron
I don't understand this? Can you explain what you mean by 'inside' VS?Also, what is pis8? Is this code you wrote? Do you have access to the source?
thehouse
@thehouse: executing inside Visual studio, no problems (i.e., no 0x8000FFFF returned from HRESULT), pis8 - is an interface pointer (this info was generated from MIDL compiler) and lastly - YES
Aaron
its still not clear what 'inside' means. Do you mean running it using the debugger? VS is just an IDE. It doesn't have an inside or an outside.As Richard has said, you need to step through the call to raw_Open using the debugger and find out where the component fails.
thehouse
The COM object (server-side) cannot be debugged
Aaron
@Atklin: even at assembler level with a native debugger (to minimise impact)?Without more details more help is very difficult, if it were raising a SEH exception that could be used to trigger a mini-dump with ADPLus... but far more details needed.
Richard
@Richard: what I'm totally confused about, is the fact that execution through Visual Studio's debugger is fine. I'll close the question as is too ambiguous
Aaron
+1  A: 

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).

danbystrom
+1  A: 

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.

sharptooth