privileged instruction in 32-bit code

[Tyler Nielsen]

Hello,

I'm looking for a little help to find the next step in getting a program 
(Everquest 2) working under wine.  It currently runs the patcher, and 
will go through the load screen, and when the game comes up I get:

WineDbg starting on pid 0x8
Unhandled exception: privileged instruction in 32-bit code (0x00872230).
In 32 bit mode.
fixme:dbghelp:sffip_cb NIY on 
'D:\test\eq2\output\User_Optimized\Client\EverQuest2.pdb'
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
 EIP:00872230 ESP:7fbfee40 EBP:7fbfef64 EFLAGS:00210202(   - 00      - -RI1)
 EAX:75065bec EBX:00f77bc0 ECX:00f78080 EDX:00f78080
 ESI:60890008 EDI:75003280
Stack dump:
0x7fbfee40:  fffffffe 7449f020 7cb55a30 60890008
0x7fbfee50:  00000008 00f78090 60888370 00000a5c
0x7fbfee60:  75468130 00000000 60897ca0 75065bb0
0x7fbfee70:  00f78740 60a917f0 00f78090 00f780a0
0x7fbfee80:  7449f020 00000a5f 75468100 00000297
0x7fbfee90:  beb29113 3fa5ebd8 be2674d8 00aba38f
Backtrace:
=>1 0x00872230 in everquest2 (+0x472230) (0x7fbfef64)
  2 0x00876a6e in everquest2 (+0x476a6e) (0x7449ed70)
  3 0x00000010 (0x00d1eb84)
  4 0x00874f28 in everquest2 (+0x474f28) (0x008755a4)
0x00872230:
Modules:

I then started up winedbg and got this:

WineDbg starting on pid 0xa
In 32 bit mode.
start_process () at 
/home/tcnielsen/Programming/wine/dlls/kernel/../../include/winternl.h:1692
0x7fc7523c start_process+0xfc 
[/home/tcnielsen/Programming/wine/dlls/kernel/../../include/winternl.h:1692] 
in kernel32: jmp     0x7fc7522b start_process+0xeb 
[/home/tcnielsen/Programming/wine/dlls/kernel/process.c:992] in kernel32
1692    static inline void WINAPI DbgBreakPoint(void) { __asm__ 
__volatile__("int3"); }
Wine-dbg>disas 0x00872230
fixme:dbghelp:sffip_cb NIY on 
'D:\test\eq2\output\User_Optimized\Client\EverQuest2.pdb'
0x00872230:
0x00872232: push        %es
0x00872233:
0x00872235: incl        %edi
0x00872236: loopne      0x00872247
0x00872238: subl        %ecx,0x10(%esi)
0x0087223b:
0x0087223d: decl        %edi
0x0087223e: lock
0x00872241: inl %dx,%eax

I've tried googling and the closest thing I found was an old wine 
traffic from 2003. 
http://www.kerneltraffic.org/wine/wn20031017_192.html#4. So is there 
anything else I can look at or do to try and get past this?

Thanks for the help,
Tyler

[Raphael]

