Managed Thread Stacks Tool Window (Ctl-Shift-M) Multiple Threads
Browse Multiple thread's call stacks at the same time. No more switching threads using the threads window Automatic Deadlock Detection
If there's a deadlock, it will appear in the deadlocks node. No more trawling through call stack and autos windows to find those pesky critters hiding away. Wait and Owned
See which objects your thread owns, and which object you are waiting on. See the SyncBlk items in the CLR that your thread owns, and the single SyncBlock that you are waiting on. Displayed as the object that the SyncBlock is attached to. Fake-Syncblocks are used for each thread to show join deadlocks. I.E. Where thread 'A' is joining on another thread 'B' who is waiting on SyncBlock 'X' which is owned by thread 'A'. CLR Stack Frames, as CLR reports them
See the actual internal CLR Stack frames and frame types as the CLR stores them Context Menu
Choose from Hexidecimal display, Module names, Line numbers and byte offsets Go to Code, Go to Disassembly
Double click on the stack frame and go to the line of code, if available, or the JIT disassembly of the method. Unmanaged Thread Stacks Tool Window (DebugInspector.Studio.exe) Multiple Threads
Browse Multiple thread's call stacks at the same time. No more switching threads using the threads window Automatic Deadlock Detection*
If there's a deadlock, it will appear in the deadlocks node. No more trawling through call stack and autos windows to find those pesky critters hiding away. Because certain WIN32 primitives such as Events and Semaphores do not record their owning thread (even inside the kernel), or the concept of an owning thread is not applicable, not all deadlocks can be automatically resolved. But you will have a snapshot of the entire wait chain for each thread. Others, such as Critical Sections involve a bit more work mapping the Event object back to the CRITICAL_SECTION, which then displays the owning thread, so deadlocks can be resolved for these. Both WaitForSingleObject and WaitForMultipleObjects are covered by Debug Inspector. Since not all objects have thread owners, the following are automatically covered by Debug Inspector. The rest are indicated by Wait and Suspect deadlocks.
Thread Deadlocks Thread Deadlocks are genuine discovered deadlocks and pinpoint the wait call chain that has lead up to it. Wait Deadlocks These are the cyclical wait chains but could be part of WaitForMultipleObjects calls where one of the threads participating in the call cannot be verified as deadlocked. Suspect Deadlocks These are the wait call chains that span more than one thread but get to a thread who cannot be a guaranteed owner of any objects. Wait and Owned
See which objects (not all types) your thread owns, and which kernel objects you are waiting on. Context Menu
Choose from Hexidecimal display, Module names, Line numbers and byte offsets Go to Code, Go to Disassembly
Double click on the stack frame and go to the line of code, if available, or the disassembly of the method. |