[main] Update dependencies from dotnet/runtime

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/runtime

• Subscription: d9f5b309-084f-43b5-02de-08d8b80548e4
• Build: 20241217.3
• Date Produced: December 17, 2024 6:40:45 PM UTC
• Commit: 040cbe276907174316e2cc07b35814b3069874a6
• Branch: refs/heads/main

• Updates:
  • Microsoft.Internal.Runtime.WindowsDesktop.Transport: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • Microsoft.NET.Sdk.IL: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • Microsoft.NETCore.App.Ref: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • Microsoft.NETCore.App.Runtime.win-x64: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • Microsoft.NETCore.ILAsm: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • Microsoft.NETCore.ILDAsm: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • Microsoft.NETCore.Platforms: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • Microsoft.Win32.Registry.AccessControl: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • Microsoft.Win32.SystemEvents: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • runtime.win-x64.Microsoft.NETCore.ILAsm: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • runtime.win-x86.Microsoft.NETCore.ILAsm: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.CodeDom: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.ComponentModel.Composition: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.ComponentModel.Composition.Registration: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Configuration.ConfigurationManager: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Data.Odbc: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Data.OleDb: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Diagnostics.EventLog: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Diagnostics.PerformanceCounter: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.DirectoryServices: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.DirectoryServices.AccountManagement: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.DirectoryServices.Protocols: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Formats.Nrbf: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.IO.Hashing: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.IO.Packaging: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.IO.Ports: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Management: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Reflection.Context: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Reflection.MetadataLoadContext: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Resources.Extensions: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Runtime.Caching: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Runtime.Serialization.Formatters: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Security.Cryptography.Pkcs: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Security.Cryptography.ProtectedData: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Security.Cryptography.Xml: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Security.Permissions: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.ServiceModel.Syndication: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.ServiceProcess.ServiceController: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Speech: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Text.Encoding.CodePages: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Text.Encodings.Web: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Text.Json: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Threading.AccessControl: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • System.Windows.Extensions: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3
  • VS.Redist.Common.NetCore.SharedFramework.x64.10.0: from 10.0.0-alpha.1.24611.1 to 10.0.0-alpha.1.24617.3

Microsoft Reviewers: Open in CodeFlow

[dotnet-policy-service]

Go, you big red fire engine!

[lonitra]

We are observing access violations / ExecutionEngineExceptions in our tests with this update. I tried to investigate further by debugging our ScrollBarTests suite, which is where I first saw tests aborting. Unfortunately, it is inconsistent on where it is seen surfacing.. I have seen it surface when xunit tries to invoke test methods, doing simple null checks, when trying to create new objects. Whenever there is an access violation typically message says something like:

Exception thrown at 0x00007FF825E2C0D6 (coreclr.dll) in testhost.exe: 0xC0000005: Access violation reading location 0x0000000000000020.

These are the commits included in the first dependency update dotnet/runtime@aa9cd3b...c646425 but it is not obvious to me what may have caused this behavior. @ericstj are you aware of any changes that could have caused this or who can help investigate?

[ericstj]

@lonitra any chance you have a dump?

Of those commits identified, the one that seems the most likely is dotnet/runtime@69d8076 cc @VSadov @jkotas.

[jkotas]

Of those commits identified, the one that seems the most likely is dotnet/runtime@69d8076

I have confirmed that it is caused by this change. I am reverting it in dotnet/runtime#110801

The crash repros fairly reliably for me locally. It is not obvious what the problem is.

[VSadov]

My guess - either winforms scenarios use FLS in a conflicting manner, or something that we do on thread detach in CoreCLR is somehow dependent on holding the loader lock (that would be a bit inconvenient).

[jkotas]

@VSadov The symptoms of this crash are very similar to dotnet/runtime#110442 . One possible explanation is that there is a subtle race condition where we forget to unregister the dying thread and the FLS change just made it more likely to be hit.

[jkotas]

I was able to catch the problem under debugger. The problem is that COM apartment shutdown ends up calling into managed code and re-initializes the Thread at the callstack below. The re-initialized Thread won't be unregistered and we will crash later when trying to access it:

combase!PeekTillDone+0x47
combase!OXIDEntry::WaitForApartmentShutdown+0x2b
combase!OXIDEntry::StopServer+0x52
combase!CComApartment::StopServer+0x31
combase!StopThread+0x3d
combase!ApartmentUninitialize+0x91
combase!wCoUninitialize+0x2cf
combase!CoUninitialize+0x197
combase!DoThreadSpecificCleanup+0x5d
combase!FlsThreadCleanupCallback+0x29
ntdll!RtlpFlsCallbackPerform+0xa
ntdll!RtlpFlsDataCleanup+0xff
ntdll!RtlProcessFlsData+0x15
ntdll!LdrShutdownThread+0x49
ntdll!RtlExitUserThread+0x46

[VSadov]

By the looks of FlsThreadCleanupCallback it seems like combase uses similar trick with FLS as we do.

Are you seeing a scenario when we are called first (and detach) and then their callback gets called and they end up calling managed code? (it is not clear from the stack what calls managed code)

[jkotas]

Are you seeing a scenario when we are called first (and detach) and then their callback gets called and they end up calling managed code?

Yes.

[VSadov]

Our assumption that a thread cannot call into managed code after calling our FLS callback is not correct then.
~destructors of c++ thread-local objects could, in theory, have the same issue - anyone can set up one and do whatever in in it.

