symbol path hash values

WINDBG
1

Hi,

Could somebody tell me how are the hash / timestamp (or what are they)
values generated for .SYS and .PDB files? For example, when I issue a
.reload /f XX…X.sys in WinDBG (with !sym noisy on) it shows me that
“SYMSRV: s:\symbols\XX…X.sys\464C19FF27e00\XX…X.sys not found”. Here
how it is generated that particular “464C19FF27e00” value? Also, AFAIK,
the .PDB hash is different than the one generated on .SYS files.

I am currently using “symstore.exe add …” on the current .SYS/.PDB
files, but I also have a pretty big older .SYS / .PDB collection, and I
would like to write a small tool that generates the hash based on a SYS
and a search script that lookups the file in the collection. Any hint
would be appreciated.

have a nice day,

–
Sandor LUKACS
Analyst Programmer, R&D
BitDefender

E-mail: xxxxx@bitdefender.com
Phone : +40 264 443 008

www.bitdefender.com

2

I think that they are just UUID’s, but that maybe wrong. Unless I’m
missing something, they SYS and PDB values should match. HBave you
tried dumpbin /HEADERS and dumpbin /PDBPATH:VERBOSE? The SYS value
comes from the DBG directory, which is documented in the PE documentation.

Good luck,

mm

Sandor LUKACS wrote:

Hi,

Could somebody tell me how are the hash / timestamp (or what are they)
values generated for .SYS and .PDB files? For example, when I issue a
.reload /f XX…X.sys in WinDBG (with !sym noisy on) it shows me that
“SYMSRV: s:\symbols\XX…X.sys\464C19FF27e00\XX…X.sys not found”. Here
how it is generated that particular “464C19FF27e00” value? Also, AFAIK,
the .PDB hash is different than the one generated on .SYS files.

I am currently using “symstore.exe add …” on the current .SYS/.PDB
files, but I also have a pretty big older .SYS / .PDB collection, and I
would like to write a small tool that generates the hash based on a SYS
and a search script that lookups the file in the collection. Any hint
would be appreciated.

have a nice day,

3

Sandor LUKACS wrote:

Could somebody tell me how are the hash / timestamp (or what are they)
values generated for .SYS and .PDB files? For example, when I issue a
.reload /f XX…X.sys in WinDBG (with !sym noisy on) it shows me that
“SYMSRV: s:\symbols\XX…X.sys\464C19FF27e00\XX…X.sys not found”.
Here how it is generated that particular “464C19FF27e00” value? Also,
AFAIK, the .PDB hash is different than the one generated on .SYS files.

For the sys path, the first 8 digits are a timestamp, in seconds since
1/1/1970. The last four digits I can’t figure out. They seem to be
selected from a small set of values. It may be a bit mask; the last two
digits seem to be 80 for a release build and 00 for a checked build.

Martin may be right about the PDB path; it appears to be a UUID with one
incrementing digit added for uniqueness.

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

4

Hello Tim.

The values that are used to calculate the hashes differ dependent upon the type of file and some other edge cases. I guess I should ask what it is you are trying to achieve. Maybe I can help you out. There is an API that can be used to leverage this stuff.

.pat styles

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, November 12, 2007 1:31 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] symbol path hash values

Sandor LUKACS wrote:

Could somebody tell me how are the hash / timestamp (or what are they)
values generated for .SYS and .PDB files? For example, when I issue a
.reload /f XX…X.sys in WinDBG (with !sym noisy on) it shows me that
“SYMSRV: s:\symbols\XX…X.sys\464C19FF27e00\XX…X.sys not found”.
Here how it is generated that particular “464C19FF27e00” value? Also,
AFAIK, the .PDB hash is different than the one generated on .SYS files.

For the sys path, the first 8 digits are a timestamp, in seconds since
1/1/1970. The last four digits I can’t figure out. They seem to be
selected from a small set of values. It may be a bit mask; the last two
digits seem to be 80 for a release build and 00 for a checked build.

Martin may be right about the PDB path; it appears to be a UUID with one
incrementing digit added for uniqueness.

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

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

5

> “SYMSRV: s:\symbols\XX…X.sys\464C19FF27e00\XX…X.sys not found”.

