How to find what .NET method led caused the worker to stop

Question

My code has deadlocked. Here is the stack trace for the main thread:

[Managed to Native Transition]

WindowsBase.dll!MS.Win32.UnsafeNativeMethods.GetMessageW(ref System.Windows.Interop.MSG msg, System.Runtime.InteropServices.HandleRef hWnd, int uMsgFilterMin, int uMsgFilterMax) + 0x14 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.GetMessage(ref System.Windows.Interop.MSG msg, System.IntPtr hwnd, int minMessage, int maxMessage) + 0x80 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame frame) + 0x75 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame frame) + 0x49 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.Run() + 0x4b bytes
PresentationFramework.dll!System.Windows.Application.RunDispatcher(object ignore) + 0x17 bytes
PresentationFramework.dll!System.Windows.Application.RunInternal(System.Windows.Window window) + 0x6f bytes
PresentationFramework.dll!System.Windows.Application.Run(System.Windows.Window window) + 0x26 bytes
PresentationFramework.dll!System.Windows.Application.Run() + 0x1b bytes MainDashboard.exe!MainDashboard.App.Main() + 0x59 bytes C# [Native to Managed Transition] [Managed to Native Transition]
mscorlib.dll!System.AppDomain.ExecuteAssembly(string assemblyFile, System.Security.Policy.Evidence assemblySecurity, string[] args) + 0x6b bytes
Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() + 0x27 bytes mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x6f bytes
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0xa7 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x16 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x41 bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes [Native to Managed Transition]

How do I know what part of my code is responsible. The application entry point is:

MainDashboard.exe!MainDashboard.App.Main() + 0x59 bytes C#

and that is the only line in this stacktrace that is from my code.

Trying to view the call stack for two other frames displays the following:

The current thread is not currently running code all the call stack is could not be obtained.

Here is the call stack of another worker thread:

[Managed to Native Transition]

System.dll!Microsoft.Win32.SystemEvents.WindowThreadProc() + 0xaf bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x6f bytes
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0xa7 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x16 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x41 bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes [Native to Managed Transition]

And here is the call stack of the last thread:

[Managed to Native Transition]

Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.WaitForThreadExit() + 0x93 bytes Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunParkingWindowThread() + 0x253 bytes mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x6f bytes
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0xa7 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x16 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x41 bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes [Native to Managed Transition]

The app is hanged. there is a total of 49,000 records it needs to process. it stopped at 3,029. The app is not using any resources at this point. Task Manager is showing it using 0% CPU. The UI is responsive, but it is designed to be always responsive.

Also, this is not deterministic. I mean, if I restart the app, it will hang at a different point in the code, so there is not one record that has an issue that brings the whole thing down.

Answer 1

Since you now noticed 'first chance exceptions' in your 'Output' and they seem to kill your threads, there's one more thing other than just try/catch/log.

Use the debugging features of VS/CLR even further. Go to DEBUG menu, then EXCEPTIONS then find one (or all, but I prefer to do it one-by-one) of the exceptions you identified as thrown-and-killing-your-threads, i.e. InvalidOperationException and check the tick "thrown" or "unhandled" (depending on what you want and what version of VS you have).

Now, assuming you ticked "thrown", the IDE will automatically break/halt the program whenever it tried to throw exactly this one type of exception.

..and not only it will halt the program, it will also jump there as if you placed a breakpoint. You'll instantly get all the stacktraces, variables, code, etc you'd like to inspect.

But, on the other hand, if you app is spamming with this kind of exception with rate of thousands per second, just because someone was lazy and if/else'd some bad-arguments case and try/caught the exception instead, then trying to rely on this exception being "thrown" will .. well.. fail. In such case, you might want to try with "unhandled" tick instead (if you see it in the IDE at all), but of course it has its own limitations, too. Nevertheless, they are really precious tools if only you can attach the IDE to the failing process. Insta-break on the unknown line with problems!