WinDbg loads a wrong symbol file

Konstantin_Manurin · January 19, 2007, 8:20am

Hi guys,

I use WinDbg 6.6.7.5 and today faced some strange behavior of this tool.
I tried to load symbol files for two modules: HALAACPI.DLL and
HALMACPI.DLL from both free and checked builds of Windows Server 2003 R2
Enterprise Edition. HALAACPI.PDB was successfully loaded. But when I
tried to query symbols for HALMACPI.DLL I received quite a strange
result. WinDbg loaded HALAACPI.PDB file again. Then I tried to do it
several times and got the same result. After quick research I’ve figured
out that this two files, HALACPI.DLL and HALMACPI.DLL, have same
timestamps and image sizes. But these files are totally different.

It’s significant to say that primarily I tried to obtain symbols only
for the HALMACPI.DLL module, and I didn’t find HALMACPI.PDB, but there
was HALAACPI.PDB loaded and its respective HALAACPI.DLL. I switched on a
symbol noisy mode in WinDbg and it certainly showed that it loaded
exactly HALAACPI.PDB file.

I’m really stuck. Is it a kind of bug in WinDbg and how can I possibly
force loading correct symbols?

Thanks beforehand, any information will be highly appreciated.

WBR,
Konstantin Manurin
System Programmer
mailto:xxxxx@gmail.com

Tim_Roberts · January 19, 2007, 1:32pm

Konstantin Manurin wrote:

Hi guys,

I use WinDbg 6.6.7.5 and today faced some strange behavior of this tool.
I tried to load symbol files for two modules: HALAACPI.DLL and
HALMACPI.DLL from both free and checked builds of Windows Server 2003 R2
Enterprise Edition. HALAACPI.PDB was successfully loaded. But when I
tried to query symbols for HALMACPI.DLL I received quite a strange
result. WinDbg loaded HALAACPI.PDB file again. Then I tried to do it
several times and got the same result. After quick research I’ve figured
out that this two files, HALACPI.DLL and HALMACPI.DLL, have same
timestamps and image sizes. But these files are totally different.

Yes, but only one can be loaded at a time. There is only one HAL for a
given machine. You’ll have either halaacpi.dll or halmacpi.dll (or one
of the other HALs; I believe there are now 7), and whichever one is
loaded is “the HAL”.

It’s significant to say that primarily I tried to obtain symbols only
for the HALMACPI.DLL module, and I didn’t find HALMACPI.PDB, but there
was HALAACPI.PDB loaded and its respective HALAACPI.DLL. I switched on a
symbol noisy mode in WinDbg and it certainly showed that it loaded
exactly HALAACPI.PDB file.

That means you have a uniprocessor machine with ACPI. If you had a
multiprocessor machine with ACPI, it would have loaded halmacpi.dll
instead, and NOT halaacpi.dll.

I’m really stuck. Is it a kind of bug in WinDbg and how can I possibly
force loading correct symbols?

Why would the system load symbols for a DLL that isn’t loaded?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Konstantin_Manurin · January 19, 2007, 2:04pm

Thanks for a quick reply. I will be more precise about describing this
problem.

I load these modules into WinDbg as crash dump files (WinDbg allows this
trick) to simply receive symbol files from the MS symbol server and
store them into a local folder for future use. So when I load
HALMACPI.DLL, I receive HALAACPI.PDB file instead of HALMACPI.PDB.
That’s it. I checked HALAACPI.DLL and HALMACPI.DLL and saw that both of
these modules have the same time stamps and image sizes (these values,
as I understood, are used to build a folder path name for storing a
loaded module in a local symbol server directory). Strange but
HALMACPI.DLL contains a valid PDB file name in its Debug Directory, but
nevertheless WinDbg persistently loads a wrong symbol file.

WBR,
Konstantin Manurin
System Programmer

OSR_Community_User · January 20, 2007, 7:46am

You don’t have hyperthreading turned off, or have booted with the ONECPU
option? While we’re at it, if you don’t mind, disconnect WinDbg, delete
your local symbol cache and reboot the machine with an early breakpoint
set (/BREAK, HALBREAKPOINT or -d). Upon first entry to WinDbg, turn on
every option you can with .symopt, issue a .reload -f -n, issue a !dh -a
[ADDRESS OF HAL], issue and lml, and finally post a copy of the output.
I’ll take a look.

mm