[jkotas]

Our assumption that a thread cannot call into managed code after calling our FLS callback

Dtto for regular TLS callbacks - I guess that it is the problem in dotnet/runtime#110442. We wish that it can declared as unsupported scenario, but we have not done a good job failing deterministically in this situation, so there is likely quite a bit out code that depends on it "working".

[VSadov]

At high level dotnet/runtime#110442 seems similar - it also seems to be an issue with thread destruction notification. Although it is a different platform with different notification mechanism and from the discussion it appears the notification just did not arrive (or was not acted upon) before TLS was destroyed and then GC happened and crashed. Here the notification did arrive, but the thread found a way to do a reverse pinvoke after that.

Unix issue feels simpler - we should be able to be notified and detach before TLS is destroyed. Something did not work as expected.

The issue with thread termination callback itself entering managed code seems a bit harder to deal with. I do not have any good ideas at the moment.

FLS callbacks are not very commonly used and the documentation says that they should be simple, basically just memory deallocation. Perhaps there is a way to prevent entering managed code from that?

[jkotas]

Here the notification did arrive, but the thread found a way to do a reverse pinvoke after that.

My guess is that the Unix issue is the same: The notification did arrive, but the thread found a way to do a reverse pinvoke after that via thread static in some native library.

FLS callbacks are not very commonly used and the documentation says that they should be simple, basically just memory deallocation. Perhaps there is a way to prevent entering managed code from that?

We can fail-fast if the thread tries to re-enter managed code after the thread destruction notification (e.g. we can have a bool thread static that is set in the thread destruction notification). But it would be a severe breaking change in combination with the FLS change on Windows.

[jkotas]

FLS callbacks are not very commonly used and the documentation says that they should be simple, basically just memory deallocation.

The COM FLS fallback is anything but simple. It pumps Windows messages... .

it would be a severe breaking change in combination with the FLS change on Windows.

Brainstorming about possible solutions:

• Ensure that our FLS slot is allocated after COM FLS slot, so that our callback comes after the COM callback. It would not be pretty, but I am sure that it would fix the winforms crash.
  (or)
• Do a full attach/detach on attempt to enter managed code after thread destruction notification. It would make JIT_ReversePInvokeExit a bit slower (we would have to check a flag and to do full detach if the flag is set)

[VSadov]

it would be a severe breaking change in combination with the FLS change on Windows.

On that I agree. Poisoning a thread after detaching will get us in trouble in exactly same scenarios.

Do a full attach/detach on attempt to enter managed code after thread destruction notification.

In theory it could work. Everything is synchronous as it is local to the thread, so no races to be concerned about.
Possible problems could be:

• I am not sure if registering an FLS slot from a detach callback is something that API expects. (same applies to any other kind of thread termination notifications - is it ok to reregister in a callback?).
• might be some subtle issues with managed thread identity - is it the "same" thread after reattachment, is the managed ID the same, are thread statics resurrected somehow, does the thread still own the same locks (although terminating thread while owning locks is mostly UB anyways...).
  It feels like it might need to be a new managed thread, while native part would still remember old things.

It would make JIT_ReversePInvokeExit a bit slower

If the idea is to not reregister with OS at all and just detach on every PInvokeExit, then it eliminates the concern #1 (can we reregister at all), while the concern #2 (thread's identity) may get worse.

Ensure that our FLS slot is allocated after COM FLS slot, so that our callback comes after the COM callback.

If registering FLS slot earlier guarantees that callback is called later (i.e. LIFO), this might be sufficient.

We'd need just to be sure that the FLS is allocated before everything else when a thread is attached.

(another assumption is that anything that allocates FLS slots before calling managed code will not call managed code in its callback - not the 100% robust, but plausible assumption, I think)

[jkotas]

If registering FLS slot earlier guarantees that callback is called later (i.e. LIFO), this might be sufficient.

It is the other way around: Callbacks registered earlier get called earlier. (As long as there is no FLS slot reuse.) We registered our FLS callback before the COM one, so it got called before the COM one.

[jkotas]

It feels like it might need to be a new managed thread, while native part would still remember old things.

I think it can be the same managed/native combo. We can use the thread static callback that gets executed under loader lock to tell signal that the managed/native combo is not needed anymore (without entering the coop mode).

[VSadov]

Also wonder why we did not see this before.
I guess it is just because FLS callbacks are called before DllMain (or whatever calls threadlocal destructors).

[VSadov]

What exactly managed code do they need to run on apartment shutdown? Can we move that to native or fake it and not run at all (conditionally - if thread is detached) ?

[jkotas]

What exactly managed code do they need to run on apartment shutdown?

The managed code that I have seen running under WaitForApartmentShutdown was a managed Windows Proc registered by WinForms. It run because of the thread was pumping windows messages and the message happened to be for the window owned by WinForms.

[lonitra]

Thank you for investigating this! I'm closing this PR as #12655 has superseded this and contains the fix.

[VSadov]

I was able to catch the problem under debugger.

@jkotas what was your way to repro this? Did you run a particular test or a directed repro sample?

[jkotas]

@jkotas what was your way to repro this? Did you run a particular test or a directed repro sample?

Build and run all winforms tests against the changes in this PR. The crash occurs when running the WinForms unit tests (System.Windows.Forms.Tests). I have not isolated the specific test that triggers the crash. I have used coreclr.dll with custom instrumentation to figure out what's going on.