StringComparer.InvariantCulture.GetHashCode throws in Windows 7 compat mode

[vitek-karas]

Repro

dotnet new console
Use this code in Main

            string value = @"Some";
            IEqualityComparer<string> comparer = StringComparer.InvariantCulture;
            Console.WriteLine($"{comparer.GetHashCode(value)}");

Build with .NET Core 3.0.
Go to the output folder and set compatibility mode for the .exe to Windows 7.
Run the exe.

Output

Unhandled exception. System.ArgumentException: External component has thrown an exception.
   at System.Globalization.CompareInfo.GetHashCodeOfStringCore(ReadOnlySpan`1 source, CompareOptions options)
   at System.Globalization.CompareInfo.GetHashCodeOfString(String source, CompareOptions options)
   at System.CultureAwareComparer.GetHashCode(String obj)
   at ConsoleApp3.Program.Main(String[] args)

This seems to happen for any string other than empty string. The program works fine when executed without the compatibility mode set.

I haven't tried to run this on actual Windows 7 machine.

[vitek-karas]

Originally reported in https://github.com/dotnet/core-setup/issues/7872.

[jkotas]

This is duplicate of https://github.com/dotnet/coreclr/issues/15021. The Windows compatibility shims do not correctly implement LCMAP_SORTHANDLE flag that .NET Core depends on.

[vitek-karas]

This is basically extending the scenarios where it can happen. In .NET Core 3.0 all apps get an .exe by default, so it's not just setting compatibility mode on the dotnet.exe which I agree is something we should not support. This is about each particular app.

Also with .NET Core 3.0 this is then exaggerated by the much wider support for native hosting, which means there will be more native apps which host .NET Core for pieces of functionality. If the app itself wants to use compatibility modes, it will break. Note that this also applies to .NET Core COM servers - if a COM object which is implemented in .NET Core is ever activated by an app running in the compatibility mode, it will fail to activate.
/cc @AaronRobinsonMSFT

[Sewer56]

Also with .NET Core 3.0 this is then exaggerated by the much wider support for native hosting, which means there will be more native apps which host .NET Core for pieces of functionality.

This is actually the original scenario that caused https://github.com/dotnet/core-setup/issues/7872 to be reported.

I specifically noticed this issue when trying to execute .NET code in a foreign native process through the use of DLL Injection of a native bootstrapper which uses the nethost hosting API.

The foreign native process has a small issue running on modern OS in a very specific place, which is why I had compatibility mode enabled in the first place.

Diagram from Reloaded-II Documentation provided for clarity.

---

Note: This issue isn't limited to Windows 7 compatibility mode. It will happen with compat mode with any OS starting with Vista.

[tarekgh]

CC @ericstj

This will be risky to try to fix for 3.0. This is not a new issue and existed in previous releases too. We never supported running .net core apps under the Windows comparability modes. trying to fix that will not only just fixing this case but also we'll need to do more work to ensure we run fine under the comparability modes.

Also, the underlying issue is really a bug in Windows and not in our products. I contacted Windows team before and they decided to not fix it. I'll try to bring this issue back to them to consider. but for now, I am going to move this issue to 5.0 release and apps need to work around this by not applying the compatibility mode.

[tarekgh]

CC @danmosemsft

[danmoseley]

Marking 3.0.x for servicing consideration. Please leave this active after merging into master.

[tarekgh]

@danmosemsft should we keep this issue active as you marked it as 3.0.x?

[danmoseley]

Yes please let's use issues + 3.0.x milestone for now while we figure out process.

[tarekgh]

sorry I didn't see your previous comment.

[tarekgh]

@danmosemsft I think this issue is not meeting 3.0.x bar but I believe having it for 3.1 is good. what you think? should I move it to 3.1?

CC @ericstj

[danmoseley]

@tarekgh Do we run perfectly (as far as is known) in compat mode, after this fix, or are there more issues?

If this fix enables the whole scenario, and the risk is acceptable, I support porting into 3.1 - please go ahead and prep a PR.

[danmoseley]

I ask because I see you said

also we'll need to do more work to ensure we run fine under the comparability modes.

In the PR could you put the usual template, even if it's just for us?