Description
Files closed itself with an access violation in coreclr.dll, on the .NET finalizer thread, while it was releasing a COM object.
Windows Error Reporting caught a full dump of it, so everything below comes from that dump and the Application event log.
Event 1026, .NET Runtime:
Application: Files.exe
CoreCLR Version: 10.0.826.23019
.NET Version: 10.0.8
Description: The process was terminated due to an unhandled exception.
Stack:
at WinRT.IObjectReference.Finalize()
at System.GC.RunFinalizers()
Event 1000, Application Error:
Faulting module name: coreclr.dll, version: 10.0.826.23019
Exception code: 0xc0000005
Fault offset: 0x0000000000356d4f
Faulting application path: C:\Program Files\WindowsApps\Files_4.2.9.0_x64__1y0xx7n9077q4\Files.exe
From the dump, read with dotnet-dump:
- The thread in the exception record is the finalizer.
clrthreads lists it as (Finalizer) with System.ExecutionEngineException.
- The object being finalized is a
WinRT.ObjectReference<IUnknownVftbl>. Its _thisPtr points at an object whose vtable sits inside combase.dll, so a COM proxy or something else combase owns, and not a class from Files.
- The
ComWrappers+NativeObjectWrapper beside it on the stack already had _comWrappers and _externalComObject zeroed.
- Files had been up about 3.5 hours. It was carrying 280 OS threads and 158 managed threads, 80 of them dead, and a lot of the live ones are STA, including
Files.App.Utils.Shell.ThreadWithMessageQueue threads. A live dump from an earlier session had 68 threads, for comparison.
My guess, and it is only a guess: a COM proxy that never got disposed was collected after the apartment that owned it had gone, and the release from the finalizer hit memory that was already freed.
I don't have symbols for coreclr.dll, so I can't name the function at +0x356d4f, and the thread count might have nothing to do with it.
I still have the dump and can run anything against it you'd like to see.
It's a full-memory dump, so I'd prefer to keep the file itself off the internet.
Steps To Reproduce
No reliable repro.
It's one crash in about eight weeks of daily use.
- Open Files and use it normally for a few hours.
- Files closes with this crash.
Files Version
4.2.9.0
Windows Version
10.0.19045.7725
Log File
debug.log is attached. It has rolled over since the crash, so it won't cover the 28 Aug session.
Description
Files closed itself with an access violation in
coreclr.dll, on the .NET finalizer thread, while it was releasing a COM object.Windows Error Reporting caught a full dump of it, so everything below comes from that dump and the Application event log.
Event 1026, .NET Runtime:
Event 1000, Application Error:
From the dump, read with
dotnet-dump:clrthreadslists it as(Finalizer)withSystem.ExecutionEngineException.WinRT.ObjectReference<IUnknownVftbl>. Its_thisPtrpoints at an object whose vtable sits insidecombase.dll, so a COM proxy or something else combase owns, and not a class from Files.ComWrappers+NativeObjectWrapperbeside it on the stack already had_comWrappersand_externalComObjectzeroed.Files.App.Utils.Shell.ThreadWithMessageQueuethreads. A live dump from an earlier session had 68 threads, for comparison.My guess, and it is only a guess: a COM proxy that never got disposed was collected after the apartment that owned it had gone, and the release from the finalizer hit memory that was already freed.
I don't have symbols for
coreclr.dll, so I can't name the function at+0x356d4f, and the thread count might have nothing to do with it.I still have the dump and can run anything against it you'd like to see.
It's a full-memory dump, so I'd prefer to keep the file itself off the internet.
Steps To Reproduce
No reliable repro.
It's one crash in about eight weeks of daily use.
Files Version
4.2.9.0
Windows Version
10.0.19045.7725
Log File
debug.logis attached. It has rolled over since the crash, so it won't cover the 28 Aug session.