On Thursday 10 November 2005 03:25, Tyler Nielsen wrote:
> Hello,
>
> I'm looking for a little help to find the next step in getting a program
> (Everquest 2) working under wine.  It currently runs the patcher, and
> will go through the load screen, and when the game comes up I get:
>
> WineDbg starting on pid 0x8
> Unhandled exception: privileged instruction in 32-bit code (0x00872230).
> In 32 bit mode.
> fixme:dbghelp:sffip_cb NIY on
> 'D:\test\eq2\output\User_Optimized\Client\EverQuest2.pdb'
> Register dump:
>  CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
>  EIP:00872230 ESP:7fbfee40 EBP:7fbfef64 EFLAGS:00210202(   - 00      -
> -RI1) EAX:75065bec EBX:00f77bc0 ECX:00f78080 EDX:00f78080
>  ESI:60890008 EDI:75003280
> Stack dump:
> 0x7fbfee40:  fffffffe 7449f020 7cb55a30 60890008
> 0x7fbfee50:  00000008 00f78090 60888370 00000a5c
> 0x7fbfee60:  75468130 00000000 60897ca0 75065bb0
> 0x7fbfee70:  00f78740 60a917f0 00f78090 00f780a0
> 0x7fbfee80:  7449f020 00000a5f 75468100 00000297
> 0x7fbfee90:  beb29113 3fa5ebd8 be2674d8 00aba38f
> Backtrace:
> =>1 0x00872230 in everquest2 (+0x472230) (0x7fbfef64)
>   2 0x00876a6e in everquest2 (+0x476a6e) (0x7449ed70)
>   3 0x00000010 (0x00d1eb84)
>   4 0x00874f28 in everquest2 (+0x474f28) (0x008755a4)
> 0x00872230:
> Modules:
>
> I then started up winedbg and got this:
>
> WineDbg starting on pid 0xa
> In 32 bit mode.
> start_process () at
> /home/tcnielsen/Programming/wine/dlls/kernel/../../include/winternl.h:1692
> 0x7fc7523c start_process+0xfc
> [/home/tcnielsen/Programming/wine/dlls/kernel/../../include/winternl.h:1692
> ] in kernel32: jmp     0x7fc7522b start_process+0xeb
> [/home/tcnielsen/Programming/wine/dlls/kernel/process.c:992] in kernel32
> 1692    static inline void WINAPI DbgBreakPoint(void) { __asm__
> __volatile__("int3"); }
> Wine-dbg>disas 0x00872230
> fixme:dbghelp:sffip_cb NIY on
> 'D:\test\eq2\output\User_Optimized\Client\EverQuest2.pdb'
> 0x00872230:
> 0x00872232: push        %es
> 0x00872233:
> 0x00872235: incl        %edi
> 0x00872236: loopne      0x00872247
> 0x00872238: subl        %ecx,0x10(%esi)
> 0x0087223b:
> 0x0087223d: decl        %edi
> 0x0087223e: lock
> 0x00872241: inl %dx,%eax
>
> I've tried googling and the closest thing I found was an old wine
> traffic from 2003.
> http://www.kerneltraffic.org/wine/wn20031017_192.html#4. So is there
> anything else I can look at or do to try and get past this?
>
> Thanks for the help,
> Tyler

Hi,

seems another "Copy Protected" Game.
can you try "Ivan Leo Puoti" patches (related to ntoskrnl/safedisc) ?

Raphael

[Tyler Nielsen]

Raphael wrote:
> On Thursday 10 November 2005 03:25, Tyler Nielsen wrote:
> > Hello,
> >
> > I'm looking for a little help to find the next step in getting a program
> > (Everquest 2) working under wine.  It currently runs the patcher, and
> > will go through the load screen, and when the game comes up I get:
> >
> > WineDbg starting on pid 0x8
> > Unhandled exception: privileged instruction in 32-bit code (0x00872230).
> > In 32 bit mode.
> > fixme:dbghelp:sffip_cb NIY on
> > 'D:\test\eq2\output\User_Optimized\Client\EverQuest2.pdb'
> > Register dump:
> > CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
> > EIP:00872230 ESP:7fbfee40 EBP:7fbfef64 EFLAGS:00210202(   - 00      -
> > -RI1) EAX:75065bec EBX:00f77bc0 ECX:00f78080 EDX:00f78080
> > ESI:60890008 EDI:75003280
> > Stack dump:
> > 0x7fbfee40:  fffffffe 7449f020 7cb55a30 60890008
> > 0x7fbfee50:  00000008 00f78090 60888370 00000a5c
> > 0x7fbfee60:  75468130 00000000 60897ca0 75065bb0
> > 0x7fbfee70:  00f78740 60a917f0 00f78090 00f780a0
> > 0x7fbfee80:  7449f020 00000a5f 75468100 00000297
> > 0x7fbfee90:  beb29113 3fa5ebd8 be2674d8 00aba38f
> > Backtrace:
> > =>1 0x00872230 in everquest2 (+0x472230) (0x7fbfef64)
> >  2 0x00876a6e in everquest2 (+0x476a6e) (0x7449ed70)
> >  3 0x00000010 (0x00d1eb84)
> >  4 0x00874f28 in everquest2 (+0x474f28) (0x008755a4)
> > 0x00872230:
> > Modules:
>
> Hi,
>
> seems another "Copy Protected" Game.
> can you try "Ivan Leo Puoti" patches (related to ntoskrnl/safedisc) ?
>
> Raphael

Thanks for the reply.  I'll track down that patch and try it tonight.  I 
don't think this program uses safedisc though (I don't have to have the 
cd in to play).  On another note, I found 'INSTR_EmulateInstruction' and 
added some debug.  It looks like the disassembly I posted earlier was 
wrong.  I dumped the data, and put it into gdb, and here is the result.

