Re: Crash in 16-bit code

[Jukka Heinonen]

Okay, I have posted a patch to wine-patches that
should have fixed this bug. Let's see if that is
the case. 

It may be that bug has still not been
fixed by that patch. In that case last lines
of trace "wine --debugmsg +int,+int31" before
the point where application crashes would be helpful.

-- 
Jukka Heinonen <http://www.iki.fi/jhei/>

Crash in 16-bit code

* Jukka Heinonen wrote:
| Okay, I have posted a patch to wine-patches that
| should have fixed this bug. Let's see if that is
| the case. 

Thanks -- I've tested it, and it seems to get further now.  It still
crashes, though...

As you can see, it now crashes in another executable.


$ wine ./Setup
fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported
err:wave:OSS_WaveOutInit /dev/mixer1: No such device
err:wave:OSS_WaveInInit /dev/mixer1: No such device
fixme:cdrom:CDROM_GetStatusCode Unmapped error code 13: Permission denied
fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported
wine: Unhandled exception (thread 000c), starting debugger...
fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported
WineDbg starting on pid b
Loaded debug information from ELF 'wine' ((nil))
Breakpoint 1 at 0x4000cf70 (_end+0x400b824)
Loaded debug information from ELF '/home/andrej/local/wine/lib/libntdll.dll.so' (0x40017000)
Loaded debug information from ELF '/home/andrej/local/wine/lib/libwine.so.1' (0x400aa000)
Loaded debug information from ELF '/home/andrej/local/wine/lib/libwine_unicode.so.1' (0x400c1000)
No debug information in ELF '/lib/tls/libpthread.so.0' (0x401c8000)
No debug information in ELF '/lib/tls/libm.so.6' (0x401d6000)
No debug information in ELF '/lib/libdl.so.2' (0x401f8000)
No debug information in ELF '/lib/ld-linux.so.2' (0x40000000)
Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/kernel32.dll.so' (0x401fd000)
No debug information in 32bit DLL 'D:\Mainx01.exe' (0x400000)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40040000)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x40230000)
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000).
In 32-bit mode.
0x00000000: addb        %al,0x0(%eax)
Wine-dbg>bt
Backtrace:
=>0 0x00000000 (ebp=0000311f)
  1 0x0040b4aa (Mainx01.exe.C0DE+0x44aa in Mainx01.exe) (ebp=0000311f, null call assumed)


| It may be that bug has still not been
| fixed by that patch. In that case last lines
| of trace "wine --debugmsg +int,+int31" before
| the point where application crashes would be helpful.

$ nice wine --debugmsg +int,+int31 ./Setup
fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported
err:wave:OSS_WaveOutInit /dev/mixer1: No such device
err:wave:OSS_WaveInInit /dev/mixer1: No such device
trace:int:DOSVM_HardwareInterruptPM builtin interrupt 31 has been invoked (through vector 31)
trace:int31:DOSVM_Int31Handler Simulate real mode interrupt 2f.
trace:int:DOSVM_Int2fHandler Subfunction 0x150D
trace:int:MSCDEX_Handler Get drive letters
trace:int:DOSVM_HardwareInterruptPM builtin interrupt 31 has been invoked (through vector 31)
trace:int31:DOSVM_Int31Handler Simulate real mode interrupt 2f.
trace:int:DOSVM_Int2fHandler Subfunction 0x1510
trace:int:MSCDEX_Handler CDROM device driver -> command <12>
trace:int:MSCDEX_Handler  --> IOCTL OUTPUT <2>
fixme:cdrom:CDROM_GetStatusCode Unmapped error code 13: Permission denied
trace:int:MSCDEX_Handler  ----> RESET
trace:int:DOSVM_HardwareInterruptPM builtin interrupt 31 has been invoked (through vector 31)
trace:int31:DOSVM_Int31Handler Simulate real mode interrupt 2f.
trace:int:DOSVM_Int2fHandler Subfunction 0x1510
trace:int:MSCDEX_Handler CDROM device driver -> command <128>
fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported
wine: Unhandled exception (thread 000c), starting debugger...
fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported
WineDbg starting on pid b
Loaded debug information from ELF 'wine' ((nil))
Breakpoint 1 at 0x4000cf70 (_end+0x400b824)
Loaded debug information from ELF '/home/andrej/local/wine/lib/libntdll.dll.so' (0x40017000)
Loaded debug information from ELF '/home/andrej/local/wine/lib/libwine.so.1' (0x400aa000)
Loaded debug information from ELF '/home/andrej/local/wine/lib/libwine_unicode.so.1' (0x400c1000)
No debug information in ELF '/lib/tls/libpthread.so.0' (0x401c8000)
No debug information in ELF '/lib/tls/libm.so.6' (0x401d6000)
No debug information in ELF '/lib/libdl.so.2' (0x401f8000)
No debug information in ELF '/lib/ld-linux.so.2' (0x40000000)
Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/kernel32.dll.so' (0x401fd000)
No debug information in 32bit DLL 'D:\Mainx01.exe' (0x400000)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40040000)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x40230000)
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000).
In 32-bit mode.
0x00000000: addb        %al,0x0(%eax)
Wine-dbg>bt
Backtrace:
=>0 0x00000000 (ebp=0000311f)
  1 0x0040b4aa (Mainx01.exe.C0DE+0x44aa in Mainx01.exe) (ebp=0000311f, null call assumed)