>> xxxxx@gmail.com 2007-01-19 14:04 >>>
Thanks for a quick reply. I will be more precise about describing this
problem.

I load these modules into WinDbg as crash dump files (WinDbg allows
this
trick) to simply receive symbol files from the MS symbol server and
store them into a local folder for future use. So when I load
HALMACPI.DLL, I receive HALAACPI.PDB file instead of HALMACPI.PDB.
That’s it. I checked HALAACPI.DLL and HALMACPI.DLL and saw that both
of
these modules have the same time stamps and image sizes (these values,
as I understood, are used to build a folder path name for storing a
loaded module in a local symbol server directory). Strange but
HALMACPI.DLL contains a valid PDB file name in its Debug Directory,
but
nevertheless WinDbg persistently loads a wrong symbol file.

WBR,
Konstantin Manurin
System Programmer

You are currently subscribed to windbg as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Konstantin_Manurin · January 22, 2007, 5:51am

No, I don’t perform a remote debugging. I simply load HALMACPI.DLL as a
crash dump file on my working machine. The following is a sequence of my
actions:

Run WinDbg
Press Ctrl-S to set a local symbol files path and MS downstream server
Enter “srv*C:\11\symbols*http://msdl.microsoft.com/download/symbols”
to download symbols from the MS downstream server and store it locally
in “C:\11” folder (as a local symbol server)
Press Ctrl-D to open a crash dump file
Choose the HALMACPI.DLL file
Enter “.reload /u” to unload all modules (just in case for experiment
purity)
Delete a local symbol server directory in “C:\11” (just in case for
experiment purity)
Enter “!sym noisy” to switch on the detailed symbol prompts
Enter “.reload /f halmacpi.dll” to reload HALMACPI.DLL symbols only

And that’s what I saw in a WinDbg command window:

Loading Dump File [C:\11\halmacpi.dll]
DBGHELP: Symbol Search Path:
srv*C:\11\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is:
srv*C:\11\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
DBGHELP: SharedUserData - virtual symbol module
ModLoad: 80010000 8003c000 C:\11\halmacpi.dll

eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000
edi=00000000
eip=80036e7e esp=00000000 ebp=00000000 iopl=0 nv up di pl nz na
po nc
cs=0000 ss=0000 ds=0000 es=0000 fs=0000 gs=0000
efl=00000000
SYMSRV: halaacpi.dll from http://msdl.microsoft.com/download/symbols:
50243 bytes copied
DBGHELP: C:\11\symbols\halaacpi.dll\42435B352c000\halaacpi.dll - OK
DBGENG: C:\11\symbols\halaacpi.dll\42435B352c000\halaacpi.dll - Mapped
image memory
SYMSRV: halaacpi.pdb from http://msdl.microsoft.com/download/symbols:
41651 bytes copied
DBGHELP: halmacpi - public symbols

C:\11\symbols\halaacpi.pdb\36AC14DB1A0C4BC690CCAD40912790C91\halaacpi.pdb
halmacpi!HalpMcaInit+0x1d8:
80036e7e 4d dec ebp

You can clearly see that totally wrong symbols were loaded (obviously,
“dec ebp” is a kind of strange initial command)

Here I performed a symbol reloading action:

0:000> !sym noisy
noisy mode - symbol prompts on
0:000> .reload /f halmacpi.dll
SYMSRV: halaacpi.dll from http://msdl.microsoft.com/download/symbols:
50243 bytes copied
DBGHELP: C:\11\symbols\halaacpi.dll\42435B352c000\halaacpi.dll - OK
DBGENG: C:\11\symbols\halaacpi.dll\42435B352c000\halaacpi.dll - Mapped
image memory
SYMSRV: halaacpi.pdb from http://msdl.microsoft.com/download/symbols:
41651 bytes copied
DBGHELP: halmacpi - public symbols

C:\11\symbols\halaacpi.pdb\36AC14DB1A0C4BC690CCAD40912790C91\halaacpi.pdb

Why did WinDbg load a wrong symbol file and its respective DLL module
(HALAACPI.DLL)??? I always loaded different kernel modules in such a way
to receive their symbol files, including symbols for different flavors
of HAL, but I never had any problems.

But HALMPS.DLL symbols were perfectly loaded (from Windows Server 2003 R2):

Loading Dump File [C:\11\halmps.dll]
DBGHELP: Symbol Search Path:
srv*C:\11\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is:
srv*C:\11\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
DBGHELP: SharedUserData - virtual symbol module
ModLoad: 80010000 80040000 C:\11\halmps.dll

eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000
edi=00000000
eip=8003a404 esp=00000000 ebp=00000000 iopl=0 nv up di pl nz na
po nc
cs=0000 ss=0000 ds=0000 es=0000 fs=0000 gs=0000
efl=00000000
SYMSRV: C:\11\symbols\halaacpi.dll\42435B3B30000\halaacpi.dll not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/halaacpi.dll/42435B3B30000/halaacpi.dll
not found
SYMSRV: C:\11\symbols\halacpi.dll\42435B3B30000\halacpi.dll not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/halacpi.dll/42435B3B30000/halacpi.dll
not found
SYMSRV: C:\11\symbols\halapic.dll\42435B3B30000\halapic.dll not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/halapic.dll/42435B3B30000/halapic.dll
not found
SYMSRV: C:\11\symbols\halmacpi.dll\42435B3B30000\halmacpi.dll not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/halmacpi.dll/42435B3B30000/halmacpi.dll
not found
SYMSRV: halmps.dll from http://msdl.microsoft.com/download/symbols:
55215 bytes copied
DBGHELP: C:\11\symbols\halmps.dll\42435B3B30000\halmps.dll - OK
DBGENG: C:\11\symbols\halmps.dll\42435B3B30000\halmps.dll - Mapped
image memory
SYMSRV: halmps.pdb from http://msdl.microsoft.com/download/symbols:
42019 bytes copied
DBGHELP: halmps - public symbols

C:\11\symbols\halmps.pdb\ABED21B5A009406B88A681CBB40220951\halmps.pdb
halmps!HalInitSystem:
8003a404 8bff mov edi,edi

And at last, this is an output for HALMACPI.DLL module from Windows
Vista RTM 6000

Loading Dump File [C:\11\halmacpi.dll]
DBGHELP: Symbol Search Path:
srv*C:\11\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is:
srv*C:\11\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
DBGHELP: SharedUserData - virtual symbol module
ModLoad: 80010000 80044000 C:\11\halmacpi.dll

eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000
edi=00000000
eip=80032b3c esp=00000000 ebp=00000000 iopl=0 nv up di pl nz na
po nc
cs=0000 ss=0000 ds=0000 es=0000 fs=0000 gs=0000
efl=00000000
SYMSRV: C:\11\symbols\halaacpi.dll\4549AC9A34000\halaacpi.dll not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/halaacpi.dll/4549AC9A34000/halaacpi.dll
not found
SYMSRV: C:\11\symbols\halacpi.dll\4549AC9A34000\halacpi.dll not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/halacpi.dll/4549AC9A34000/halacpi.dll
not found
SYMSRV: C:\11\symbols\halapic.dll\4549AC9A34000\halapic.dll not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/halapic.dll/4549AC9A34000/halapic.dll
not found
SYMSRV: halmacpi.dll from http://msdl.microsoft.com/download/symbols:
80777 bytes copied
DBGHELP: C:\11\symbols\halmacpi.dll\4549AC9A34000\halmacpi.dll - OK
DBGENG: C:\11\symbols\halmacpi.dll\4549AC9A34000\halmacpi.dll - Mapped
image memory
SYMSRV: halmacpi.pdb from http://msdl.microsoft.com/download/symbols:
69163 bytes copied
DBGHELP: halmacpi - public symbols

C:\11\symbols\halmacpi.pdb\AE84FF5D9CEE4D64927E629F756036841\halmacpi.pdb
halmacpi!HalInitSystem:
80032b3c 8bff mov edi,edi

It was totally ok.

But now I have suspicion why WinDbg loads totally wrong symbols. You can
clearly see that first WinDbg checks HALAACPI.DLL, then HALACPI.DLL,
then HALAPIC.DLL and finally HALMACPI.DLL. So as I wrote earlier,
HALAACPI.DLL and HALMACPI.DLL from Windows Server 2003 R2 have the same
time stamps and image sizes, so I can suppose that WinDbg simply loads
the first appropriate HAL module which contains proper time stamp and
image size (in my case, it’s HALAACPI.DLL), and since WinDbg first
checks HALAACPI.DLL module, I receive symbols exactly for this module.

WBR,
Konstantin Manurin
System Programmer

