Saturday, June 24, 2006, 3:18:03 PM, Jaap Stolk wrote:
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.
It's pretty hard to see what you doing from this pastes. Do you have time to join one of the Wine's IRC channels?
What I see there the driver tries to do soemthing that it thinks could be done running inside the kernel. But we don't run inside the kernel so those instructions do raise exception. Depending on what it's trying to do we should be able to emulate what it needs (if you applied all of my patch, especially the part to kernel/except.c
Vitaliy