Continuing my debugging efforts, I decided to look some more at the strange symbols I got in the backtrace.
Indeed, it seems like winedbg completely screws up the MFC42 symbols. For example, by disassembling from the load address of MFC42 I was able to identify the CString::FreeData() function at 0x5f402125, but winedbg tells me it's 0x5f445900.
Is this a known problem?
Regards, -- Christer Palm
Christer Palm wrote:
Continuing my debugging efforts, I decided to look some more at the strange symbols I got in the backtrace.
Indeed, it seems like winedbg completely screws up the MFC42 symbols. For example, by disassembling from the load address of MFC42 I was able to identify the CString::FreeData() function at 0x5f402125, but winedbg tells me it's 0x5f445900.
Is this a known problem?
yes, when you have several versions of MFC42.PDB like you seem to do (we don't lookup up for the right one yet) A+
Eric Pouech wrote:
Christer Palm wrote:
Continuing my debugging efforts, I decided to look some more at the strange symbols I got in the backtrace.
Indeed, it seems like winedbg completely screws up the MFC42 symbols. For example, by disassembling from the load address of MFC42 I was able to identify the CString::FreeData() function at 0x5f402125, but winedbg tells me it's 0x5f445900.
Is this a known problem?
yes, when you have several versions of MFC42.PDB like you seem to do (we don't lookup up for the right one yet) A+
The thing is that I can't see that this is the case here. I have:
[palm@localhost ~]$ find ~/.wine/drive_c/ -name "MFC*" -o -name "mfc*" /home/palm/.wine/drive_c/windows/system/MFC42.DLL /home/palm/.wine/drive_c/hager/Semiolog/Apps/MFC42.MAP /home/palm/.wine/drive_c/hager/Semiolog/Apps/MFC42.PDB
I have copied those DLL's off a VC++ 6.0 CD: MFC42.DLL from OS\SYSTEM into windows/system MFC42.MAP + MFC42.PDB from VC98\DEBUG into the directory I run the application from.
Still have the exact same problem...
Regards, -- Christer Palm
Christer Palm wrote:
Eric Pouech wrote:
Christer Palm wrote:
Continuing my debugging efforts, I decided to look some more at the strange symbols I got in the backtrace.
Indeed, it seems like winedbg completely screws up the MFC42 symbols. For example, by disassembling from the load address of MFC42 I was able to identify the CString::FreeData() function at 0x5f402125, but winedbg tells me it's 0x5f445900.
Is this a known problem?
yes, when you have several versions of MFC42.PDB like you seem to do (we don't lookup up for the right one yet) A+
The thing is that I can't see that this is the case here. I have:
[palm@localhost ~]$ find ~/.wine/drive_c/ -name "MFC*" -o -name "mfc*"
from one of your previous posts:
wine: Unhandled page fault on read access to 0x0000003c at address 0x5f4056dd (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x0000003c in 32-bit code (0x5f4056dd). In 32 bit mode. fixme:dbghelp:sffip_cb NIY on 'E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb' fixme:dbghelp:sffip_cb NIY on 'C:\hager\Semiolog\Apps\MFC42.PDB' fixme:dbghelp_msc:codeview_parse_type_table Not adding parameters' types to function signature fixme:dbghelp_msc:codeview_parse_type_table Unsupported type-id leaf a fixme:dbghelp_msc:dump 00000000: 06 00 0a 00 01 00 50 f1 ......P. fixme:dbghelp_msc:codeview_get_type Returning NULL symt for type-id 1053
also, we don't check (yet) CRC when loading PDB, which may also be the issue. A+
Eric Pouech wrote:
Christer Palm wrote:
The thing is that I can't see that this is the case here. I have:
[palm@localhost ~]$ find ~/.wine/drive_c/ -name "MFC*" -o -name "mfc*"
from one of your previous posts:
wine: Unhandled page fault on read access to 0x0000003c at address 0x5f4056dd (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x0000003c in 32-bit code (0x5f4056dd). In 32 bit mode. fixme:dbghelp:sffip_cb NIY on 'E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb' fixme:dbghelp:sffip_cb NIY on 'C:\hager\Semiolog\Apps\MFC42.PDB' fixme:dbghelp_msc:codeview_parse_type_table Not adding parameters' types to function signature fixme:dbghelp_msc:codeview_parse_type_table Unsupported type-id leaf a fixme:dbghelp_msc:dump 00000000: 06 00 0a 00 01 00 50 f1 ......P. fixme:dbghelp_msc:codeview_get_type Returning NULL symt for type-id 1053
Ah, I suppose you mean the 'E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb' line. There is no such file. In fact, I don't even have a drive mapping for E:. I've been assuming that winedbg is getting this bogus path from the executable (perhaps the location of MFC42.PDB when MFC42 was originally compiled or something).
I ran the ChkMatch tool from www.debuginfo.com to verify that the PDB and DLL really match, and it also confirms that the bogus E: path really comes from MFC42.DLL. This doesn't rule out the (rather unlikely, I would say) possibility that the PDB is corrupt in some other way, of course. Perhaps someone can mail me a "known good" pair of MFC42.DLL/PDB files?
[palm@localhost tmp]$ wine ChkMatch.exe -c /home/palm/.wine/drive_c/windows/system/MFC42.DLL /home/palm/.wine/drive_c/hager/Semiolog/Apps/MFC42.PDB ChkMatch - version 1.0 Copyright (C) 2004 Oleg Starodumov http://www.debuginfo.com/
Executable: /home/palm/.wine/drive_c/windows/system/MFC42.DLL Debug info file: /home/palm/.wine/drive_c/hager/Semiolog/Apps/MFC42.PDB
Executable: TimeDateStamp: 35889e42 Debug info: 2 ( CodeView ) TimeStamp: 35887c4e Characteristics: 0 MajorVer: 0 MinorVer: 0 Size: 55 RVA: 00000000 FileOffset: 000f3000 CodeView format: NB10 Signature: 35889e42 Age: 2 PDB File: E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb Debug info: 10 ( Unknown ) TimeStamp: 00000000 Characteristics: 0 MajorVer: 0 MinorVer: 0 Size: 0 RVA: 00000000 FileOffset: 00000000 Debug info: Unknown.
Debug information file: Format: PDB 2.00 Signature: 35889e42 Age: 2
Result: Matched
Regards, -- Christer Palm
-
Christer Palm -
Eric Pouech