OSRLogoOSRLogoOSRLogo x Seminar Ad

Everything Windows Driver Development

GoToHomePage xLoginx

    Thu, 14 Mar 2019     118020 members


  Online Dump Analyzer
OSR Dev Blog
The NT Insider
The Basics
File Systems
ListServer / Forum
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

Beware the Guarded Mutex

In the folklore of file systems, we know that IRQL APC_LEVEL is used to prevent the delivery of all forms of APC - both normal and kernel mode APCs.  This is because paging I/O operations are always sent at APC_LEVEL.  However, beginning in Windows Server 2003, this is no longer the case.  Instead, the Memory Manager now uses guarded mutexes. These are similar to fast mutexes except that instead of raising the IRQL of the processor, they merely block the delivery of all forms of kernel APC object.

Thus, for those developing file systems and file system filter drivers, it is now important to use KeAreApcsDisabled rather than just relying upon the IRQL of the system (it would be wonderful if KeAreApcsDisabled returned TRUE if IRQL > PASSIVE_LEVEL but right now that is not the case).  This is particularly critical because if special kernel APCs are disabled, no calls should be passed that rely upon I/O completion processing - otherwise the operation might hang and never completed.

For a network file system, no calls should be made to TDI if KeAreApcsDisabled returns TRUE.  Similarly, no kernel component should call any of the Zw API operations for I/O operations if KeAreApcsDisabled returns TRUE.

Note that in the current (Windows Server 2003, Build 3790) the documentation for KeAreApcsDisabled is incorrect - it says "The system still delivers special kernel APCs even if KeAreApcsDisabled returns TRUE".  This was certainly true in Windows XP and earlier versions, but is not the case in 2003.  This can be seen from the disassembly (from Windows Server 2003, Build 3790):

0: kd> u nt!KeAreApcsDisabled
80827bf0 64a124010000     mov     eax,fs:[00000124]
80827bf6 83787000         cmp     dword ptr [eax+0x70],0x0
80827bfa 0f95c0           setne   al
80827bfd c3               ret

Thus, this returns the DWORD value at offset 0x70 in the KTHREAD (fs:[124] is always the address of the current thread). From the command dt nt!_KTHREAD we can find the value at offset 0x70:

   +0x070 KernelApcDisable : Int2B
   +0x072 SpecialApcDisable : Int2B
   +0x070 CombinedApcDisable : Uint4B

This is quite different than on Windows XP:

lkd> u nt!KeAreApcsDisabled
804f3756 64a124010000  mov eax,fs:[00000124]
804f375c 33c9          xor ecx,ecx
804f375e 3988d4000000  cmp [eax+0xd4],ecx
804f3764 0f95c1        setne cl
804f3767 8ac1          mov al,cl
804f3769 c3            ret

And at offset 0xd4:

+0x0d4 KernelApcDisable : Uint4B

There is no concept of SpecialApcDisable in Windows XP. In Windows Server 2003, however, this function will return TRUE if special kernel APCs are disabled through this explicit mechanism.

This can be a rather substantial change (we found this here at OSR while testing a low level I/O routine in a file system.  The system hung, we could see the special kernel APC had not been delivered and yet the thread was blocked at PASSIVE_LEVEL.)  It is an unfortunate oversight that this was not documented in the IFS Kit for Windows Server 2003, although we can hope that this oversight is addressed in the SP1 kit.

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

"Why the change?"
Could you elaborate on why the change was made? I'm not grasping the motivation here. This seems kind of like "critical section++" or something. What was Microsoft trying to improve by doing this?


Steve Dispensa www.kernelmustard.com

29-Sep-04, Steve Dispensa

"very informative"
nice. with the lh code most likely going to be based off of server 2003 this should apply to lh as well in the future.

12-Jun-04, Kinshumann Kinshumann

Post Your Comments.
Print this article.
Email this article.
bottom nav links