GetFileVersionInfo() returns wrong file's version information
Asked Answered
S

2

4

I have an application that is required to check the versions of various system EXEs and DLLs to determine if they are vulnerable or not. This is a native C++ application which does not provide any specific WinSxS linkages in its manifest. On Windows 7, when I invoke GetFileVersionInfo on an absolute path, for example "c:\windows\system32\taskeng.exe", I receive the version information for "C:\Windows\winsxs\x86_microsoft-windows-taskscheduler-engine_31bf3856ad364e35_6.1.7600.16385_none_e582a352202e02c8\taskeng.exe"

So, to clarify, the version c:\windows\system32\taskeng.exe reported by Windows Explorer is 6.1.7600.16699. The version of c:\windows\system32\taskeng.exe reported by GetFileVersionInfo() is 6.1.7600.16385.

How do I force my app to not have its file redirected via WinSxS?

Slalom answered 10/3, 2011 at 18:20 Comment(14)
are you sure you don't want the side by side version? What's the underlying project goal?Signe
Yeah. The goal is to determine if DLLs or EXEs are up to date or not, so I need to be able to specify an exact path, and get the version of that file. Windows seems to think it knows better and redirects me to a different file under the WinSxS directory.Slalom
Surely it's merely redirecting you to the actual file that will load when the user runs c:\windows\system32\taskeng.exe? And isn't that what you want?Signe
I don't think so, because checking the version c:\windows\system32\taskeng.exe via windows explorer shows a different value.Slalom
Well, isn't that the whole point of side-by-side? My guess is that if GetFileVersionInfo didn't do this it would be doing it wrong.Signe
The point of side-by-side is to bind your application to a specific version of a library or executable. I need my app to behave like Windows Explorer and be able to read the version information from an arbitrary filename without being redirected.Slalom
@sec Why? When the user runs it, they'll get the one in WinSxS!Signe
I just verified that is not the case. Double clicking c:\windows\system32\taskeng.exe runs version 6.1.7600.16699. GetFileVersionInfo() returns 6.1.7600.16385.Slalom
Do you have the win7 compatibility guid in your manifest? Do you have a manifest at all?Monatomic
Basically the only thing in the manifest is requestedExecutionLevel level="requireAdministrator". This problem exists on Vista as well, is there a Vista compatibility GUID too?Slalom
@sec I don't see the same behaviour as you.Signe
I think I'll have to parse the version resource out of the file manually.Slalom
is this perhaps Vista 64 and your app is 32its. While the location is strange it looks like you might be falling afoul of the 32bit redirection when 32bit apps try to access system locations on 64bit windows.Stockist
No, I already had to deal with that using sysnative. The machine I'm on right now is Win7 32bit.Slalom
F
3

Are you sure you are looking at the correct fields? GetFileVersionInfo() gives me the same thing as Explorer with one caveat: the FileVersion in the StringFileInfo is 6.1.7600.16385 whereas the FileVersion in the VS_FIXEDFILEINFO is 6.1.7600.16699. Explorer is showing the FileVersion from the VS_FIXEDFILEINFO. I guess Microsoft just didn't update the StringFileInfo for some reason.

Fullbodied answered 11/3, 2011 at 15:39 Comment(1)
You nailed it. We've always just looked at the string version. I guess MS forgot to update the resource file completely when they updated it.Slalom
W
5

Here's a PowerShell script to show the difference. FileVersion is a string that is different than the composition of [FileMajorPart].[FileMinorPart].[FileBuildPart].[FilePrivatePart].

PS C:\> [System.Diagnostics.FileVersionInfo]::GetVersionInfo("c:\windows\system32\taskeng.exe") | Format-List -property *


Comments           :
CompanyName        : Microsoft Corporation
FileBuildPart      : 7601
FileDescription    : Task Scheduler Engine
FileMajorPart      : 6
FileMinorPart      : 1
FileName           : c:\windows\system32\taskeng.exe
FilePrivatePart    : 17514
FileVersion        : 6.1.7600.16385 (win7_rtm.090713-1255)
InternalName       : TaskEng
IsDebug            : False
IsPatched          : False
IsPrivateBuild     : False
IsPreRelease       : False
IsSpecialBuild     : False
Language           : English (United States)
LegalCopyright     : © Microsoft Corporation. All rights reserved.
LegalTrademarks    :
OriginalFilename   : taskeng.exe.mui
PrivateBuild       :
ProductBuildPart   : 7601
ProductMajorPart   : 6
ProductMinorPart   : 1
ProductName        : Microsoft® Windows® Operating System
ProductPrivatePart : 17514
ProductVersion     : 6.1.7600.16385
SpecialBuild       :
Willin answered 24/2, 2015 at 16:15 Comment(0)
F
3

Are you sure you are looking at the correct fields? GetFileVersionInfo() gives me the same thing as Explorer with one caveat: the FileVersion in the StringFileInfo is 6.1.7600.16385 whereas the FileVersion in the VS_FIXEDFILEINFO is 6.1.7600.16699. Explorer is showing the FileVersion from the VS_FIXEDFILEINFO. I guess Microsoft just didn't update the StringFileInfo for some reason.

Fullbodied answered 11/3, 2011 at 15:39 Comment(1)
You nailed it. We've always just looked at the string version. I guess MS forgot to update the resource file completely when they updated it.Slalom

© 2022 - 2024 — McMap. All rights reserved.