Wine-dbg>cont
First chance exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:003b GS:0033
 EIP:00000000 ESP:40862e5c EBP:0000311f EFLAGS:00010246(  R- 00  I  Z- -P1 )
 EAX:0040bb77 EBX:0040b181 ECX:0000041d EDX:0000041d
 ESI:400499ea EDI:40098118
Stack dump:
0x40862e5c (_end+0x573214):  0040b4aa 00000100 0040aa03 4009eea0
0x40862e6c (_end+0x573224):  00407162 40862e7c 4009ed00 0000311f
0x40862e7c (_end+0x573234):  4009d5c0 00000216 4006f97f 402efb80
0x40862e8c (_end+0x573244):  40862ea4 00400100 401c0038 00407000
0x40862e9c (_end+0x573254):  405305e0 00000000 00000000 00000000
0x40862eac (_end+0x573264):  00000000 00000000 00000000 00000000
0x40862ebc (_end+0x573274):

Backtrace:
=>0 0x00000000 (ebp=0000311f)
  1 0x0040b4aa (Mainx01.exe.C0DE+0x44aa in Mainx01.exe) (ebp=0000311f, null call assumed)

0x00000000: addb        %al,0x0(%eax)

-- 
Try   Anarchy  Online   http://www.anarchy-online.com/content/downloads/tryout/
Netiquette guidelines   ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt
How to quote properly   http://www.i-hate-computers.demon.co.uk/
Hvordan sitere riktig   http://home.online.no/~vidaandr/news/OBSquoting.html

Crash in 16-bit code

[Jukka Heinonen]

On Tue, Oct 07, 2003 at 12:29:15AM +0200, André Johansen wrote:
> * Jukka Heinonen wrote:
> | Okay, I have posted a patch to wine-patches that
> | should have fixed this bug. Let's see if that is
> | the case.
>
> Thanks -- I've tested it, and it seems to get further now.  It still
> crashes, though...
>
> As you can see, it now crashes in another executable.

I think the problem is now that the program is able to call
MSCDEX (DOS CDROM driver) routines but those routines crash.

There seems to be at least one obvious bug in MSCDEX that
may be the reason for this crash. Unfortunately trace does not
contain information about where the crash happened but I guess
since this bug is in the same routine called on the last lines
of trace (trace:int:MSCDEX_Handler CDROM device driver -> command <128>),
fixing this bug may help.

Please, if you can, try the patch below and report what happens.