You don’t have hyperthreading turned off, or have booted with the ONECPU
option? While we’re at it, if you don’t mind, disconnect WinDbg, delete
your local symbol cache and reboot the machine with an early breakpoint
set (/BREAK, HALBREAKPOINT or -d). Upon first entry to WinDbg, turn on
every option you can with .symopt, issue a .reload -f -n, issue a !dh -a
[ADDRESS OF HAL], issue and lml, and finally post a copy of the output.
I’ll take a look.

mm

Konstantin_Manurin · January 22, 2007, 6:08am

Oh, it’s a miracle! I have just used .symopt command with 0x400 argument
(SYMOPT_EXACT_SYMBOLS) and it’s really worked out. Here’s an output:

0:000> .reload /f halmacpi.dll
DBGENG: C:\11\symbols\halaacpi.dll\42435B352c000\halaacpi.dll image
header does not match memory image header.
DBGHELP: C:\11\symbols\halaacpi.dll\42435B352c000\halaacpi.dll - mismatched
SYMSRV: C:\11\symbols\halacpi.dll\42435B352c000\halacpi.dll not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/halacpi.dll/42435B352c000/halacpi.dll
not found
SYMSRV: C:\11\symbols\halapic.dll\42435B352c000\halapic.dll not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/halapic.dll/42435B352c000/halapic.dll
not found
SYMSRV: halmacpi.dll from http://msdl.microsoft.com/download/symbols:
51265 bytes copied
DBGHELP: C:\11\symbols\halmacpi.dll\42435B352c000\halmacpi.dll - OK
DBGENG: C:\11\symbols\halmacpi.dll\42435B352c000\halmacpi.dll - Mapped
image memory
SYMSRV: halmacpi.pdb from http://msdl.microsoft.com/download/symbols:
42573 bytes copied
DBGHELP: halmacpi - public symbols

C:\11\symbols\halmacpi.pdb\3FC80D1EB1B8427FB9E1ABA54E14CA411\halmacpi.pdb

Martin, thank you very much for this helpful suggestion. I have already
found -ses command line switch to force WinDbg to load strictly exact
symbol files. Simply I use a BAT-file to run WinDbg in a loop for all
necessary kernel modules to receive symbols for them and store these
symbol files in a local folder for future use.

Once again, thanks a lot for this information.

With best regards,
Konstantin Manurin
System Programmer

OSR_Community_User · January 22, 2007, 1:36pm

No problem. To be perfectly honest, I had even considered what you
found to actually work. I was just trying to get as much information as
possible to display, and EXACT hadn’t even crossed my mind. In any
case, I’m glad you solved your problem.

mm

>> xxxxx@gmail.com 2007-01-22 06:08 >>>
Oh, it’s a miracle! I have just used .symopt command with 0x400
argument
(SYMOPT_EXACT_SYMBOLS) and it’s really worked out. Here’s an output:

0:000> .reload /f halmacpi.dll
DBGENG: C:\11\symbols\halaacpi.dll\42435B352c000\halaacpi.dll image
header does not match memory image header.
DBGHELP: C:\11\symbols\halaacpi.dll\42435B352c000\halaacpi.dll -
mismatched
SYMSRV: C:\11\symbols\halacpi.dll\42435B352c000\halacpi.dll not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/halacpi.dll/42435B352c000/halacpi.dll

not found
SYMSRV: C:\11\symbols\halapic.dll\42435B352c000\halapic.dll not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/halapic.dll/42435B352c000/halapic.dll

not found
SYMSRV: halmacpi.dll from http://msdl.microsoft.com/download/symbols:

51265 bytes copied
DBGHELP: C:\11\symbols\halmacpi.dll\42435B352c000\halmacpi.dll - OK
DBGENG: C:\11\symbols\halmacpi.dll\42435B352c000\halmacpi.dll -
Mapped
image memory
SYMSRV: halmacpi.pdb from http://msdl.microsoft.com/download/symbols:

42573 bytes copied
DBGHELP: halmacpi - public symbols

C:\11\symbols\halmacpi.pdb\3FC80D1EB1B8427FB9E1ABA54E14CA411\halmacpi.pdb

Martin, thank you very much for this helpful suggestion. I have
already
found -ses command line switch to force WinDbg to load strictly exact
symbol files. Simply I use a BAT-file to run WinDbg in a loop for all
necessary kernel modules to receive symbols for them and store these
symbol files in a local folder for future use.

Once again, thanks a lot for this information.

With best regards,
Konstantin Manurin
System Programmer

You are currently subscribed to windbg as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com