Reputation: 2883
Revised from previous question
Note:
8000FFFF
0
Illustration:
BSTR raw_sim_Open = SysAllocString (L"c:\\example.S8");
hresult = pis8->raw_Open (raw_sim_Open); //0x8000FFFF returned
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=??
Upvotes: 1
Views: 1447
Reputation: 109200
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.
Upvotes: 0
Reputation: 170569
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.
Upvotes: 1
Reputation: 9244
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).
Upvotes: 1