- \n
- Monitor the
ThreadPool<\/code> for when it’s taking longer than a particular time to complete a thread.<\/li>\n- Dump the memory to a Memory Dump file that we can open in Visual Studio.<\/li>\n<\/ol>\n
Monitoring the
ThreadPool<\/code><\/h3>\nTo monitor the
ThreadPool<\/code> we’re going to create a newThread<\/code> that we periodically put into theThreadPool<\/code> and observe how long it takes to complete. If it takes longer than a timeout that we deem ideal (we’re going to use three seconds for this sample), we’ll dump the state of theThreadPool<\/code> for diagnostics.<\/p>\nHere’s our basic monitor code:<\/p>\n
var interval = 3_000;\nvar thread = new Thread(() =>\n{\n while (true)\n {\n Thread.Sleep(interval);\n\n Stopwatch stopwatch = Stopwatch.StartNew();\n\n Task.Run(() =>\n {\n stopwatch.Stop();\n }).Wait();\n\n if (stopwatch.ElapsedMilliseconds > interval)\n {\n \/\/ Took over the interval to complete\n Console.WriteLine($\"Task took too long: {stopwatch.ElapsedMilliseconds} ms\");\n\n string path = Path.Combine(AppContext.BaseDirectory, $\"fulldump-{Environment.ProcessId}-{DateTime.Now:yyyyMMdd-HHmmss}.dmp\");\n\n MiniDumper.WriteCurrentProcess(path);\n }\n }\n})\n{\n Name = \"ThreadPool Watcher\",\n IsBackground = true\n};\nthread.Start();\n<\/code><\/pre>\nAs I mentioned, we have a companion post<\/a> that will go into more details on this code, but what is doing is creating a new
Thread<\/code> that, every three seconds, creates a newStopwatch<\/code>, then puts aTask<\/code> onto theThreadPool<\/code> that will stop the stopwatch. Once thatTask<\/code> completes, we check how long it took, and if it took longer than our threshold, we’ll call some Windows APIs to create our dump.<\/p>\nCreating a Crash<\/h3>\n
For this demo, we’re going to exhaust the
ThreadPool<\/code> by spinning up a lot of async tasks that are going to take a long time to complete.<\/p>\nParallel.For(0, 100, (i) => {\n Console.WriteLine(\"Running task {0}\", i);\n Thread.Sleep(10_000);\n});\n<\/code><\/pre>\nWhen our application runs, it’s going to start spinning up background threads, they’ll “do work” (ie, sleep for ten seconds), but since they haven’t finished in a timely fashion more tasks will be added, until we end up with our application hanging because the
ThreadPool<\/code> is overloaded. Thankfully, our memory dump will be captured for us to debug.<\/p>\nOpening a Memory Dump<\/h2>\n
Our application has created a
.dmp<\/code> file that is the memory dump, which we can open in Visual Studio.<\/p>\n![\"Memory](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2026\/09\/memory-dump-overview.webp\")
<\/a><\/p>\nThere’s a lot of things we can do now that we’ve opened the memory dump, but because we’re trying to get to the bottom of why our application crashed, we’re going to debug this memory dump using the Debug with Mixed<\/strong>, which will launch a debugging session which can debug both managed (C#) and native code.<\/p>\n
![\"Application](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2026\/09\/application-paused.webp\")
<\/a><\/p>\nThis is a very similar experience to if we had put a breakpoint in place and run the application from Visual Studio with the debugger attached. We can see the Call Stack<\/strong>, we have our Autos<\/strong> showing the value of local variables (
i = 2<\/code>), we can navigate around the decompiled file, but what it’s not showing us is why<\/em> theThreadPool<\/code> was having problems at this point in time. For that, we’re going to use another view in the debugger.<\/p>\nViewing Parallel Stacks<\/h2>\n
From the menu Debug<\/strong> -> Windows<\/strong> we’re going to select Parallel Stacks<\/strong> (CTRL + SHIFT + D, S) and this will load up a new window that gives us an overview of all the threads that are running in parallel of within our application.<\/p>\n
![\"Parallel](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2026\/09\/parallel-stacks-view.webp\")
<\/a><\/p>\nFrom here we can see three threads, there’s Main Thread<\/strong>, which is the application running, there’s ThreadPool Watcher<\/strong>, which is the thread we defined earlier, but then there’s a box in the middle that shows 27 Threads<\/em> at the top – and this is where our problem can be spotted. There are 27 threads all blocked at the same place (which happens to be our
Thread.Sleep(10_000)<\/code>), which is well above the number of threads I should be running on my 16-core CPU. If we were to hover over the method shown for that collection of threads, we’ll see where each of them is paused at.<\/p>\n![\"Viewing](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2026\/09\/viewing-thread-list.webp\")
<\/a><\/p>\nFrom here, we can click into any of the threads, view their unique state at that point of time in the application, and isolate where the problem is coming from.<\/p>\n
Analyzing Parallel Stacks with Copilot<\/h2>\n
Understanding the root cause of a problem across an application that is using a lot of threads can be challenging, and while the memory dump contains a lot of information, it can be difficult to try and find that root cause. To help sift through all the information, we can level the GitHub Copilot integration with the Parallel Stacks window. On the Parallel Stacks window there is a Copilot icon, and that will start a new chat session with the context being the current view and Copilot having access to the memory dump. Copilot can then analyze the threads, their state, and their stacks to help come up with a plan for resolving the problem.<\/p>\n
- Dump the memory to a Memory Dump file that we can open in Visual Studio.<\/li>\n<\/ol>\n
![\"copilot](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2026\/09\/copilot-analysis-parallel-stacks.webp\")
<\/a><\/p>\n