This is a normal behavior. This is just attempt for case the path is
secondary or primary symbol storage. Why are you concentrating just on this
unsuccessful attempt? Later must be an attempt without this GUID. If .pbd
is not loaded it can be because it’s timestamp doesn’t match to timestamp in
the debug section of .sys file.

If you still want to follow dead way there is a DIA SDK which can provide
you pdb internals.

6

Pat Styles wrote:

Hello Tim.

The values that are used to calculate the hashes differ dependent upon the type of file and some other edge cases. I guess I should ask what it is you are trying to achieve. Maybe I can help you out. There is an API that can be used to leverage this stuff.

.pat styles

Thanks for the reply,

I think that I actually found a solution, by using SymSrvGetFileIndexes
API plus some “workarounds”. After some experimenting, I found, that for
.PDB files it used both a GUID (or some PDB signature) and a Val1 value
returned by the API. For .SYS and other files it returns only a DWORD in
the upper part of the GUID (timestamp?) and a Val1 value (filesize?).
Anyway, any clarification / confirmation, or a better API or example
would be greatly appreciated :slight_smile:

I have access to pretty huge older / various .SYS / .PDB collection that
I don’t want to insert into a local symbol store, but from time to time
I need them for different reasons (like bugcheck analysis). When I issue
a !sym noisy and a .reload /f XXX.sys, I can easily see the hash of the
file requested by WinDBG, but without loading all the stuff into a local
symbol store I can’t select the proper .SYS / .PDB or tell if one
exists. However, with the above “workaround” I have created an ordered
list with all the “hash” values and the corresponding files, and thus, I
can very quickly lookup the proper .SYS / .PDB.

Sandor

7

Hello Sandor.

There are other API functions that may be of value, but I guess I would need a more exact understanding of your workflow.

Better yet, why don’t you index all these extra symbols into an separate symbol store from your local cache. But instead of actually moving the files to the store, use pointers. Then you will have a simple index that will work without any concern for what the hash values are.

I don’t have a copy of the help file with me, but you want to use the symstore.exe option that creates file.ptr.

.p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Sandor LUKACS
Sent: Tuesday, November 13, 2007 12:31 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] symbol path hash values

Pat Styles wrote:

Hello Tim.

The values that are used to calculate the hashes differ dependent upon the type of file and some other edge cases. I guess I should ask what it is you are trying to achieve. Maybe I can help you out. There is an API that can be used to leverage this stuff.

.pat styles

Thanks for the reply,

I think that I actually found a solution, by using SymSrvGetFileIndexes
API plus some “workarounds”. After some experimenting, I found, that for
.PDB files it used both a GUID (or some PDB signature) and a Val1 value
returned by the API. For .SYS and other files it returns only a DWORD in
the upper part of the GUID (timestamp?) and a Val1 value (filesize?).
Anyway, any clarification / confirmation, or a better API or example
would be greatly appreciated :slight_smile:

I have access to pretty huge older / various .SYS / .PDB collection that
I don’t want to insert into a local symbol store, but from time to time
I need them for different reasons (like bugcheck analysis). When I issue
a !sym noisy and a .reload /f XXX.sys, I can easily see the hash of the
file requested by WinDBG, but without loading all the stuff into a local
symbol store I can’t select the proper .SYS / .PDB or tell if one
exists. However, with the above “workaround” I have created an ordered
list with all the “hash” values and the corresponding files, and thus, I
can very quickly lookup the proper .SYS / .PDB.

Sandor

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

8

Pat Styles wrote:

Hello Sandor.

There are other API functions that may be of value, but I guess I would need a more exact understanding of your workflow.

Better yet, why don’t you index all these extra symbols into an separate symbol store from your local cache. But instead of actually moving the files to the store, use pointers. Then you will have a simple index that will work without any concern for what the hash values are.

I don’t have a copy of the help file with me, but you want to use the symstore.exe option that creates file.ptr.

.p
Hi,

this is the right solution :slight_smile: by using the /p option I can actually
store only pointers to files…

(maybe next time I should try every single option of a tool…)

have a nice day, thank you very much,

Sandor