[environment]::OSVersion.Version returns a wrong result of the OS

[jeremylandon]

Steps to reproduce

[environment]::OSVersion.Version

Expected behavior

Should be return the OS Version

Actual behavior

• Windows 10 with PowerShell 5 : 10.0.10536.0
• Windows 10 with PowerShell 6 : 6.2.9200.0
• Ubuntu : throw an error

Potential error of the problem

The method used by PowerShell must be GetVersionInfoEX (depreciated since Windows 8.1) instead of GetVersionInfo

Environment data

PS C:\> $PSVersionTable

Name                           Value
----                           -----
CLRVersion
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
PSVersion                      6.0.0-alpha
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
PSEdition                      Core
GitCommitId                    v6.0.0-alpha.9
BuildVersion                   3.0.0.0

[GeeLaw]

Nah the reason is NOT using GetVersionEx. It works fine in Windows 10. You're referring to a right documentation though. The exe of that PowerShell lacks manifestation, as you can see it is reporting Windows 8.1.

GetVersionInfo seems not to be a Win32 API, can you find a documentation on it? As far as I know, Microsoft only recommends using version helper functions (hmmm I'd have to say many programmers aren't logical enough to correctly check version numbers so MS is providing helper functions haha). And for getting the native system information, use GetFileVersionInfo. GetVersionEx returns the compatibility mode version number and if the app is not manifested for Windows 8.1/10, VersionLie shim gets in.

[daxian-dbw]

[environment]::OSVersion.Version is actually calling .NET Core code:

PS C:\> [environment]::OSVersion.GetType().Assembly

GAC    Version        Location
---    -------        --------
       v4.0.30319     C:\Users\dongbow\Downloads\powershell-6.0.0-alpha.9\System.Private.CoreLib.ni.dll

PS C:\>
PS C:\> [environment].Assembly

GAC    Version        Location
---    -------        --------
       v4.0.30319     C:\Users\dongbow\Downloads\powershell-6.0.0-alpha.9\System.Private.CoreLib.ni.dll

System.Environment::OSVersion is not exposed in .NET Core contract, but it's obviously still preserved in the runtime assembly.

.NET Core team will bring back OSVersion and other public surface from System.Private.Corelib in .NET Core 1.1 release, see dotnet-core#6006

[SteveL-MSFT]

we are doing work to expose OS info in psversiontable #1635 , this is already tracked in dotnet repo

[mklement0]

Just a heads-up that, at least as of this writing, while dotnet-core#6006 does intend to bring System.Environment's OSVersion back:

• its implementation is not cross-platform yet,

• and is furthermore currently based on calls to the deprecated-since-Windows-8.1 GetVersion and GetVersionEx Windows API functions, which as has been pointed out, do not report the true OS version.

  • @GeeLaw: The Core powershell.exe does have an (embedded) manifest too, but one without entries targeting specific Windows version, hence it is "stuck" at reporting Windows 8 (6.2), as you state.
    That said, even the Windows PowerShell powershell.exe, with its Windows-version-targeting entries would be lied to in the future, if it used GetVersion(Ex) directly:

  "Once an application is manifested for a given operating system version, GetVersionEx will always return the version that the application is manifested for in future releases." -

  • However, it seems that the .NET Framework (I presume) works around this:

/*

• SystemNative::GetOSVersion - Fcall corresponding to System.Environment.GetVersion
• It calls clr!GetOSVersion to get the real OS version even when running in
• app compat. Calling kernel32!GetVersionEx() directly will be shimmed and will return the
• fake OS version. In order to avoid this the call to getVersionEx is made via mscoree.dll.
• Mscoree.dll resides in system32 dir and is never lied about OS version.
  */

• It sounds like .NET Core, which I presume doesn't use mscoree.dll, cannot take advantage of this, which is why the Core edition reports the fake version.

• It is hard to believe, but the method that the official docs recommend for determining the true Windows version number is:

call the GetFileVersionInfo function on one of the system DLLs, such as Kernel32.dll, then call VerQueryValue to obtain the \StringFileInfo\\ProductVersion sub-block of the file version information."

To put it in PowerShell terms (Windows-only):
(Get-FileVersionInfo $env:SystemRoot\System32\kernel32.dll).ProductVersion