Debugging crashes in 16 bit code?

Dan Kegel dank at kegel.com
Sun Feb 2 02:48:45 CST 2003


How does one tell what DLL contains a particular
segment of 16 bit code in winedbg?

For instance, there's a nice juicy exception that happens
towards the end of the Resource Hunter installer,
available as a free trial download at http://www.boilsoft.com/rchunter.html
In wine = win2k mode, it happens early enough to break the install,
but in wine's win98 mode, the install doesn't crash until quite late,
and you can actually use the product.  Here's a log of an installer run
that crashed (with "Windows" = "win2k"):

$ ~/wine/wine setup.exe
fixme:seh:check_resource_write Broken app is writing to the resource data, enabling work-around
fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000008,0x00000000,0x40791ba4): stub
fixme:ntdll:NtQueryInformationToken (0xcafe,2,(nil),0,0x40791b90): stub
fixme:ntdll:NtQueryInformationToken (0xcafe,2,0x40791b7c,12,0x40791b90): stub
fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000008,0x00000000,0x4079154c): stub
fixme:ntdll:NtQueryInformationToken (0xcafe,2,(nil),0,0x40791538): stub
fixme:ntdll:NtQueryInformationToken (0xcafe,2,0x40791524,12,0x40791538): stub
fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000008,0x00000000,0x4079135c): stub
fixme:ntdll:NtQueryInformationToken (0xcafe,2,(nil),0,0x40791348): stub
fixme:ntdll:NtQueryInformationToken (0xcafe,2,0x40791334,12,0x40791348): stub
fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.
wine: Unhandled exception, starting debugger...
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\CTL3D32.DLL' (0x41170000)
...
Unhandled exception: privileged instruction in 16-bit code (0487:09b7).
In 16-bit mode.
0x0487:0x09b7: ldsw     0x014a,%dx
Wine-dbg>

At that point, I know how to gather a few kinds of info helpful
to people trying to track down the cause of the crash,
namely 'bt', 'info regs' and 'disas' (giving the latter an address 0x20 or
so lower than the crash address, to give a little context):

Wine-dbg> info regs
Register dump:
  CS:0487 SS:048f DS:048f ES:049f FS:0000 GS:0007
  IP:09b7 SP:1768 BP:176e FLAGS:0246(   - 00  I  Z- -P1 )
  AX:0000 BX:000b CX:0000 DX:0000 SI:01be DI:01be

Wine-dbg> disas 0x0487:0x0977
0x0487:0x0977: movw     $0x1be,%di
0x0487:0x097a: call     0x09d2
0x0487:0x097d: movw     $0x1be,%si
0x0487:0x0980: movw     $0x1be,%di
0x0487:0x0983: call     0x09e1
0x0487:0x0986: call     0x09a9
0x0487:0x0989: popw     %ax
0x0487:0x098a: orb      %ah,%ah
0x0487:0x098c: jnz      0x09a5
0x0487:0x098e: movw     0x4(%bp),%ax
0x0487:0x0991: movb     $0x4c,%ah
Wine-dbg> disas
0x0487:0x0993: testw    $0x1,%cs:0x0794
0x0487:0x099a: jz       0x09a3
0x0487:0x099c: lcall    0x011f:0x0cdf
0x0487:0x09a1: jmp      0x09a5
0x0487:0x09a3: int      $0x21
0x0487:0x09a5: popw     %di
0x0487:0x09a6: popw     %si
0x0487:0x09a7: popw     %bp
0x0487:0x09a8: ret
0x0487:0x09a9: movw     0x01b4,%cx
Wine-dbg>
0x0487:0x09ad: jcxz     0x09b6
0x0487:0x09af: movw     $0x2,%bx
0x0487:0x09b2: lcall    *0x1b2 -> 0x0000
0x0487:0x09b6: push     %ds
0x0487:0x09b7: ldsw     0x014a,%dx
0x0487:0x09bb: movw     $0x2500,%ax
0x0487:0x09be: testw    $0x1,%cs:0x0794
0x0487:0x09c5: jz       0x09ce
0x0487:0x09c7: lcall    0x011f:0x0cdf
0x0487:0x09cc: jmp      0x09d0

That's fine and dandy, and maybe it'll help Marcus find the bug,
but it leaves me scratching my head, wondering what DLL could
be at fault, and how I could connect it to Wine source code
or a vendor-supplied DLL.

Which FM did I fail to R?   I did have a look at
http://www.winehq.org/docs/wine-devel/wine-debugger.shtml
but it doesn't seem to even think winedbg can disassemble
stuff by itself, so I wonder if that's not quite up to date.

Thanks,
Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045




More information about the wine-devel mailing list