It is possible for this MDA to be falsely activated when all of the following conditions are met:
* An application creates COM components from STA threads either directly or indirectly through libraries.
* The application was stopped in the debugger and the user either continued the application or performed a step operation.
*Unmanaged debugging is not enabled.
The reasoning is that:
1) When you’re stopped in the debugger while managed-only debugging, unmanaged threads are still running. This means that any unmanaged threads that are waiting on some timeout from managed code will continue to run. The unmanaged thread will see the timeout fire, but it won’t realize that the managed thread is actually stopped by the debugger. Thus the managed thread looks it’s deadlocked. This is not an issue when unmanaged debugging because then the timeout thread is also frozen when stopped in the debugger, and so the timeout won’t fire.
2) The finalizer for an STA COM objects needs to run code on the STA thread. So there’s some cross-thread stuff between the finalizer thread and the STA thread.
So the STA thread may be blocked by the debugger (since the whole managed process is frozen at a breakpoint), while the timeout check (on an unmanaged thread) is still ticking.
This is a race because it needs the finalization and debugger event to happen at just the right windows.
We assessed that this scenario as a rare situation. I’d expect you to see this only on very rare occasions (due to prerequisite timing issues).
If you are hitting this bogusly, one workaround is to disable this specific MDA.