Crash while releasing fast mutex

NTFSD
1

My code looks like this

try
{
ExAcquireFastMutex

.................................
.................................
...............................

ExReleaseFastMutex

}
finally
{
if(KeGetCurrentIrql() == APC_LEVEL)
ExReleaseFastMutex
}

This code is written with a thought that if somehow exception occurs after
acquiring fast mutex and before releasing fast mutex, then the fast mutex
must be released in finally.
But what i saw using debugger that mutex is released inside try block and
still KeGetCurrentIrql returns 1. That's why system got crashed at this
statement. I am currently using driver verifier to test the driver and the
bugcheck

BugCheck C4, {1007, baf0a620, 869960f0, 0}

Bugcheck analysis

*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
will
be among the most commonly seen crashes.
Parameter 1 = 0x1000 .. 0x1020 - deadlock verifier error codes.
Typically the code is 0x1001 (deadlock detected) and you can
issue a '!deadlock' KD command to get more information.
Arguments:
Arg1: 00001007, subclass of driver violation.
Arg2: baf0a620
Arg3: 869960f0
Arg4: 00000000

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

BUGCHECK_STR: 0xc4_1007

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 8053721e to 804e30d9

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
f703671c 8053721e 00000003 8056a680 00000000 nt!DbgBreakPointWithStatus+0x4
f7036afc 80537832 000000c4 00001007 baf0a620
nt!KeDeregisterBugCheckReasonCallback+0x6c7
f7036b1c 8067c083 000000c4 00001007 baf0a620 nt!KeBugCheckEx+0x1b
f7036b3c 8067d365 00001007 baf0a620 869960f0 nt!RtlCompressBuffer+0xa998
f7036b6c 806755e3 baf0a620 00000000 86688da8 nt!RtlCompressBuffer+0xbc7a
f7036b88 baf07e9a baf07e7c 8056a680 e100ed30 nt!RtlCompressBuffer+0x3ef8
f7036b8c baf07e7c 8056a680 e100ed30 00000008 drv!Store+0x3ca
[f:\cyberauditor\driver\drv\hlp.c @ 243]
f7036be4 806357ec 8695ded0 000002a4 f7036c24 drv!Store+0x3ac
[f:\cyberauditor\driver\drv\hlp.c @ 233]
f7036c04 805fde48 8695ded0 000002a4 f7036c24
nt!PsRemoveLoadImageNotifyRoutine+0xb9
f7036c48 80587a6d 86799ce8 66700000 f7036d18
nt!FsRtlDeleteKeyFromTunnelCache+0x12312
f7036ca4 80580b45 00000004 86912110 f7036d18
nt!NtQuerySystemInformation+0x197e
f7036d34 804ddf0f 00000024 ffffffff 0015f7d0 nt!NtMapViewOfSection+0x22f
f7036d64 7c90eb94 badb0d00 0015f700 c7c7c7c7 nt!KiDeliverApc+0xbbb
0015f7ec 7c916071 00000000 0015f878 00000000 ntdll!KiFastSystemCallRet
0015faac 7c9162da 00000000 00000000 00000000
ntdll!RtlValidateUnicodeString+0x3ff
0015fd54 48585e7e 00000000 00000000 0015fd7c ntdll!LdrLoadDll+0x110
0015fd84 485878a2 0015fe40 0015fe48 0015fe4c smss+0x5e7e
0015fe58 48588c79 00000000 7c9012d6 00000000 smss+0x78a2
0015fecc 48588f27 0015ff6c 00000005 00000000 smss+0x8c79
0015ff18 48589bfc 0015ff6c 0015ff64 00000005 smss+0x8f27
0015ffa8 4858ad97 00000001 00162340 00162348 smss+0x9bfc
0015fff4 00000000 7ffde000 000000c8 0000012f smss+0xad97

FOLLOWUP_IP:
drv!Store+3ca [f:\cyberauditor\driver\drv\hlp.c @ 243]
baf07e9a 837dcc00 cmp dword ptr [ebp-0x34],0x0

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: drv!Store+3ca

MODULE_NAME: drv

IMAGE_NAME: drv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 448a531d

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

2

Rohit,

