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