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

runtime/src/libraries/System.Diagnostics.FileVersionInfo/src/System/Diagnostics/FileVersionInfo.Windows.cs

Lines 28 to 34 in fe3d5b5

	// Some dlls might not contain correct codepage information, in which case the lookup will fail. Explorer will take
	// a few shots in dark. We'll simulate similar behavior by falling back to the following lang-codepages.
	uint lcp = GetLanguageAndCodePage(memPtr);
	_ = GetVersionInfoForCodePage(memPtr, lcp.ToString("X8")) ||
	(lcp != 0x040904B0 && GetVersionInfoForCodePage(memPtr, "040904B0")) || // US English + CP_UNICODE
	(lcp != 0x040904E4 && GetVersionInfoForCodePage(memPtr, "040904E4")) || // US English + CP_USASCII
	(lcp != 0x04090000 && GetVersionInfoForCodePage(memPtr, "04090000")); // US English + unknown codepage

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.

[dotnet-policy-service]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

[tommcdon]

@ericstj

[ericstj]

I think this might be Windows Defender or similar blocking that EXE. Looks like that file is detected as EUS:Win32/CustomCertEnterpriseBlock!cl.