Index: dlls/winedos/int2f.c
===================================================================
RCS file: /home/wine/wine/dlls/winedos/int2f.c,v
retrieving revision 1.5
diff -u -r1.5 int2f.c
--- dlls/winedos/int2f.c        22 Sep 2003 19:33:07 -0000      1.5
+++ dlls/winedos/int2f.c        7 Oct 2003 18:29:10 -0000
@@ -783,8 +783,9 @@
 
             case 128: /* read long */
                 {
-                    LPVOID              dst = MapSL(MAKESEGPTR(PTR_AT(driver_request, 16, WORD),
-                                                               PTR_AT(driver_request, 14, WORD)));
+                    LPVOID dst = CTX_SEG_OFF_TO_LIN( context, 
+                                                     PTR_AT(driver_request, 16, WORD),
+                                                     PTR_AT(driver_request, 14, WORD) );
                     DWORD               at = PTR_AT(driver_request, 20, DWORD);
                     WORD                num = PTR_AT(driver_request, 18, WORD);
                     RAW_READ_INFO       rri;



-- 
Jukka Heinonen <http://www.iki.fi/jhei/>

Crash in 16-bit code

[Eric Pouech]

> Please, if you can, try the patch below and report what happens.
> may be (code janitorial) we could get rid of all MapSL and 
> PTR_REAL_TO_LIN calls, and just use the CTX_SEG_OFF_TO_LIN macro instead 
> ? That would be more readable IMO.
> A+

-- 
Eric Pouech

Crash in 16-bit code

[Jukka Heinonen]

On Tue, Oct 07, Eric Pouech wrote:
> may be (code janitorial) we could get rid of all MapSL and 
> PTR_REAL_TO_LIN calls, and just use the CTX_SEG_OFF_TO_LIN macro instead 
> ? That would be more readable IMO.

Well, that would be a good idea. I was actually planning to
post a patch that would make this change in int2f.c if my
test patch fixes the reported bug. There are
some places where we do know that pointers are either
real or protected mode ones, but I don't think that
really matters. Even kernel/instr.c does provide its own 
implementation of CTX_SEG_OFF_TO_LIN so other dlls would
require some cleaning up, too.

-- 
Jukka Heinonen <http://www.iki.fi/jhei/>

Crash in 16-bit code

[Steven Edwards]

--- Eric Pouech <pouech-eric(a)wanadoo.fr> wrote:
> may be (code janitorial) we could get rid of all MapSL and 
> PTR_REAL_TO_LIN calls, and just use the CTX_SEG_OFF_TO_LIN macro
> instead 
> ? That would be more readable IMO.
> A+

Yes [Un]Map[SL/LS] calls should all be marked as janitorial. They are
9x only and we dont want to have to try and implement a hack in
ReactOS.

Thanks
Steven


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Crash in 16-bit code

[Alexandre Julliard]

Steven Edwards <steven_ed4153(a)yahoo.com> writes:
> Yes [Un]Map[SL/LS] calls should all be marked as janitorial. They are
> 9x only and we dont want to have to try and implement a hack in
> ReactOS.

You can't get rid of MapSL, it's necessary for 16-bit support; all you
can do is separate the 16-bit code to not have to build it on ReactOS.

-- 
Alexandre Julliard
julliard(a)winehq.com

Crash in 16-bit code

* Jukka Heinonen wrote:
| Unfortunately trace does not
| contain information about where the crash happened but I guess
| since this bug is in the same routine called on the last lines
| of trace (trace:int:MSCDEX_Handler CDROM device driver -> command <128>),
| fixing this bug may help.

Is it possible to add more trace messages somewhere or get a larger
call-stack?


| Please, if you can, try the patch below and report what happens.

Didn't seem to change anything:

$ wine --debugmsg +int,+int31 ./Setup
fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported
err:wave:OSS_WaveOutInit /dev/mixer1: No such device
err:wave:OSS_WaveInInit /dev/mixer1: No such device
trace:int:DOSVM_HardwareInterruptPM builtin interrupt 31 has been invoked (through vector 31)
trace:int31:DOSVM_Int31Handler Simulate real mode interrupt 2f.
trace:int:DOSVM_Int2fHandler Subfunction 0x150D
trace:int:MSCDEX_Handler Get drive letters
trace:int:DOSVM_HardwareInterruptPM builtin interrupt 31 has been invoked (through vector 31)
trace:int31:DOSVM_Int31Handler Simulate real mode interrupt 2f.
trace:int:DOSVM_Int2fHandler Subfunction 0x1510
trace:int:MSCDEX_Handler CDROM device driver -> command <12>
trace:int:MSCDEX_Handler  --> IOCTL OUTPUT <2>
fixme:cdrom:CDROM_GetStatusCode Unmapped error code 13: Permission denied
trace:int:MSCDEX_Handler  ----> RESET
trace:int:DOSVM_HardwareInterruptPM builtin interrupt 31 has been invoked (through vector 31)
trace:int31:DOSVM_Int31Handler Simulate real mode interrupt 2f.
trace:int:DOSVM_Int2fHandler Subfunction 0x1510
trace:int:MSCDEX_Handler CDROM device driver -> command <128>
fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported
wine: Unhandled exception (thread 000c), starting debugger...
fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported
WineDbg starting on pid b
Loaded debug information from ELF 'wine' ((nil))
Breakpoint 1 at 0x4000cf70 (_end+0x400b824)
Loaded debug information from ELF '/home/andrej/local/wine/lib/libntdll.dll.so' (0x40017000)
Loaded debug information from ELF '/home/andrej/local/wine/lib/libwine.so.1' (0x400ab000)
Loaded debug information from ELF '/home/andrej/local/wine/lib/libwine_unicode.so.1' (0x400c2000)
No debug information in ELF '/lib/tls/libpthread.so.0' (0x401c9000)
No debug information in ELF '/lib/tls/libm.so.6' (0x401d7000)
No debug information in ELF '/lib/libdl.so.2' (0x401f9000)
No debug information in ELF '/lib/ld-linux.so.2' (0x40000000)
Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/kernel32.dll.so' (0x401fe000)
No debug information in 32bit DLL 'D:\Mainx01.exe' (0x400000)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40040000)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x40230000)
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000).
In 32-bit mode.
0x00000000: addb        %al,0x0(%eax)
Wine-dbg>bt
Backtrace:
=>0 0x00000000 (ebp=0000311f)
  1 0x0040b4aa (Mainx01.exe.C0DE+0x44aa in Mainx01.exe) (ebp=0000311f, null call assumed)
