> However doing so it looks like:
>
>
> 0x405cdf46 (CreateWindowExA+0x46 [win.c:1118])
> 1118 FIXME("BON:Setting up SysHeader32\n");
> Wine-dbg>bt
> Backtrace:
> =>0 0x405cdf46 (CreateWindowExA+0x46(exStyle=0x0, className=0x5f4a5444,
>windowName=0x0, style=0x40000042, x=0x5f403903, y=0x5f4d1b60, width=0xa10af35d,
>height=0xa0b2e4a0, parent=0x341c, menu=0x9c70, instance=0x400000, data=0x0)
>[win.c:1118]) (ebp=4083cde0)
> 1 0x5f407d8a (COccManager::SplitDialogTemplate+0x6(pTemplate=0x0,
>ppOleDlgItems=0x5f4a5444) [occmgr.cpp:182]) (ebp=4083ce50)
> 2 0x5f409a6b (MFC42.DLL.2124+0x46) (ebp=4083ce8c)
> 3 0x5f456a10 (MFC42.DLL.2093+0x2d) (ebp=ffffffff)
> *** Invalid address 0xffffffff (SHLWAPI.DLL..reloc+0x4048dfff)
>
> I wonder why the stack levels 2 and 3 don't get resolved in Function
> names and looking at the MFC source for occmgr.cpp I think winedbg
> doesn't get things right...
windbg can read pdb files if the debug information of the exe file is not stripped
and the exe file is pointing directly to the pdb file.
If the debuginformation is stripped to a dbg file and there is a record pointing
to the pdb file in the dbg file windgb is not able to load the filename.
I already implemented the missing functionallity but didn't post the code since
it resolves not all functions to the right adresses and i could not find the problem
yet.
A second problem is: the pdb file seems to have a different timestamp than the dbg file
so I had to disable the code what checks it. To me it looks like the pdb code gets a
invalid timestamp from pdb files mostly.
I think I'll post the patch tomorrow anyway. (Have do do some cleanup before and its
a bit late now)
With this patch it reads the pdb file regadless of the timestamp (prints a warning) but
it displays often wrong function names (some 1000 bytes beside the right name).
juergen
