The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
I am tracing critical section leaks and trying to figure out how to locate the source code behind which holds the critical section. I have an app which contains PDB file and I created memory dump.
For example, critical section below is one of the most busiest (high ContentionCount) and I would like to understand where in the source is the critical section created. For some reason I am not able to use Display Type (dt) command for some critical sections, for some critical sections dt command works fine.
Does all critical sections listed in user mode memory dump belong to process or is it possible that some belong to drivers ?
Any guidelines how to track down the location of critical section ?
0:000> !locks -v CritSec +adf30be8 at 0000003eadf30be8 LockCount NOT LOCKED RecursionCount 0 OwningThread 0 EntryCount 0 ContentionCount 797047 0:000> dt _RTL_CRITICAL_SECTION 0000003eadf30be8 myapp!_RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x00000089`3a3d81a0 _RTL_CRITICAL_SECTION_DEBUG +0x008 LockCount : 0n-1 +0x00c RecursionCount : 0n0 +0x010 OwningThread : (null) +0x018 LockSemaphore : 0xffffffff`ffffffff Void +0x020 SpinCount : 0x200013c 0:000> dx -r1 ((myapp!_RTL_CRITICAL_SECTION_DEBUG *)0x893a3d81a0) ((myapp!_RTL_CRITICAL_SECTION_DEBUG *)0x893a3d81a0) : 0x893a3d81a0 [Type: _RTL_CRITICAL_SECTION_DEBUG *] [+0x000] Type : 0x0 [Type: unsigned short] [+0x002] CreatorBackTraceIndex : 0x0 [Type: unsigned short] [+0x008] CriticalSection : 0x3eadf30be8 [Type: _RTL_CRITICAL_SECTION *] [+0x010] ProcessLocksList [Type: _LIST_ENTRY] [+0x020] EntryCount : 0x0 [Type: unsigned long] [+0x024] ContentionCount : 0x797047 [Type: unsigned long] [+0x028] Flags : 0x0 [Type: unsigned long] [+0x02c] CreatorBackTraceIndexHigh : 0x0 [Type: unsigned short] [+0x02e] SpareWORD : 0x74 [Type: unsigned short] 0:000> dx -r1 ((myapp!_RTL_CRITICAL_SECTION *)0x3eadf30be8) ((myapp!_RTL_CRITICAL_SECTION *)0x3eadf30be8) : 0x3eadf30be8 [Type: _RTL_CRITICAL_SECTION *] [+0x000] DebugInfo : 0x893a3d81a0 [Type: _RTL_CRITICAL_SECTION_DEBUG *] [+0x008] LockCount : -1 [Type: long] [+0x00c] RecursionCount : 0 [Type: long] [+0x010] OwningThread : 0x0 [Type: void *] [+0x018] LockSemaphore : 0xffffffffffffffff [Type: void *] [+0x020] SpinCount : 0x200013c [Type: unsigned __int64] 0:000> dt 0000003eadf30be8 Symbol not found at address 0000003eadf30be8. 0:000> ln 0000003eadf30be8 Browse module Set bu breakpoint
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!|
|Internals & Software Drivers||15 November 2021||Live, Online|
|Writing WDF Drivers||24 January 2022||Live, Online|
|Developing Minifilters||7 February 2022||Live, Online|
|Kernel Debugging||21 March 2022||Live, Online|