Wine-dbg>cont
First chance exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:003b GS:0033
 EIP:00000000 ESP:40862e5c EBP:0000311f EFLAGS:00010246(  R- 00  I  Z- -P1 )
 EAX:0040bb77 EBX:0040b181 ECX:0000041d EDX:0000041d
 ESI:400499ea EDI:400991b8
Stack dump:
0x40862e5c (_end+0x572214):  0040b4aa 00000100 0040aa03 4009ff40
0x40862e6c (_end+0x572224):  00407162 40862e7c 4009fda0 0000311f
0x40862e7c (_end+0x572234):  4009e660 00000216 4006fc17 402f0b80
0x40862e8c (_end+0x572244):  40862ea4 00400100 401c0038 00407000
0x40862e9c (_end+0x572254):  405305e0 00000000 00000000 00000000
0x40862eac (_end+0x572264):  00000000 00000000 00000000 00000000
0x40862ebc (_end+0x572274):

Backtrace:
=>0 0x00000000 (ebp=0000311f)
  1 0x0040b4aa (Mainx01.exe.C0DE+0x44aa in Mainx01.exe) (ebp=0000311f, null call assumed)

0x00000000: addb        %al,0x0(%eax)


I'm unable to run the program directly from winedbg; I only get to
this point:

First chance exception: page fault in 16-bit code (0267:00c9).
In 16-bit mode.
Register dump:
 CS:0267 SS:026f DS:026f ES:026f FS:0000 GS:0000
 IP:00c9 SP:43da BP:0000 FLAGS:0246(   - 00  I  Z- -P1 )
 AX:0300 BX:002f CX:0000 DX:1001 SI:0348 DI:001a
Stack dump:
0x026f:0x43da:  0000 0000 008f 0000 0000 0000 0000 0000
0x026f:0x43ea:  0000 0000 0000 0000 0000 0000 0000 0000
0x026f:0x43fa:  0000 0000 0000 0000 0000 0000 0000 0000
0x026f:0x440a:

004d: sel=026f base=405914c0 limit=0000641f 16-bit rw-
Backtrace:
=>0 0x0267:0x00c9 (bp=0000)

0x0267:0x00c9: int      $0x31

