Debuging Splinter Cell 1 - found bug in kernel32?

[Andreas Mohr]

Hi,

On Sat, Oct 15, 2005 at 12:44:35PM +0000, Christian Gmeiner wrote:
> Hi.
> 
> I have read this "tutorial" 
> http://wiki.winehq.org/Debugging_'Wild_Metal_Country' and tought that i can
> maybe find the problem, why splinter cell 1 wont start.
> 
> Here is the importat part (i think):
> 000b:Call kernel32.RaiseException(c000008f,00000001,00000002,7fbef5e4) 
> ret=66024d53
> 000b:Call ntdll.RtlRaiseException(7fbef4c4) ret=7fc48163 fs=003b
> eax=7fc319ad ebx=7fcb088c ecx=00000000 edx=00000008 esi=7fbef5ec 
> edi=7fbef4e0
> ebp=7fbef520 esp=7fbef4c4 ds=007b es=007b gs=0033 flags=00200202
> 000b:trace:seh:__regs_RtlRaiseException code=c000008f flags=1 
> addr=0x7fc480d0
> 000b:trace:seh:__regs_RtlRaiseException  info[0]=deadcafe
> 000b:trace:seh:__regs_RtlRaiseException  info[1]=deadcafe
> 000b:trace:seh:__regs_RtlRaiseException  eax=7fc319ad ebx=7fcb088c 
> ecx=00000000 edx=00000008 esi=7fbef5ec edi=7fbef4e0
> 000b:trace:seh:__regs_RtlRaiseException  ebp=7fbef520 esp=7fbef4c4 
> cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00200202
> 000b:trace:seh:EXC_CallHandler calling handler at 0x402586 code=c000008f 
> flags=1
> 000b:Call kernel32.IsBadReadPtr(004012b0,00000004) ret=66024da1
> 000b:Ret  kernel32.IsBadReadPtr() retval=00000000 ret=66024da1
> 000b:Call kernel32.TlsGetValue(00000003) ret=66024eda
> 000b:Ret  kernel32.TlsGetValue() retval=7fd5af10 ret=66024eda
> 000b:Call ntdll.RtlUnwind(7fbef69c,661001ad,00000000,00000000) 
> ret=661001ad fs=003b
> eax=00000001 ebx=7fcbbbac ecx=7fbef69c edx=00000003 esi=004012b0 
> edi=7fbef69c
> ebp=7fbeef50 esp=7fbeef44 ds=007b es=007b gs=0033 flags=00200206
> 
> The full log can be found here: 
> http://x-factor.dyndns.org/~austriancoder/splinter_cell1.log.bz2 (1,5 M)
> 
> Maybe somebody can confirm that it is a kernel32 bug and may can fix it, 
> or give me a hint
> were i can fix it.

That one is certainly not a kernel32 bug.

Well, at least that crash (and the part you showed) doesn't show anything pointing
at kernel32, what makes you think it's such a problem?

In fact that crash occurs out of the blue, with no indications what is causing it
AFAICS.

But I see that the program makes extensive use of oleaut32, which might be a bad
idea in case our implementation is still weak.
Try using a native oleaut32.dll to see if this fixes it and thus nails the problem
down to somewhere in oleaut32...

Hmm, but another thing is that the exception code here is very interesting:
include/ntstatus.h:#define STATUS_FLOAT_INEXACT_RESULT      0xC000008F
which is rather different from the all-too-common
#define STATUS_ACCESS_VIOLATION          0xC0000005

And
000b:trace:seh:__regs_RtlRaiseException  info[0]=deadcafe
000b:trace:seh:__regs_RtlRaiseException  info[1]=deadcafe
deadcafe is another special magic value that might have been set by Wine code to
indicate a problem...

Andreas Mohr

-- 
No programming skills!? Why not help translate many Linux applications! 
https://launchpad.ubuntu.com/rosetta