(gdb) disassemble bar
Dump of assembler code for function bar:
0x080495a0 <bar+0>:     movaps %xmm0,(%ecx)
0x080495a3 <bar+3>:     shufps $0xa,%xmm3,%xmm2
0x080495a7 <bar+7>:     add    $0x90,%eax
0x080495ac <bar+12>:    decl   0x4c(%esp)
0x080495b0 <bar+16>:    movaps %xmm1,0x10(%ecx)
0x080495b4 <bar+20>:    shufps $0x9d,%xmm3,%xmm2
0x080495b8 <bar+24>:    mov    %edi,0x88(%esp)
0x080495bf <bar+31>:    mov    0x64(%esp),%edi
0x080495c3 <bar+35>:    movaps %xmm2,0x20(%ecx)
0x080495c7 <bar+39>:    jne    0x80491b6

I'm now fairly sure it's failing on the first movaps command.  Unless 
someone can direct me differently, I'm going to start looking at why 
that command is showing up as 'privileged'.

Thanks,
Tyler

[Marcus Meissner]

> (gdb) disassemble bar
> Dump of assembler code for function bar:
> 0x080495a0 <bar+0>:     movaps %xmm0,(%ecx)
> 0x080495a3 <bar+3>:     shufps $0xa,%xmm3,%xmm2
> 0x080495a7 <bar+7>:     add    $0x90,%eax
> 0x080495ac <bar+12>:    decl   0x4c(%esp)
> 0x080495b0 <bar+16>:    movaps %xmm1,0x10(%ecx)
> 0x080495b4 <bar+20>:    shufps $0x9d,%xmm3,%xmm2
> 0x080495b8 <bar+24>:    mov    %edi,0x88(%esp)
> 0x080495bf <bar+31>:    mov    0x64(%esp),%edi
> 0x080495c3 <bar+35>:    movaps %xmm2,0x20(%ecx)
> 0x080495c7 <bar+39>:    jne    0x80491b6
>
> I'm now fairly sure it's failing on the first movaps command.  Unless 
> someone can direct me differently, I'm going to start looking at why 
> that command is showing up as 'privileged'.

Does your machine support SSE2 instructions? I guess this is the problem.

Ciao, Marcus

[Andreas Mohr]

Hi,

On Fri, Nov 11, 2005 at 10:36:24AM +0100, Marcus Meissner wrote:
> > (gdb) disassemble bar
> > Dump of assembler code for function bar:
> > 0x080495a0 <bar+0>:     movaps %xmm0,(%ecx)
> > 0x080495a3 <bar+3>:     shufps $0xa,%xmm3,%xmm2
> > 0x080495a7 <bar+7>:     add    $0x90,%eax
> > 0x080495ac <bar+12>:    decl   0x4c(%esp)
> > 0x080495b0 <bar+16>:    movaps %xmm1,0x10(%ecx)
> > 0x080495b4 <bar+20>:    shufps $0x9d,%xmm3,%xmm2
> > 0x080495b8 <bar+24>:    mov    %edi,0x88(%esp)
> > 0x080495bf <bar+31>:    mov    0x64(%esp),%edi
> > 0x080495c3 <bar+35>:    movaps %xmm2,0x20(%ecx)
> > 0x080495c7 <bar+39>:    jne    0x80491b6
> >
> > I'm now fairly sure it's failing on the first movaps command.  Unless 
> > someone can direct me differently, I'm going to start looking at why 
> > that command is showing up as 'privileged'.
>
> Does your machine support SSE2 instructions? I guess this is the problem.

Thinking that stuff a bit further: I'd guess that an app usually knows when
to use SSE2 and when not to use it (since it'd most likely crash the same
way on Windows if it was wrong!).
IOW, do we have an issue with some SystemInfo API indicating that we *have*
an SSE2 CPU here when we actually have not, and thus the program chooses to
switch to the improper code path?

Andreas

[Tyler Nielsen]

