Given a dump file or live system, I use vertarget to find the executable’s version info.
Given a .pdb file, can I get the same information? For example, using dbh.exe?
vertarget does not provide any executable version info as far as i know
are you sure?
can you paste an output ?
you can manually try matching pdb signature in dbh
C:\Documents and Settings\Admin\Desktop>dbh dir ActXPrxy.pdb f:\SYMBOLS\
f:\SYMBOLS\actxprxy.pdb\C9391764905144B7AE384BB966CF79562\actxprxy.pdb
f:\SYMBOLS\actxprxy.pdb\EDBCB121A075480095CB48E4B80BF0402\actxprxy.pdb
f:\SYMBOLS\actxprxy.pdb\F3D626B3AFFC4A91A8605582B7D203282\ActXPrxy.pdb
C:\Documents and Settings\Admin\Desktop>dbh c:\WINDOWS\system32\actxprxy.dll inf
o | grep 70
PdbSig70 : 0xedbcb121, 0xa075, 0x4800, 0x95, 0xcb, 0x48, 0xe4, 0xb8, 0x0
b, 0xf0, 0x40
C:\Documents and Settings\Admin\Desktop>so the 2nd pdb matches my
current os actxprxy.dll
see the edbcb121
On 11/2/12, xxxxx@yahoo.com wrote:
> Given a dump file or live system, I use vertarget to find the executable’s
> version info.
>
> Given a .pdb file, can I get the same information? For example, using
> dbh.exe?
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
This is what I call executable version info
0: kd> vertarget
Windows 8 Kernel Version 9200 MP (4 procs) Free ARM (NT) Thumb-2
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9200.16442.armfre.win8_gdr.121023-1503
Machine Name:
Kernel base = 0x8381c000 PsLoadedModuleList = 0x839df8e0
Debug session time: Fri Oct 26 19:27:19.268 2012 (UTC - 7:00)
System Uptime: 0 days 0:03:32.993
No such stuff in pdb.
– pa
On 02-Nov-2012 01:27, xxxxx@yahoo.com wrote:
This is what I call executable version info
0: kd> vertarget
Windows 8 Kernel Version 9200 MP (4 procs) Free ARM (NT) Thumb-2
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9200.16442.armfre.win8_gdr.121023-1503
Machine Name:
Kernel base = 0x8381c000 PsLoadedModuleList = 0x839df8e0
Debug session time: Fri Oct 26 19:27:19.268 2012 (UTC - 7:00)
System Uptime: 0 days 0:03:32.993
On 11/2/12, xxxxx@yahoo.com wrote:
> This is what I call executable version info
>
> 0: kd> vertarget
sorry pdb is built for an executable not for an operating system so
pdb might contain information about a specific executable not about os
and i think executable version info is what lm v m provides
lkd> lm v m nt
start end module name
804d7000 806cf980 nt (pdb symbols) f:\symbols\ntkrnlpa.pdb\4B
F71966DA15428C9532FDC1F6886F571\ntkrnlpa.pdb
Loaded symbol image file: ntkrnlpa.exe
Image path: ntkrnlpa.exe
Image name: ntkrnlpa.exe
Timestamp: Tue Feb 16 18:55:00 2010 (4B7A9CAC)
CheckSum: 001F8A2D
ImageSize: 001F8980
File version: 5.1.2600.5938
Product version: 5.1.2600.5938
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft« Windows« Operating System
InternalName: ntkrnlpa.exe
OriginalFilename: ntkrnlpa.exe
ProductVersion: 5.1.2600.5938
FileVersion: 5.1.2600.5938 (xpsp_sp3_gdr.100216-1514)
FileDescription: NT Kernel & System
LegalCopyright: ⌐ Microsoft Corporation. All rights reserved.
lkd>
The version information is stored in the VERSIONINFO resource. As far as
I know, no trace of this information makes it to the .pdb files. .pdb
files don’t care about version numbers in any way whatsoever; they use the
build timestamp which is written to both the executable file and the .pdb.
Compile your program tomorrow, and even if the resulting executable is
almost-bitwise-identical to yesterday’s executable image, at least one
difference will be in the build timestamp, so as far as the debugger is
concerned, tomorrow’s .pdb file is useless to analyze yesterday’s dump.
Even though the VERSIONINFO in both is identical. This is why you always
have to archive the actual .pdb generated for your product build, so you
have it available to analyze dumps.
joe
Given a dump file or live system, I use vertarget to find the executable’s
version info.Given a .pdb file, can I get the same information? For example, using
dbh.exe?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
What is not clear from this output is what information comes from the .pdb
file and what information comes from the VERSIONINFO resource in the
executable, since it has the loaded symbol image file, and getting that
information fron the file is trivial.
joe
On 11/2/12, xxxxx@yahoo.com wrote:
>> This is what I call executable version info
>>
>> 0: kd> vertarget
>
> sorry pdb is built for an executable not for an operating system so
> pdb might contain information about a specific executable not about os
>
> and i think executable version info is what lm v m provides
>
> lkd> lm v m nt
> start end module name
> 804d7000 806cf980 nt (pdb symbols)
> f:\symbols\ntkrnlpa.pdb\4B
> F71966DA15428C9532FDC1F6886F571\ntkrnlpa.pdb
> Loaded symbol image file: ntkrnlpa.exe
> Image path: ntkrnlpa.exe
> Image name: ntkrnlpa.exe
> Timestamp: Tue Feb 16 18:55:00 2010 (4B7A9CAC)
> CheckSum: 001F8A2D
> ImageSize: 001F8980
> File version: 5.1.2600.5938
> Product version: 5.1.2600.5938
> File flags: 0 (Mask 3F)
> File OS: 40004 NT Win32
> File type: 1.0 App
> File date: 00000000.00000000
> Translations: 0409.04b0
> CompanyName: Microsoft Corporation
> ProductName: Microsoft« Windows« Operating System
> InternalName: ntkrnlpa.exe
> OriginalFilename: ntkrnlpa.exe
> ProductVersion: 5.1.2600.5938
> FileVersion: 5.1.2600.5938 (xpsp_sp3_gdr.100216-1514)
> FileDescription: NT Kernel & System
> LegalCopyright: ⌠Microsoft Corporation. All rights reserved.
> lkd>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
On 11/2/12, xxxxx@flounder.com wrote:
>
> What is not clear from this output is what information comes from the .pdb
> file and what information comes from the VERSIONINFO resource in the
> executable, since it has the loaded symbol image file, and getting that
> information fron the file is trivial.
all the version info of the command lm vm comes purely from image file
not symbol file
lm vm will work if there is no symbol file loaded
or
if no symbol file exists
and even
if you forcefully discard symbol information
for example you can force .sympath to some dir which doesn’t have any
symbol file
and then do a lm vm and you will still get version info if it exists in exe
0:000> lm m windbg
start end module name
01000000 01097000 windbg (no symbols)
0:000> lm vm windbg
start end module name
01000000 01097000 windbg (no symbols)
Loaded symbol image file: F:\windbg\612windbg\windbg.exe
Image path: windbg.exe
Image name: windbg.exe
Timestamp: Tue Feb 02 01:38:35 2010 (4B6734C3)
CheckSum: 0008F0A9
ImageSize: 00097000
File version: 6.12.2.633
Product version: 6.12.2.633
File flags: 8 (Mask 3F) Private
File OS: 40004 NT Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Debugging Tools for Windows(R)
InternalName: windbg.exe
OriginalFilename: windbg.exe
ProductVersion: 6.12.0002.633
FileVersion: 6.12.0002.633 (debuggers(dbg).100201-1203)
FileDescription: Windows GUI symbolic debugger
LegalCopyright: ? Microsoft Corporation. All rights reserved.
and if versioninfo doesnt exist in exe only what is in header will be provided
0:000> lm m image00400000
start end module name
00400000 00406000 image00400000 C (no symbols)
0:000> lm vm image00400000
start end module name
00400000 00406000 image00400000 C (no symbols)
Loaded symbol image file: C:\Documents and
Settings\Admin\Desktop\DummyExe.exe
Image path: image00400000
Image name: image00400000
Timestamp: Fri Dec 30 01:32:12 2011 (4EFCC744)
CheckSum: 00000000
ImageSize: 00006000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
So for the OP, this answers the question: version information is NOT
stored in the .pdb file.
joe
On 11/2/12, xxxxx@flounder.com wrote:
>>
>> What is not clear from this output is what information comes from the
>> .pdb
>> file and what information comes from the VERSIONINFO resource in the
>> executable, since it has the loaded symbol image file, and getting that
>> information fron the file is trivial.
>
> all the version info of the command lm vm comes purely from image file
> not symbol file
>
> lm vm will work if there is no symbol file loaded
> or
> if no symbol file exists
> and even
> if you forcefully discard symbol information
>
>
> for example you can force .sympath to some dir which doesn’t have any
> symbol file
> and then do a lm vm and you will still get version info if it exists in
> exe
>
> 0:000> lm m windbg
> start end module name
> 01000000 01097000 windbg (no symbols)
> 0:000> lm vm windbg
> start end module name
> 01000000 01097000 windbg (no symbols)
> Loaded symbol image file: F:\windbg\612windbg\windbg.exe
> Image path: windbg.exe
> Image name: windbg.exe
> Timestamp: Tue Feb 02 01:38:35 2010 (4B6734C3)
> CheckSum: 0008F0A9
> ImageSize: 00097000
> File version: 6.12.2.633
> Product version: 6.12.2.633
> File flags: 8 (Mask 3F) Private
> File OS: 40004 NT Win32
> File type: 1.0 App
> File date: 00000000.00000000
> Translations: 0409.04b0
> CompanyName: Microsoft Corporation
> ProductName: Debugging Tools for Windows(R)
> InternalName: windbg.exe
> OriginalFilename: windbg.exe
> ProductVersion: 6.12.0002.633
> FileVersion: 6.12.0002.633 (debuggers(dbg).100201-1203)
> FileDescription: Windows GUI symbolic debugger
> LegalCopyright: © Microsoft Corporation. All rights reserved.
>
> and if versioninfo doesnt exist in exe only what is in header will be
> provided
>
> 0:000> lm m image00400000
> start end module name
> 00400000 00406000 image00400000 C (no symbols)
> 0:000> lm vm image00400000
> start end module name
> 00400000 00406000 image00400000 C (no symbols)
> Loaded symbol image file: C:\Documents and
> Settings\Admin\Desktop\DummyExe.exe
> Image path: image00400000
> Image name: image00400000
> Timestamp: Fri Dec 30 01:32:12 2011 (4EFCC744)
> CheckSum: 00000000
> ImageSize: 00006000
> Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Kind of an odd representation, since I see no version information about
the executable here. It tells you what version of the OS it was built
for, but actual version information about the executable image, such as
you would see if you right-clcked on the executable file in Windows
Explorer and went to the “Version” tab, is conspicuously absent below.
What you are seeing are /properties/ of the executable image, not its
/version/, a term which has a well-defined meaning in Windows: the 4-tuple
major.minor.point.build. I would not refer to any of the information
below as “version” information except that this is probably derived from
interpreting flags in the VERSIONINFO resource, which is where these
properties are also stored.
And no, as far as I know, absolutely none of this appears in the .pdb
file. The point is that if you know the executable is foo.sys, then its
symbols are found in foo.pdb which is located by looking at the symbol
search path. In most environments of heavy development, you will have a
local symbol server with all the .pdb files for ptentially debuggable
versions; the symbol server will select the correct one by matching the
timestamp in the header of the executable with the timestamp of the
correspndingly-named .pdb file the symbol server has in its database;
otherwise, I believe the search stops when the first foo.pdb is found in
the path. If the build timestamp in the dump or running system matches
the timestamp in this .pdb file, all is cool, but if I recall correctly
(and this may have changed) it does not continue the search looking for
other foo.pdb files, which is why when you have multiple versions “in the
wild” (even if this is the test engineer in the adjacent cubicle), you
will want to use the symbol server and add your own local server ahead of
the spec for the Microsoft server.
Why do you care about version information in the .pdb file? Or, to
rephrase in the canonical question, what problem are you trying to solve?
joe
This is what I call executable version info
0: kd> vertarget
Windows 8 Kernel Version 9200 MP (4 procs) Free ARM (NT) Thumb-2
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9200.16442.armfre.win8_gdr.121023-1503
Machine Name:
Kernel base = 0x8381c000 PsLoadedModuleList = 0x839df8e0
Debug session time: Fri Oct 26 19:27:19.268 2012 (UTC - 7:00)
System Uptime: 0 days 0:03:32.993
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>And no, as far as I know, absolutely none of this appears in the .pdb file.
The point is that if you know the executable is foo.sys, then its symbols
are found in foo.pdb which is located by looking at the symbol search path.
In most environments of heavy >development, you will have a local symbol
server with all the .pdb files for ptentially debuggable versions; the
symbol server will select the correct one by matching the timestamp in the
header of the executable with the timestamp of the correspndingly->named
.pdb file the symbol server has in its database; otherwise, I believe the
search stops when the first foo.pdb is found in the path. If the build
timestamp in the dump or running system matches the timestamp in this .pdb
file, all is cool, but if I recall >correctly (and this may have changed) it
does not continue the search looking for other foo.pdb files, which is why
when you have multiple versions “in the wild” (even if this is the test
engineer in the adjacent cubicle), you will want to use the symbol >server
and add your own local server ahead of the spec for the Microsoft server.
That’s not correct for any remotely recent version of CL - it uses the
embedded UUID and “age” in the exe to match the pdb.
If you look at the directory structure of a symbol server, that’s where it
comes from:
ntkrnlmp.pdb\3844DBB920174967BE7AA4A2C20430FA2\
uuid: 3844DBB920174967BE7AA4A2C20430FA
age: 2
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@flounder.com
Sent: Friday, November 02, 2012 11:47 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Find the corresponding executable from a symbol file
Kind of an odd representation, since I see no version information about
the executable here. It tells you what version of the OS it was built
for, but actual version information about the executable image, such as you
would see if you right-clcked on the executable file in Windows Explorer and
went to the “Version” tab, is conspicuously absent below.
What you are seeing are /properties/ of the executable image, not its
/version/, a term which has a well-defined meaning in Windows: the 4-tuple
major.minor.point.build. I would not refer to any of the information below
as “version” information except that this is probably derived from
interpreting flags in the VERSIONINFO resource, which is where these
properties are also stored.
And no, as far as I know, absolutely none of this appears in the .pdb file.
The point is that if you know the executable is foo.sys, then its symbols
are found in foo.pdb which is located by looking at the symbol search path.
In most environments of heavy development, you will have a local symbol
server with all the .pdb files for ptentially debuggable versions; the
symbol server will select the correct one by matching the timestamp in the
header of the executable with the timestamp of the correspndingly-named .pdb
file the symbol server has in its database; otherwise, I believe the search
stops when the first foo.pdb is found in the path. If the build timestamp
in the dump or running system matches the timestamp in this .pdb file, all
is cool, but if I recall correctly (and this may have changed) it does not
continue the search looking for other foo.pdb files, which is why when you
have multiple versions “in the wild” (even if this is the test engineer in
the adjacent cubicle), you will want to use the symbol server and add your
own local server ahead of the spec for the Microsoft server.
Why do you care about version information in the .pdb file? Or, to rephrase
in the canonical question, what problem are you trying to solve?
joe
This is what I call executable version info
0: kd> vertarget
Windows 8 Kernel Version 9200 MP (4 procs) Free ARM (NT) Thumb-2
Product: WinNt, suite: TerminalServer SingleUserTS Built by:
9200.16442.armfre.win8_gdr.121023-1503
Machine Name:
Kernel base = 0x8381c000 PsLoadedModuleList = 0x839df8e0 Debug session
time: Fri Oct 26 19:27:19.268 2012 (UTC - 7:00) System Uptime: 0 days
0:03:32.993
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
xxxxx@yahoo.com wrote:
This is what I call executable version info
0: kd> vertarget
Windows 8 Kernel Version 9200 MP (4 procs) Free ARM (NT) Thumb-2
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9200.16442.armfre.win8_gdr.121023-1503
Machine Name:
Kernel base = 0x8381c000 PsLoadedModuleList = 0x839df8e0
Debug session time: Fri Oct 26 19:27:19.268 2012 (UTC - 7:00)
System Uptime: 0 days 0:03:32.993
Now, are we all clear that this is showing us the version information
from the target system’s kernel – the exact same information you get
when you start a kernel debug session? This is not information about
any specific executable.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>versions; the symbol server will select the correct one by matching the
timestamp in the header of the executable with the timestamp of the
correspndingly-named .pdb file t
the pdb from pdb70 signature (RSDS ) onwards ie post (w2k spX) or
link version >= 7
link is no > 9
isnt based on time stamp stuff it is based on a uuid and age
On 11/3/12, Martin O’Brien wrote:
>>And no, as far as I know, absolutely none of this appears in the .pdb
>> file.
> The point is that if you know the executable is foo.sys, then its symbols
> are found in foo.pdb which is located by looking at the symbol search path.
> In most environments of heavy >development, you will have a local symbol
> server with all the .pdb files for ptentially debuggable versions; the
> symbol server will select the correct one by matching the timestamp in the
> header of the executable with the timestamp of the correspndingly->named
> .pdb file the symbol server has in its database; otherwise, I believe the
> search stops when the first foo.pdb is found in the path. If the build
> timestamp in the dump or running system matches the timestamp in this .pdb
> file, all is cool, but if I recall >correctly (and this may have changed)
> it
> does not continue the search looking for other foo.pdb files, which is why
> when you have multiple versions “in the wild” (even if this is the test
> engineer in the adjacent cubicle), you will want to use the symbol >server
> and add your own local server ahead of the spec for the Microsoft server.
>
> That’s not correct for any remotely recent version of CL - it uses the
> embedded UUID and “age” in the exe to match the pdb.
>
> If you look at the directory structure of a symbol server, that’s where it
> comes from:
>
> ntkrnlmp.pdb\3844DBB920174967BE7AA4A2C20430FA2<br>>
> uuid: 3844DBB920174967BE7AA4A2C20430FA
> age: 2
>
>
>
> mm
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@flounder.com
> Sent: Friday, November 02, 2012 11:47 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Find the corresponding executable from a symbol file
>
> Kind of an odd representation, since I see no version information about
> the executable here. It tells you what version of the OS it was built
> for, but actual version information about the executable image, such as you
> would see if you right-clcked on the executable file in Windows Explorer
> and
> went to the “Version” tab, is conspicuously absent below.
> What you are seeing are /properties/ of the executable image, not its
> /version/, a term which has a well-defined meaning in Windows: the 4-tuple
> major.minor.point.build. I would not refer to any of the information below
> as “version” information except that this is probably derived from
> interpreting flags in the VERSIONINFO resource, which is where these
> properties are also stored.
>
> And no, as far as I know, absolutely none of this appears in the .pdb file.
> The point is that if you know the executable is foo.sys, then its symbols
> are found in foo.pdb which is located by looking at the symbol search path.
> In most environments of heavy development, you will have a local symbol
> server with all the .pdb files for ptentially debuggable versions; the
> symbol server will select the correct one by matching the timestamp in the
> header of the executable with the timestamp of the correspndingly-named
> .pdb
> file the symbol server has in its database; otherwise, I believe the search
> stops when the first foo.pdb is found in the path. If the build timestamp
> in the dump or running system matches the timestamp in this .pdb file, all
> is cool, but if I recall correctly (and this may have changed) it does not
> continue the search looking for other foo.pdb files, which is why when you
> have multiple versions “in the wild” (even if this is the test engineer in
> the adjacent cubicle), you will want to use the symbol server and add your
> own local server ahead of the spec for the Microsoft server.
>
> Why do you care about version information in the .pdb file? Or, to
> rephrase
> in the canonical question, what problem are you trying to solve?
> joe
>
>> This is what I call executable version info
>>
>> 0: kd> vertarget
>> Windows 8 Kernel Version 9200 MP (4 procs) Free ARM (NT) Thumb-2
>> Product: WinNt, suite: TerminalServer SingleUserTS Built by:
>> 9200.16442.armfre.win8_gdr.121023-1503
>> Machine Name:
>> Kernel base = 0x8381c000 PsLoadedModuleList = 0x839df8e0 Debug session
>> time: Fri Oct 26 19:27:19.268 2012 (UTC - 7:00) System Uptime: 0 days
>> 0:03:32.993
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>