Autocad 2004 STATUS_INVALID_LDT_OFFSET

[Vitaliy Margolen]

Saturday, June 24, 2006, 3:18:03 PM, Jaap Stolk wrote:
> 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.

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