Contents

  Features
  Screenshots
  Future Plans
  FAQ
  Links
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.
  • Critical Sections
  • Mutants (Mutexes)
  • SendMessage
  • Thread Handles

 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.
 
 
 
 
 
 

Privacy Policy
©2008 DebugInspector. All rights reserved