On 6/24/06, Jaap Stolk jwstolk@gmail.com 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.