>This code is written with a thought that if somehow exception occurs
after acquiring fast mutex and before releasing fast mutex, then >>the fast
mutex must be released in finally.But what i saw using debugger that mutex
is released inside try block and still >>KeGetCurrentIrql returns 1.
That’s why system got crashed at this statement.

see the ExAcquireFastMutex & *ExAcquireFastMutex* documents from IFS Kit
(Callers of *ExAcquireFastMutex* must be running at IRQL <= APC_LEVEL. *
ExAcquireFastMutex* sets the IRQL to APC_LEVEL, and the caller continues to
run at APC_LEVEL after *ExAcquireFastMutex* returns.
*ExAcquireFastMutex*saves the caller’s previous IRQL in the mutex,
however, and that IRQL is
restored when the caller invokes *ExReleaseFastMutex*. )

You are releasing the FastMutex twice. Comment the ExReleaseFastMutex call
in the try block & KeGetCurrentIrql() in finally block.
See what hapends…

try
{
ExAcquireFastMutex

…
…
…

// ExReleaseFastMutex - > Don’t call here

}
finally
{
// if(KeGetCurrentIrql() == APC_LEVEL) -> Not necessary

ExReleaseFastMutex
}

Regards
Murali

3

Thanks Murali

Sorry for giving the partial information.

I appreciate your comments but ExReleaseFastMutex is not the last statement
inside try block. there are around 10 lines of code after
ExReleaseFastMutex. I want that code to executed after releasing fast mutex.

I thought of a solution and i appreciate your comments on that. Solution is

In the above code if i replace the line
if(KeGetCurrentIrql() == APC_LEVEL)
with
ExTryToAcquireFastMutex

4

Sorry i couldn’t able to understand your solution. If you don’t mind, you
can share the code.

On 6/10/06, Rohit wrote:
>
> Thanks Murali
>
> Sorry for giving the partial information.
>
> I appreciate your comments but ExReleaseFastMutex is not the last
> statement inside try block. there are around 10 lines of code after
> ExReleaseFastMutex. I want that code to executed after releasing fast mutex.
>
>
> I thought of a solution and i appreciate your comments on that. Solution
> is
>
> In the above code if i replace the line
> if(KeGetCurrentIrql() == APC_LEVEL)
> with
> ExTryToAcquireFastMutex
>
>
>
>
> — Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17 You are currently subscribed
> to ntfsd as: xxxxx@gmail.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

5

On 6/10/06 1:06 AM, “Rohit” wrote:
> My code looks like this
>
> try
> {
> ExAcquireFastMutex
>
> …
> …
> …
>
> ExReleaseFastMutex
>
> }
> finally
> {
> if(KeGetCurrentIrql() == APC_LEVEL)
> ExReleaseFastMutex
> }

The IRQL-based test is broken. What if you were already at APC_LEVEL when
you got the fast mutex to start with? Your test will evaluate to true and
you’ll release the mutex twice.

-Steve

6

Hi,
First of all, change your symbol file path to correct, because
“WARNING: Stack unwind information not available. Following frames may be wrong.” before the nt!* stack means you do not have symbols for kernel.
Second, your assumption is not good except you call this code in your own thread( but it seems not ).
Try this if you do not want to release mutex only in finally block

BOOLEAN IsMutexAcquired =FALSE;
try
{
ExAcquireFastMutex();
IsMutexAcquired = TRUE;

…
…
…

ExReleaseFastMutex();
IsMutexAcquired = FALSE;

}
finally
{
if( IsMutexAcquired ){
ExReleaseFastMutex();
IsMutexAcquired = FALSE;
}
}

“Rohit” wrote in message news:xxxxx@ntfsd…
My code looks like this

try
{
ExAcquireFastMutex

…
…
…

ExReleaseFastMutex

}
finally
{
if(KeGetCurrentIrql() == APC_LEVEL)
ExReleaseFastMutex
}

This code is written with a thought that if somehow exception occurs after acquiring fast mutex and before releasing fast mutex, then the fast mutex must be released in finally.
But what i saw using debugger that mutex is released inside try block and still KeGetCurrentIrql returns 1. That’s why system got crashed at this statement. I am currently using driver verifier to test the driver and the bugcheck

BugCheck C4, {1007, baf0a620, 869960f0, 0}

Bugcheck analysis

***
*
* Bugcheck Analysis
*


DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Parameter 1 = 0x1000 … 0x1020 - deadlock verifier error codes.
Typically the code is 0x1001 (deadlock detected) and you can
issue a ‘!deadlock’ KD command to get more information.
Arguments:
Arg1: 00001007, subclass of driver violation.
Arg2: baf0a620
Arg3: 869960f0
Arg4: 00000000

Debugging Details:
------------------

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

BUGCHECK_STR: 0xc4_1007

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 8053721e to 804e30d9

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
f703671c 8053721e 00000003 8056a680 00000000 nt!DbgBreakPointWithStatus+0x4
f7036afc 80537832 000000c4 00001007 baf0a620 nt!KeDeregisterBugCheckReasonCallback+0x6c7
f7036b1c 8067c083 000000c4 00001007 baf0a620 nt!KeBugCheckEx+0x1b
f7036b3c 8067d365 00001007 baf0a620 869960f0 nt!RtlCompressBuffer+0xa998
f7036b6c 806755e3 baf0a620 00000000 86688da8 nt!RtlCompressBuffer+0xbc7a
f7036b88 baf07e9a baf07e7c 8056a680 e100ed30 nt!RtlCompressBuffer+0x3ef8
f7036b8c baf07e7c 8056a680 e100ed30 00000008 drv!Store+0x3ca [f:\cyberauditor\driver\drv\hlp.c @ 243]
f7036be4 806357ec 8695ded0 000002a4 f7036c24 drv!Store+0x3ac [f:\cyberauditor\driver\drv\hlp.c @ 233]
f7036c04 805fde48 8695ded0 000002a4 f7036c24 nt!PsRemoveLoadImageNotifyRoutine+0xb9
f7036c48 80587a6d 86799ce8 66700000 f7036d18 nt!FsRtlDeleteKeyFromTunnelCache+0x12312
f7036ca4 80580b45 00000004 86912110 f7036d18 nt!NtQuerySystemInformation+0x197e
f7036d34 804ddf0f 00000024 ffffffff 0015f7d0 nt!NtMapViewOfSection+0x22f
f7036d64 7c90eb94 badb0d00 0015f700 c7c7c7c7 nt!KiDeliverApc+0xbbb
0015f7ec 7c916071 00000000 0015f878 00000000 ntdll!KiFastSystemCallRet
0015faac 7c9162da 00000000 00000000 00000000 ntdll!RtlValidateUnicodeString+0x3ff
0015fd54 48585e7e 00000000 00000000 0015fd7c ntdll!LdrLoadDll+0x110
0015fd84 485878a2 0015fe40 0015fe48 0015fe4c smss+0x5e7e
0015fe58 48588c79 00000000 7c9012d6 00000000 smss+0x78a2
0015fecc 48588f27 0015ff6c 00000005 00000000 smss+0x8c79
0015ff18 48589bfc 0015ff6c 0015ff64 00000005 smss+0x8f27
0015ffa8 4858ad97 00000001 00162340 00162348 smss+0x9bfc
0015fff4 00000000 7ffde000 000000c8 0000012f smss+0xad97

FOLLOWUP_IP:
drv!Store+3ca [f:\cyberauditor\driver\drv\hlp.c @ 243]
baf07e9a 837dcc00 cmp dword ptr [ebp-0x34],0x0

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: drv!Store+3ca

MODULE_NAME: drv

IMAGE_NAME: drv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 448a531d

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------

7

Exceptions are evil, when connected to lock acquisitions. Use the return
error codes instead.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Rohit”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, June 10, 2006 10:06 AM
Subject: [ntfsd] Crash while releasing fast mutex

