Unable to get `FileVersionInfo` data from exe

[codecat]

Description

When looking at the System.Diagnostics.FileVersionInfo output for the TeamViewer Quicksupport executable, I get all empty strings for fields like ProductName and LegalCopyright, while they do in fact exist, according to Windows Explorer:

Reproduction Steps

This code will get a path to TeamViewerQS_x64.exe (see description above for download link), and print to console some of the properties from the file version info.

// Get path to downloads folder and TeamViewerQS_x64.exe
var userPath = Environment.GetFolderPath(Environment.SpecialFolder.UserProfile);
var downloadsPath = Path.Combine(userPath, "Downloads");
var exePath = Path.Combine(downloadsPath, "TeamViewerQS_x64.exe");

// Get file version info and print to console
var fvi = FileVersionInfo.GetVersionInfo(exePath);
Console.WriteLine($"version major = {fvi.ProductMajorPart}");
Console.WriteLine($"version minor = {fvi.ProductMinorPart}");
Console.WriteLine($"product name = \"{fvi.ProductName}\"");
Console.WriteLine($"copyright = \"{fvi.LegalCopyright}\"");

Expected behavior

The expected output of the example code above should be (according to Windows Explorer):

version major = 15
version minor = 60
product name = "TeamViewer QS"
copyright = "TeamViewer"

Actual behavior

The actual output of the example code is:

version major = 15
version minor = 60
product name = ""
copyright = ""

Interesting to note is the version integers are correct.

Regression?

No response

Known Workarounds

No response

Configuration

I tried this on Windows 11, both .Net 8.0.400 and .Net 9.0.100. It also happens on Windows 10.

Other information

Considering the version integers are correct, perhaps this is some kind of string encoding issue? It appears that the TeamViewer QuickSupport exe is a compiled NSIS program, which may be relevant in helping to narrow this down.

[KalleOlaviNiemitalo]

Judging from https://github.com/dotnet/runtime/blob/fe3d5b5f7039e9f38f022dac77aeb6f01025b19d/src/libraries/System.Diagnostics.FileVersionInfo/src/System/Diagnostics/FileVersionInfo.Windows.cs#L28-L34 this could happen if the strings in the version resource are tagged with a language/codepage combination that is neither listed in the \VarFileInfo\Translation value nor any of the hardcoded guesses.

[KalleOlaviNiemitalo]

The version resource in TeamViewerQS_x64.exe has 0x04b00409 in its \VarFileInfo\Translation value, and the strings are under \StringFileInfo\040904b0, i.e. both have language 0x0409 (U.S. English) and codepage 0x04b0 (Unicode). My previous hypothesis about the cause is then not correct.

The StringFileInfo lookups in FileVersionInfo.GetVersionInfoForCodePage look like they have excess backslashes. That however shouldn't be the cause either, because .NET Framework has equivalent code.

If you had been using FileVersionInfo on an operating system other than Windows, then it would not have been able to parse the Win32 version resource at all and ProductMajorPart would also have been zero.