(I've tried cont repeatedly, but nothing new happens.)

-- 
Try   Anarchy  Online   http://www.anarchy-online.com/content/downloads/tryout/
Netiquette guidelines   ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt
How to quote properly   http://www.i-hate-computers.demon.co.uk/
Hvordan sitere riktig   http://home.online.no/~vidaandr/news/OBSquoting.html

Crash in 16-bit code

[Jukka Heinonen]

On Tue, Oct 07, André Johansen wrote:
> Is it possible to add more trace messages somewhere or get a larger
> call-stack?

Well, you could try using +relay debugmsg flag, but that usually
yields way too large traces. Probably the easiest way would be adding
manually TRACE (or ERR) lines to suspicious places and try to
pinpoint the line where crash happens (if it happens inside Wine
code). Good place to start would for example be checking if the
crash happens inside int2f handler.
> Didn't seem to change anything:

Well, that would have been too easy, anyway.
Mailing list wine-devel seems to have another CDROM
related crash, by the way, which could have something
to do with this.
> I'm unable to run the program directly from winedbg; I only get to
> this point:
>
> First chance exception: page fault in 16-bit code (0267:00c9).

Each intXX opcode throws an exception that is caught by
winedbg. This makes running DOS programs under winedbg 
next to impossible. Perhaps winedbg has some command to ignore
those exceptions or that kind of command should be added...

-- 
Jukka Heinonen <http://www.iki.fi/jhei/>

Crash in 16-bit code

* Jukka Heinonen wrote:
| Well, you could try using +relay debugmsg flag

Here are some lines around the crash-point; compare it to the previous
one (I made sure some output from that one was preset in my cut-out):

$ wine --debugmsg +int,+int31,+relay ./Setup 2> /tmp/trace
> From /tmp/trace:
> [...]
> trace:int:MSCDEX_Handler  --> IOCTL OUTPUT <2>
> 000a:Call kernel32.DeviceIoControl(00000054,002d5004,00000000,00000000,00000000,00000000,416a128c,00000000) ret=4089a01a
> fixme:cdrom:CDROM_GetStatusCode Unmapped error code 13: Permission denied
> 000a:Ret  kernel32.DeviceIoControl() retval=00000000 ret=4089a01a
> trace:int:MSCDEX_Handler  ----> RESET
> 000a:Call kernel32.CloseHandle(00000054) ret=408995fc
> 000a:Ret  kernel32.CloseHandle() retval=00000001 ret=408995fc
> 000a:Call winedos.EmulateInterruptPM(41580a44,00000031) ret=402538e9
> Call DOS int 0x31 ret=0197:00000005
>   eax=00000300 ebx=0000002f ecx=00000000 edx=00011001
>   esi=000003cf edi=0000001a ebp=00000000 esp=000000fc 
>   ds=026f es=026f fs=0000 gs=0000 ss=019f flags=00010246
> 000a:Call kernel32.MapSL(019f0000) ret=408a1f98
> 000a:Ret  kernel32.MapSL() retval=000d0b60 ret=408a1f98
> 000a:Ret  winedos.EmulateInterruptPM() retval=416a3000 ret=402538e9
> 000a:Call winedos.EmulateInterruptPM(41580a44,00000031) ret=402538e9
> Call DOS int 0x31 ret=0267:00000449
>   eax=00000300 ebx=0000002f ecx=00000000 edx=00011001
>   esi=000003cf edi=0000001a ebp=00000000 esp=d63a43bc 
>   ds=026f es=026f fs=0000 gs=0000 ss=026f flags=00010246
> trace:int:DOSVM_HardwareInterruptPM builtin interrupt 31 has been invoked (through vector 31)
> 000a:Call kernel32.MapSL(019f0000) ret=408a1f98
> 000a:Ret  kernel32.MapSL() retval=000d0b60 ret=408a1f98
> 000a:Ret  winedos.EmulateInterruptPM() retval=00000031 ret=402538e9
> 000a:Call kernel32.MapSL(019f0000) ret=408a1f98
> 000a:Ret  kernel32.MapSL() retval=000d0b60 ret=408a1f98
> trace:int31:DOSVM_Int31Handler Simulate real mode interrupt 2f.
> 000a:Call kernel32.GetModuleHandle16(408a95ce "KERNEL") ret=4089e739
> 000a:Ret  kernel32.GetModuleHandle16() retval=000000ae ret=4089e739
> 000a:Call kernel32.GetProcAddress16(000000ae,000000b7) ret=4089e742
> 000a:Ret  kernel32.GetProcAddress16() retval=ffff0097 ret=4089e742
> trace:int:DOSVM_Int2fHandler Subfunction 0x1510
> trace:int:MSCDEX_Handler CDROM device driver -> command <128>
> 000a:Call kernel32.GetDriveTypeA(416a1230 "D:\\") ret=40899195
> 000a:Ret  kernel32.GetDriveTypeA() retval=00000005 ret=40899195
> 000a:Call kernel32.CreateFileA(416a15f0 "\\\\.\\D:",80000000,00000001,00000000,00000003,00000000,00000000) ret=408994ed
> 000a:Ret  kernel32.CreateFileA() retval=00000054 ret=408994ed
> 000a:Call kernel32.DeviceIoControl(00000054,00024000,00000000,00000000,416a12c0,00000324,416a128c,00000000) ret=40899531
> 000a:Ret  kernel32.DeviceIoControl() retval=00000001 ret=40899531
> 000a:Call kernel32.DeviceIoControl(00000054,0002402c,416a128a,00000002,416a12a0,00000018,416a128c,00000000) ret=4089a465
> 000a:Ret  kernel32.DeviceIoControl() retval=00000001 ret=4089a465
> 000a:Call kernel32.ReadFile(00000054,00010090,00000800,416a128c,00000000) ret=40899ec5
> 000a:Ret  kernel32.ReadFile() retval=00000000 ret=40899ec5
> 000a:Call kernel32.CloseHandle(00000054) ret=408995fc
> 000a:Ret  kernel32.CloseHandle() retval=00000001 ret=408995fc
> 000a:Call winedos.EmulateInterruptPM(41580a44,00000031) ret=402538e9
> Call DOS int 0x31 ret=0197:00000005
>   eax=00000300 ebx=0000002f ecx=00000000 edx=00011001
>   esi=000003cf edi=0000001a ebp=00000000 esp=000000fc 
>   ds=026f es=026f fs=0000 gs=0000 ss=019f flags=00010246
> 000a:Call kernel32.MapSL(019f0000) ret=408a1f98
> 000a:Ret  kernel32.MapSL() retval=000d0b60 ret=408a1f98
> 000a:Ret  winedos.EmulateInterruptPM() retval=416a3000 ret=402538e9
> 000a:Call USER.13: GETTICKCOUNT() ret=0267:0152 ds=026f
> 000a:Call kernel32.GetTickCount() ret=408f9922
> 000a:Ret  kernel32.GetTickCount() retval=000001e4 ret=408f9922
> 000a:Ret  USER.13: GETTICKCOUNT() retval=000001e4 ret=0267:0152 ds=026f
> 000a:Call KERNEL.166: WINEXEC(026f035a "mainx01.exe  41445821",0001) ret=0267:017b ds=026f
> 0009:Ret  kernel32.LoadModule16() retval=0000026e ret=406523c4
> 0009:Call kernel32.ReleaseThunkLock(40872ce8) ret=406523d8
> 0009:Ret  kernel32.ReleaseThunkLock() retval=00000000 ret=406523d8
> 0009:Call kernel32.Sleep(ffffffff) ret=406523df
> fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported
> 000c:Call PE DLL (proc=0x40254240,module=0x40230000 L"kernel32.dll",reason=PROCESS_ATTACH,res=0x1)
> 000a:Call user32.WaitForInputIdle(00000058,00007530) ret=40267d57
> 000a:Call kernel32.GetTickCount() ret=40937cf6
> 000a:Ret  kernel32.GetTickCount() retval=00000203 ret=40937cf6
> 000a:Call kernel32.GlobalLock16(0000023f) ret=4093f4ed
> 000a:Ret  kernel32.GlobalLock16() retval=40580780 ret=4093f4ed
> 000a:Call kernel32.ReleaseThunkLock(416a17b8) ret=40937bc2
> 000a:Ret  kernel32.ReleaseThunkLock() retval=00000000 ret=40937bc2
> 000a:Call x11drv.MsgWaitForMultipleObjectsEx(00000002,416a182c,00007530,00000040,00000000) ret=40937beb
> 000a:Call kernel32.WaitForMultipleObjectsEx(00000002,416a182c,00000000,00007530,00000000) ret=40b3815f
> 000c:Ret  PE DLL (proc=0x40254240,module=0x40230000 L"kernel32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1
> 000c:Starting process L"D:\\Mainx01.exe" (entryproc=0x407000)
> wine: Unhandled exception (thread 000c), starting debugger...
> fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported
> 000e:Call PE DLL (proc=0x40254240,module=0x40230000 L"kernel32.dll",reason=PROCESS_ATTACH,res=0x1)
> 000e:Ret  PE DLL (proc=0x40254240,module=0x40230000 L"kernel32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1
> 000e:Starting process L"C:\\WINDOWS\\SYSTEM\\winedbg.exe" (entryproc=0x40659134)
> 000e:Call advapi32.RegCreateKeyA(80000001,40679576 "Software\\Wine\\WineDbg",408b2e24) ret=4066e411
> 000e:Call kernel32.GetVersion() ret=408d1e05
> 000e:Ret  kernel32.GetVersion() retval=c3b60004 ret=408d1e05
> 000e:Call ntdll.RtlOpenCurrentUser(000f003f,408b2ce0) ret=408d1cba
> 000e:Ret  ntdll.RtlOpenCurrentUser() retval=00000000 ret=408d1cba
> 000e:Call ntdll.RtlInitAnsiString(408b2cfc,40679576 "Software\\Wine\\WineDbg") ret=408d1e74
> 000e:Ret  ntdll.RtlInitAnsiString() retval=00000000 ret=408d1e74
> 000e:Call ntdll.RtlInitAnsiString(408b2cf4,00000000) ret=408d1e83
> 000e:Ret  ntdll.RtlInitAnsiString() retval=40075c21 ret=408d1e83
> 000e:Call ntdll.RtlAnsiStringToUnicodeString(402f0598,408b2cfc,00000000) ret=408d1e8c
> 000e:Ret  ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=408d1e8c
> 000e:Call ntdll.RtlAnsiStringToUnicodeString(408b2cec,408b2cf4,00000001) ret=408d1eab
> 000e:Ret  ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=408d1eab
> 000e:Call ntdll.NtCreateKey(408b2e24,000f003f,408b2d04,00000000,408b2cec,00000000,00000000) ret=408d1ec9
> 000e:Ret  ntdll.NtCreateKey() retval=00000000 ret=408d1ec9
> [...]

-- 
Try   Anarchy  Online   http://www.anarchy-online.com/content/downloads/tryout/
Netiquette guidelines   ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt
How to quote properly   http://www.i-hate-computers.demon.co.uk/
Hvordan sitere riktig   http://home.online.no/~vidaandr/news/OBSquoting.html

Crash in 16-bit code

[Jukka Heinonen]

On Tue, Oct 07, 2003 at 10:26:05PM +0200, André Johansen wrote:
> * Jukka Heinonen wrote:
> | Well, you could try using +relay debugmsg flag
>
> Here are some lines around the crash-point; compare it to the previous
> one (I made sure some output from that one was preset in my cut-out):
>
> $ wine --debugmsg +int,+int31,+relay ./Setup 2> /tmp/trace

It looks like 16-bit code uses WINEXEC function to
execute a 32-bit program mainx01.exe which crashes almost
immediately by calling a null pointer. However, I could be
wrong because I don't know that much about this part of Wine.

Anyway, unless there is some bug in WINEXEC (are these programs
really mixed code programs and if they are, does Wine handle those
cases properly?) or functions called by it, this crash may be
quite difficult to fix.

-- 
Jukka Heinonen <http://www.iki.fi/jhei/>

Crash in 16-bit code

[Sylvain Petreolle]

I still get a crash with WinDVD.
Attached : trace with +int (int 1a has no other debug channel) and
disass around $eip.

 --- Jukka Heinonen <jhei(a)iki.fi> a écrit :
> Okay, I have posted a patch to wine-patches that
> should have fixed this bug. Let's see if that is
> the case.
>
> It may be that bug has still not been
> fixed by that patch. In that case last lines
> of trace "wine --debugmsg +int,+int31" before
> the point where application crashes would be helpful.
>
> -- 
> Jukka Heinonen <http://www.iki.fi/jhei/>

=====
Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net)
 ICQ #170597259
Say NO to software patents
Dites NON aux brevets logiciels

"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Crash in 16-bit code

[Jukka Heinonen]

On Tue, Oct 07, Sylvain Petreolle wrote:
> I still get a crash with WinDVD.
> Attached : trace with +int (int 1a has no other debug channel) and
> disass around $eip.

Well, well. This looks pretty interesting.
It looks like the program is trying to call
PCI BIOS routine "FIND PCI DEVICE" from
32-bit linear code.

This is either some kind of copy protection scheme
or the program really wants to call PCI BIOS, which
is something I thought event Windows 95 would
not allow. Have you tried running the program
using different Windows versions (NT or later)?

-- 
Jukka Heinonen <http://www.iki.fi/jhei/>