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?

secdevmark
  • 43
  • 1
  • 3
  • are you sure you don't want the side by side version? What's the underlying project goal? – David Heffernan Mar 10 '11 at 18:42
  • 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. – secdevmark Mar 10 '11 at 19:26
  • 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? – David Heffernan Mar 10 '11 at 19:27
  • I don't think so, because checking the version c:\windows\system32\taskeng.exe via windows explorer shows a different value. – secdevmark Mar 10 '11 at 19:30
  • 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. – David Heffernan Mar 10 '11 at 19:40
  • 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. – secdevmark Mar 10 '11 at 19:49
  • @sec Why? When the user runs it, they'll get the one in WinSxS! – David Heffernan Mar 10 '11 at 19:51
  • 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. – secdevmark Mar 10 '11 at 19:57
  • Do you have the win7 compatibility guid in your manifest? Do you have a manifest at all? – Anders Mar 10 '11 at 20:02
  • 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? – secdevmark Mar 10 '11 at 20:11
  • @sec I don't see the same behaviour as you. – David Heffernan Mar 10 '11 at 20:15
  • I think I'll have to parse the version resource out of the file manually. – secdevmark Mar 10 '11 at 20:34
  • 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. – Chris Becke Mar 10 '11 at 20:39
  • No, I already had to deal with that using sysnative. The machine I'm on right now is Win7 32bit. – secdevmark Mar 10 '11 at 20:46

2 Answers2

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       :
bdeem
  • 899
  • 9
  • 14
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.

Luke
  • 11,211
  • 2
  • 27
  • 38
  • 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. – secdevmark Mar 11 '11 at 17:25