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 wrote:
How does one tell what DLL contains a particular segment of 16 bit code in winedbg?
that's no longer supported in winedbg (we don't generate in Wine the native 16 bit DLL loading events, so we don't catch them in winedbg) a way to do it is to trace +module and get the address from here (BTW, this is on Alexandre's and my todo list for quite a while now, but with a low priority ATM).
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.
what about http://www.winehq.org/docs/wine-devel/dbg-commands.shtml ? (and all chapter 2 of developer guide ?)
A+
Eric Pouech wrote:
Dan Kegel wrote:
How does one tell what DLL contains a particular segment of 16 bit code in winedbg?
that's no longer supported in winedbg (we don't generate in Wine the native 16 bit DLL loading events, so we don't catch them in winedbg) a way to do it is to trace +module and get the address from here (BTW, this is on Alexandre's and my todo list for quite a while now, but with a low priority ATM).
OK. (I also noticed that adding +task to --debugmsg shows a few 16 bit loading stuff.) Here are what appear to be the interesting lines from a log from a run of Resource Hunter's installer, in which it crashed during cleanup:
510 trace:module:NE_OpenFile opened 'F:\rchtemp\SETUP.EXE' -> 0x64 511 trace:module:NE_LoadSegment Loading segment 2, hSeg=0267, flags=0c43 516 trace:module:NE_StartTask Starting main program: cs:ip=025f:7564 ds=0267 ss:sp=0267:5700 ... 8956 trace:module:MODULE_LoadModule16 Loaded module 'F:\rchtemp_ISDEL.EXE' at 0x0447. ... 9028 trace:module:NE_OpenFile opened 'F:\RCHTEMP_ISDEL.EXE' -> 0x78 9029 trace:module:NE_LoadSegment Loading segment 2, hSeg=048e, flags=0c53 9030 trace:module:NE_StartTask Starting main program: cs:ip=0487:079c ds=048f ss:sp=048f:1782 ... 11586 trace:file:FILE_DoOpenFile C:\WINDOWS_iserr31.ini OF_READ OF_SHARE_COMPAT OF_DELETE ... 11590 trace:module:NE_GetOrdinal (0447,'__GP') 11591 wine: Unhandled exception, starting debugger... ... 11732 Unhandled exception: privileged instruction in 16-bit code (0487:09b7).
I had expected the segment number from the exception (0487) would show up on some log line with a DLL filename on it, but the only match was the one on the 2nd NE_startTask. But what the heck, it seems likely in this case that the crash is in the installshield cleanup program _isdel.exe. I guess if I wanted to continue tracking this down, I might set a breakpoint on NE_StartTask, and turn on +all when _isdel.exe starts running. I probably don't have energy for that today, so if someone else wants to take a crack at this apparent InstallShield crash, please do.
Maybe I'll go back to the other 16 bit crash I had and see if turning on +module gives me enough to figure out what DLL or exe is crashing there, too.
Which FM did I fail to R?
... chapter 2 of developer guide
OK, I've reviewed that, thanks. Hmm, if I come up with a good recipie for "figuring out what 16 bit DLL or EXE contains the code that crashed", maybe I should add a note to the developer guide about it; that might help until you and/or Alexadre get around to the item on your todo list you mentioned above. - Dan
-
Dan Kegel -
Eric Pouech