Debug multithreaded applications
Multithreaded applications are always harder to debug as you have to track multiple threads at a time. Moreover, multithreaded applications introduce new types of bugs and performance issues like uneven workload distribution, lock contention, serialized execution, and other*.
The illusion of a sequential flow you get from stepping in a debug session does not help while debugging a multithreaded app and can be misleading. When investigating issues that can be concurrency bugs, you should rely more on breakpoints rather than on sequential stepping. For example, conditional breakpoints can help you a lot if you want to focus on just one thread: just use some unique property of your thread (for example thread ID) to trigger the breakpoint; data breakpoints will break the execution when a marked property of a specific object changes by any thread.
JetBrains Rider provides the following functionality to simplify the debugging of multithreaded applications:
In the Debugger tab of the Debug window, the left pane shows all threads of the application and the next pane lists all stack frames of the selected thread:
The Parallel Stacks tab of the Debug window simplifies threads analysis by showing threads and their stack frames as a diagram.
The ID of the current thread is shown in line with the current execution point in the editor.
View all active threads in your program
Click the Parallel Stacks tab in the Debug window.
Click the thread ID in the editor:
Here is an example of how Parallel Stacks look like during the debugging of a simple application that starts a number of threads:
Some notes to the image:
The call path of the current thread is highlighted blue.
indicates the execution point of the current thread.
near a method indicates that a thread has stopped on this method.