> My code looks like this
>
> try
> {
> ExAcquireFastMutex
>
> …
> …
> …
>
> ExReleaseFastMutex
>
> }
> finally
> {
> if(KeGetCurrentIrql() == APC_LEVEL)
> ExReleaseFastMutex
> }
>
> This code is written with a thought that if somehow exception occurs after
> acquiring fast mutex and before releasing fast mutex, then the fast mutex
> must be released in finally.
> But what i saw using debugger that mutex is released inside try block and
> still KeGetCurrentIrql returns 1. That’s why system got crashed at this
> statement. I am currently using driver verifier to test the driver and the
> bugcheck
>
> BugCheck C4, {1007, baf0a620, 869960f0, 0}
>
> Bugcheck analysis
>
>
>
*****
>
>
> * Bugcheck
> Analysis
>
>
>
>
> DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
> A device driver attempting to corrupt the system has been caught. This is
> because the driver was specified in the registry as being suspect (by the
> administrator) and the kernel has enabled substantial checking of this
> driver.
> If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
> will
> be among the most commonly seen crashes.
> Parameter 1 = 0x1000 … 0x1020 - deadlock verifier error codes.
> Typically the code is 0x1001 (deadlock detected) and you can
> issue a ‘!deadlock’ KD command to get more information.
> Arguments:
> Arg1: 00001007, subclass of driver violation.
> Arg2: baf0a620
> Arg3: 869960f0
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
> ***** Kernel symbols are WRONG. Please fix symbols to do analysis.
>
>
> BUGCHECK_STR: 0xc4_1007
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> LAST_CONTROL_TRANSFER: from 8053721e to 804e30d9
>
> STACK_TEXT:
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f703671c 8053721e 00000003 8056a680 00000000 nt!DbgBreakPointWithStatus+0x4
> f7036afc 80537832 000000c4 00001007 baf0a620
> nt!KeDeregisterBugCheckReasonCallback+0x6c7
> f7036b1c 8067c083 000000c4 00001007 baf0a620 nt!KeBugCheckEx+0x1b
> f7036b3c 8067d365 00001007 baf0a620 869960f0 nt!RtlCompressBuffer+0xa998
> f7036b6c 806755e3 baf0a620 00000000 86688da8 nt!RtlCompressBuffer+0xbc7a
> f7036b88 baf07e9a baf07e7c 8056a680 e100ed30 nt!RtlCompressBuffer+0x3ef8
> f7036b8c baf07e7c 8056a680 e100ed30 00000008 drv!Store+0x3ca
> [f:\cyberauditor\driver\drv\hlp.c @ 243]
> f7036be4 806357ec 8695ded0 000002a4 f7036c24 drv!Store+0x3ac
> [f:\cyberauditor\driver\drv\hlp.c @ 233]
> f7036c04 805fde48 8695ded0 000002a4 f7036c24
> nt!PsRemoveLoadImageNotifyRoutine+0xb9
> f7036c48 80587a6d 86799ce8 66700000 f7036d18
> nt!FsRtlDeleteKeyFromTunnelCache+0x12312
> f7036ca4 80580b45 00000004 86912110 f7036d18
> nt!NtQuerySystemInformation+0x197e
> f7036d34 804ddf0f 00000024 ffffffff 0015f7d0 nt!NtMapViewOfSection+0x22f
> f7036d64 7c90eb94 badb0d00 0015f700 c7c7c7c7 nt!KiDeliverApc+0xbbb
> 0015f7ec 7c916071 00000000 0015f878 00000000 ntdll!KiFastSystemCallRet
> 0015faac 7c9162da 00000000 00000000 00000000
> ntdll!RtlValidateUnicodeString+0x3ff
> 0015fd54 48585e7e 00000000 00000000 0015fd7c ntdll!LdrLoadDll+0x110
> 0015fd84 485878a2 0015fe40 0015fe48 0015fe4c smss+0x5e7e
> 0015fe58 48588c79 00000000 7c9012d6 00000000 smss+0x78a2
> 0015fecc 48588f27 0015ff6c 00000005 00000000 smss+0x8c79
> 0015ff18 48589bfc 0015ff6c 0015ff64 00000005 smss+0x8f27
> 0015ffa8 4858ad97 00000001 00162340 00162348 smss+0x9bfc
> 0015fff4 00000000 7ffde000 000000c8 0000012f smss+0xad97
>
>
> FOLLOWUP_IP:
> drv!Store+3ca [f:\cyberauditor\driver\drv\hlp.c @ 243]
> baf07e9a 837dcc00 cmp dword ptr [ebp-0x34],0x0
>
> SYMBOL_STACK_INDEX: 6
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: drv!Store+3ca
>
> MODULE_NAME: drv
>
> IMAGE_NAME: drv.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 448a531d
>
> STACK_COMMAND: kb
>
> BUCKET_ID: WRONG_SYMBOLS
>
> Followup: MachineOwner
> ---------
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com