Andreas Mohr wrote:
> Hi,
>
> On Fri, Nov 11, 2005 at 10:36:24AM +0100, Marcus Meissner wrote:
> > > (gdb) disassemble bar
> > > Dump of assembler code for function bar:
> > > 0x080495a0 <bar+0>:     movaps %xmm0,(%ecx)
> > > 0x080495a3 <bar+3>:     shufps $0xa,%xmm3,%xmm2
> > > 0x080495a7 <bar+7>:     add    $0x90,%eax
> > > 0x080495ac <bar+12>:    decl   0x4c(%esp)
> > > 0x080495b0 <bar+16>:    movaps %xmm1,0x10(%ecx)
> > > 0x080495b4 <bar+20>:    shufps $0x9d,%xmm3,%xmm2
> > > 0x080495b8 <bar+24>:    mov    %edi,0x88(%esp)
> > > 0x080495bf <bar+31>:    mov    0x64(%esp),%edi
> > > 0x080495c3 <bar+35>:    movaps %xmm2,0x20(%ecx)
> > > 0x080495c7 <bar+39>:    jne    0x80491b6
> > >
> > > I'm now fairly sure it's failing on the first movaps command.  Unless 
> > > someone can direct me differently, I'm going to start looking at why 
> > > that command is showing up as 'privileged'.
> >
> > Does your machine support SSE2 instructions? I guess this is the problem.
>
> Thinking that stuff a bit further: I'd guess that an app usually knows when
> to use SSE2 and when not to use it (since it'd most likely crash the same
> way on Windows if it was wrong!).
> IOW, do we have an issue with some SystemInfo API indicating that we *have*
> an SSE2 CPU here when we actually have not, and thus the program chooses to
> switch to the improper code path?
>
> Andreas

From /proc/cpuinfo I see sse and sse2 in the flags.  So I don't think 
that this is because my cpu doesn't support it.  I would like to be able 
to dissable sse support and see if this fixes the problem, but I can't 
see an easy way to do this.  I have found the file dlls/kernel/cpu.c, 
and it seems like that is what I need to deal with.

Tyler

[Ivan Leo Puoti]

> Hi,
>
> seems another "Copy Protected" Game.
> can you try "Ivan Leo Puoti" patches (related to ntoskrnl/safedisc) ?
>
> Raphael

Unless the game is protected by safedisc they won't help much. Chances 
are some anti debugger checks are failing, so the game intentionally 
screws itself up.

Ivan.

[Tyler Nielsen]

Ivan Leo Puoti wrote:
> > Hi,
> >
> > seems another "Copy Protected" Game.
> > can you try "Ivan Leo Puoti" patches (related to ntoskrnl/safedisc) ?
> >
> > Raphael
>
> Unless the game is protected by safedisc they won't help much. Chances 
> are some anti debugger checks are failing, so the game intentionally 
> screws itself up.
>
> Ivan.

Yeah, the safedisc patch didn't seem to help the issue at all.  I really 
hope this isn't debugger checks failing, but I still wonder why a 
seemingly valid command (movaps) is returning a privileged instruction  
exception.

Tyler

[Peter Beutner]

Tyler Nielsen schrieb:
> Ivan Leo Puoti wrote:
> Yeah, the safedisc patch didn't seem to help the issue at all.  I really
> hope this isn't debugger checks failing, but I still wonder why a
> seemingly valid command (movaps) is returning a privileged instruction 
> exception.

google says:
movaps will cause an exception when trying to access data not aligned to 16-byte boundary.

though i don't really know what you can do about that :(

[Tyler Nielsen]

Peter Beutner wrote:
> Tyler Nielsen schrieb:
> > Ivan Leo Puoti wrote:
> > Yeah, the safedisc patch didn't seem to help the issue at all.  I really
> > hope this isn't debugger checks failing, but I still wonder why a
> > seemingly valid command (movaps) is returning a privileged instruction 
> > exception.
>
> google says:
> movaps will cause an exception when trying to access data not aligned to 16-byte boundary.
>
> though i don't really know what you can do about that :(

Thanks for finding that.  It looks like the movaps command that is 
failing is:

(gdb) disassemble bar
Dump of assembler code for function bar:
0x080495a0 <bar+0>:     movaps %xmm0,(%ecx)

So looking at the winedbg dump:

Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
 EIP:00872230 ESP:7fbfee40 EBP:7fbfef64 EFLAGS:00210202(   - 00      -
-RI1) EAX:75065bec EBX:00f77bc0 ECX:00f78080 EDX:00f78080
 ESI:60890008 EDI:75003280

It seems like ECX is 00f78080.  I think that's on a 16 byte boundary, 
but I'm not positive.

Thanks for all the help everyone,
Tyler

[Uwe Bonnes]

> > > > > "Peter" == Peter Beutner  writes:

Peter> Tyler Nielsen schrieb:
    >> Ivan Leo Puoti wrote: Yeah, the safedisc patch didn't seem to help
    >> the issue at all.  I really hope this isn't debugger checks failing,
    >> but I still wonder why a seemingly valid command (movaps) is
    >> returning a privileged instruction exception.
    Peter> google says: movaps will cause an exception when trying to access
    Peter> data not aligned to 16-byte boundary.

Peter> though i don't really know what you can do about that :(

Perhaps that some Wine memory layout has some weak spots in i't 16-bit range..