Autocad 2004 STATUS_INVALID_LDT_OFFSET

[Jaap Stolk]

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