Hi All,
WinDbg Symbol Server cache is organized as set of directories - one per file version.
E.g.
[ntkrpamp.pdb]
[3A51F333EC3E4943A617AFC47C95C4751]
ntkrpamp.pdb
[585DF1D2A8974184820DF55DC252C0B61]
ntkrpamp.pdb
How is possible to find out to which version (or which Build) of Windows belongs each symbol file?
Please notice, that SymGetModuleInfo64 is not able provide this information.
Thank you in advance for help.
Al
Not sure if you can tel lit from the PDB, but you can definitely see it
in the binary (DLL, SYS, EXE), because Microsoft versions them the
same way like Windows itself (talking about internal version, aka
kernel32.dll from Win7 SP1 has version 6.1.6701.xxxx.
So, you need to parse the resource section, to find the module version.
L.
Hi Zadislav,
Thank you for reply.
If binary is available - there is no question. My question was: how to associate particular PDB with Windows Build number. As you may see, symbol server stores PDBs in directory with 128-bit names. It’s probably GUID or any other form that encodes Build number and/or release date. Do anybody know how to decode this information?
Al
The linker generates this GUID to represent the specific invocation of link, it has nothing to do with the build number of Windows. That being said, if you know the GUID for a build you could create a reverse mapping database for GUID to build number (see !chksym for getting the GUID from a module). But why would you need this? It’s unusual to want to go from PDB to SYS.
-scott
OSR
@OSRDrivers
There’s an age value tacked onto the end of that GUID. It is supposed to
indicate (as I understand it) the number of times that an image has been
modified since it was fully rebuilt, though I’m not sure that makes a lot
of sense to me.
Anyway, given a symbol directory entry:
$ dir ntkrnlmp.pdb
Volume in drive C is OS
Volume Serial Number is 2666-B35C
Directory of ntkrnlmp.pdb
03/21/2016 05:38 PM
.Hi mm,
When I’m executing dumpbin /HEADERS c:\windows\system32\ntoskrnl.exe | findstr /i /c:“RSDS”
I’m getting:
c:\>“c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\dumpbin.exe” /HEADERS c:\windows\system32\ntoskrnl.exe | findstr /i /c:“RSDS”
56CD4410 cv 25 00256940 253B40 Format: RSDS, {F7971FB6-AA7E-450C-BCA7-054A98D65942}, 1, ntkrnlmp.pdb
C:\>
while symbols are in [1AE612EB37854469B2DA37990879513E1] directory.
I do not see connection between GUID I’m getting and directory name. Any suggestion?
With best regards,
Al
I intentionally picked the symbol directory that contained the pdb that
matches my ntoskrnl.exe on my machine.
To do what you want, you’ll have to search through existing binaries and
see what matches.
Good luck,
mm
On Sun, Apr 10, 2016 at 2:20 PM, wrote:
> Hi mm,
>
> When I’m executing dumpbin /HEADERS c:\windows\system32\ntoskrnl.exe |
> findstr /i /c:“RSDS”
>
> I’m getting:
>
> c:>“c:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\bin\amd64\dumpbin.exe” /HEADERS c:\windows\system32\ntoskrnl.exe |
> findstr /i /c:“RSDS”
>
> 56CD4410 cv 25 00256940 253B40 Format: RSDS,
> {F7971FB6-AA7E-450C-BCA7-054A98D65942}, 1, ntkrnlmp.pdb
>
> C:>
>
> while symbols are in [1AE612EB37854469B2DA37990879513E1] directory.
>
> I do not see connection between GUID I’m getting and directory name. Any
> suggestion?
>
> With best regards,
>
> Al
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
Hi Scott,
> But why would you need this? It’s unusual to want to go from PDB to SYS.
I wrote a program that getting symbols from x64 and x86 version of symbol files and produces a C++ header file. I need a smart way to match x64 symbols with x86 symbols for the same build of Windows.
With best regards,
Al
Hi mm,
It would mean to create a directory with all possible versions of ntoskrnl.exe for all possible version of Windows and search among all possible binaries. Is it the only way to achieve my goal?
With best regards,
Al
Have you looked at the DIA documentation?
I suspect that there is a way to determine the GUID / age for a PDB.
There’s definitely a function that will verify that GUID you give it is
correct for a given PDB.
Assuming there is, then no, you don’t need the image files for what you’re
doing, it sounds like.
The PDB is not documented, but if you really can’t extract the GUID any
other way, it’s easy to find in the PDB headers.
Some tools that might help:
dbh.exe (comes with windbg)
dia2dump (source code comes with DIA, which comes with VS).
Good luck,
mm
On Sun, Apr 10, 2016 at 2:28 PM, wrote:
> Hi mm,
>
> It would mean to create a directory with all possible versions of
> ntoskrnl.exe for all possible version of Windows and search among all
> possible binaries. Is it the only way to achieve my goal?
>
> With best regards,
>
> Al
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
Hi mm,
> Have you looked at the DIA documentation?
Yes, I did. I would not ask question here otherwise.
With best regards,
Al