WinFormAnimation's pattern of queuing work to the thread pool can block large number of threads

[davkean]

Hey, I'm from the Visual Studio performance team. Our out of memory (OOM) telemetry has detected a pattern WinFormAnimation.dll where it burns large number of threads when the UI thread is busy. In one OOM dump I looked at, the following callstack (starting [here])(

WinFormAnimation/WinFormAnimation/SafeInvoker.cs

Line 112 in 326ec78

_invokeMethod.Invoke(

) was blocking 1,825 thread pool threads, consuming about 2 GB of address space. This would have caused Visual Studio responsiveness issues and the ultimately the cause of the Visual Studio crash when it run out of memory.

I'm not sure exactly what this code is doing, but at times where the UI thread is blocked (such as solution open, large refactoring) - these calls will continue to back up until the UI responds.

 	ntdll.dll!_ZwWaitForMultipleObjects@20() Line 825	Unknown
 	KERNELBASE.dll!WaitForMultipleObjectsEx(unsigned long nCount, void * const * lpHandles, int bWaitAll, unsigned long dwMilliseconds, int bAlertable) Line 1551	C
 	mscorlib.ni.dll!7381d952()	Unknown
 	[Managed to Native Transition]	
 	mscorlib.dll!System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle waitableSafeHandle, long millisecondsTimeout, bool hasThreadAffinity, bool exitContext)	Unknown
 	mscorlib.dll!System.Threading.WaitHandle.WaitOne(int millisecondsTimeout, bool exitContext)	Unknown
 	System.Windows.Forms.dll!System.Windows.Forms.Control.WaitForWaitHandle(System.Threading.WaitHandle waitHandle)	Unknown
 	System.Windows.Forms.dll!System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control caller, System.Delegate method, object[] args, bool synchronous)	Unknown
 	System.Windows.Forms.dll!System.Windows.Forms.Control.Invoke(System.Delegate method, object[] args)	Unknown
 	System.Windows.Forms.dll!System.Windows.Forms.Control.Invoke(System.Delegate method)	Unknown
 	[Native to Managed Transition]	
 	mscorlib.ni.dll![Frames below may be incorrect and/or missing, native debugger attempting to walk managed call stack]	Unknown
 	mscorlib.ni.dll!73858589()	Unknown
 	[Managed to Native Transition]	
>	WinFormAnimation.dll!WinFormAnimation.SafeInvoker.Invoke.AnonymousMethod__0(object state)	Unknown
 	mscorlib.dll!System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(object state)	Unknown
 	mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)	Unknown
 	mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)	Unknown
 	mscorlib.dll!System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()	Unknown
 	mscorlib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch()	Unknown
 	mscorlib.dll!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()	Unknown

[falahati]

Thanks for reporting this David, I will take a look.
I suppose this is a problem with design mode, right? If it is, do we have the name of the actual component using this library?

[davkean]

Yes design-mode. I do not have a name of the component using the library, but there were a number crashes caused by this.

[mattbriggsuk]

Hi @falahati any update or thoughts on this? This issue seems manifests itself within CircularProgressBar, currently trying to understand this. When locking/unlocking the windows desktop the whole Winforms application hangs. Seems like an issue with SafeInvoker not being very safe!