On 6/24/06, Jaap Stolk <[EMAIL PROTECTED]> wrote:
So the problem is somewhere in load_driver( ). Is there a way to
narrow it down a bit more?
using objdump I got a bit closer.
(note that the exact error address my not be consistent, because I
added some more trace functions to the code while testing)
objdump ntoskrnl.exe.so -S > tmp.txt
ImagePath -> 0x1d7fa
0x1d7fa + 0x4fc = 0x1DCF6
0x1DCF6 -> static NTSTATUS driver_control(void)
also, combining the load address and the error location ends up somewhere there:
0x4062de4e - 0x40610000 = 0x1DE4E
1de21: 83 ec 0c sub $0xc,%esp
1de24: 52 push %edx
1de25: 8d 83 9c 02 ff ff lea 0xffff029c(%ebx),%eax
1de2b: 50 push %eax
1de2c: 8d 83 a4 01 ff ff lea 0xffff01a4(%ebx),%eax
1de32: 50 push %eax
1de33: 8d 83 c8 fe ff ff lea 0xfffffec8(%ebx),%eax
1de39: 50 push %eax
1de3a: 6a 01 push $0x1
1de3c: e8 c7 5f fe ff call 3e08 <_init+0x2c>
1de41: 83 c4 20 add $0x20,%esp
1de44: e9 3d ff ff ff jmp 1dd86 <driver_control+0x1ca>
1de49: 8b 45 b0 mov 0xffffffb0(%ebp),%eax
1de4c: 85 c0 test %eax,%eax
1de4e: 0f 84 1a ff ff ff je 1dd6e <driver_control+0x1b2>
1de54: 83 ec 08 sub $0x8,%esp
1de57: 56 push %esi
1de58: ff b5 50 fe ff ff pushl 0xfffffe50(%ebp)
1de5e: ff d0 call *%eax
(it's called form here:)
WINE_ERR("DispatchDeviceControl returned %lx\n", irp.IoStatus.Status);
1dd75: 8a 83 c8 fe ff ff mov 0xfffffec8(%ebx),%al
1dd7b: 83 e0 02 and $0x2,%eax
1dd7e: 84 c0 test %al,%al
1dd80: 0f 85 9b 00 00 00 jne 1de21 <driver_control+0x265>
looking at it form an other angle: I get two "raise exception".
The first one is just after user32.SetDeskWallPaper( ). I added the
wallpaper patch, but it's still happening. as it happens very early in
the log, it does not seem to be a problem.
I think the second one is causing the debugger to start:
000f:Ret ntoskrnl.exe.IoCreateSymbolicLink() retval=00000000 ret=407503ae
000f:trace:ntoskrnl:driver_control returned from call with status 00000000
000f:trace:seh:raise_exception code=c0000096 flags=0 addr=0x4062e04c
000f:trace:seh:raise_exception eax=4062e04c ebx=4063d964 ecx=400d03e8
edx=0000004b esi=4074fd80 edi=00000000
000f:trace:seh:raise_exception ebp=4074fe08 esp=4074fc2c cs=0023
ds=002b es=002b fs=003b gs=0033 flags=00010212
000f:trace:seh:call_stack_handlers calling handler at 0x4033ce80
code=c0000096 flags=0
<snip 13 lines>
000f:Call ntdll.RtlInitAnsiString(4074f5a0,4039d8ed "winedos.dll") ret=403500a0
<snip 22 pages>
000f:trace:module:load_builtin_callback loaded winedos.dll 0x4020d888 0x40760000
from what I could google, code=c0000096 means that a privileged
instruction was found.
But I don't seen anything exotic at 0x1de4e.
I think this is related:
http://bugs.winehq.com/show_bug.cgi?id=3438
but winedos.dll is started after the problem, so i don't think it's causing it.
I'm still not sure how to track the error location to the correct line
of source code, I recompiled ntoskrnl with -ggdb, but it already had
-g, so it should contain the source line numbers right?
How does wine normally handle privileged instruction ? I'm sure the
safedisc code uses every privileged instruction it can, and i would
not be surprised if it was throwing exceptions as a normal code path,
and i suspect some of it's drivers are supposed to run in ring 0 mode.
