Bugcheck: RESOURCE_NOT_OWNED

Hi Gurus, I got a bugcheck RESOURCE_NOT_OWNED when releasing a resource. It happens on some machines. The code was trying to clear the cache in the worker thread. The codes logic is quite simple, I really don’t know why it happened. I pasted the dump analysis and source codes. The variable bHaveResource is true, it means the thread have acquired the pFCBHeader->PagingIoResource. but it caused RESOURCE_NOT_OWNED in the later releasing operation. I observed the CcPurgeCacheSection cause MJ_CLOSE issued. Will it also cause the status of pFCBHeader->PagingIoResource changed somehow?

RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: faa14ba8, Address of resource
Arg2: fc2f25a0, Address of thread
Arg3: 00000000, Address of owner table if there is one
Arg4: 00000002

Debugging Details:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xE3

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 8052c6ee to 8053769a

STACK_TEXT:
a737bcc4 8052c6ee 000000e3 faa14ba8 fc2f25a0 nt!KeBugCheckEx+0x1b
a737bcf8 a3c2287c a3c22866 04f4a515 00000000 nt!ExReleaseResourceLite+0x12b
a737bcfc a3c22866 04f4a515 00000000 fc2f25a0 docCrypto!ClearSections2+0x1fc [c:\smartlock\cryptominifilter\cryptodriver\clear_section.c @ 260]
a737bd34 a3c19915 e4f3b820 fa6986b4 04f4a58d docCrypto!ClearSections2+0x1e6 [c:\smartlock\cryptominifilter\cryptodriver\clear_section.c @ 255]
a737bdac 80576316 00000000 00000000 00000000 docCrypto!ThreadClearBuffer+0x425 [c:\smartlock\cryptominifilter\cryptodriver\mf_driver_entry.c @ 312]
a737bddc 804ec6f9 a3c194f0 00000000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
docCrypto!ClearSections2+1fc [c:\smartlock\cryptominifilter\cryptodriver\clear_section.c @ 260]
a3c2287c 0fb645e2 movzx eax,byte ptr [ebp-1Eh]

FAULTING_SOURCE_CODE:
256:
257: if(bHavePageResource)
258: ExReleaseResourceLite(pFCBHeader->PagingIoResource);
259:

260: if(bHaveResource)
261: ExReleaseResourceLite(pFCBHeader->Resource);
262:
263: KeLeaveCriticalRegion();
264: }
265:

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: docCrypto!ClearSections2+1fc

FOLLOWUP_NAME: MachineOwner

BOOLEAN ClearSections2(PFSRTL_COMMON_FCB_HEADER pFCBHeader, PSECTION_OBJECT_POINTERS pSection)
{
BOOLEAN bHaveResource = FALSE;
BOOLEAN bHavePageResource = FALSE;
BOOLEAN bRetVal = FALSE;
BOOLEAN retMmFlushImageSection= TRUE, retCcPurgeCacheSection = TRUE;
BOOLEAN retMmForceSectionClosed;
BOOLEAN bRunToEnd = FALSE;

if(pSection == NULL)
return FALSE;

KeEnterCriticalRegion();
try
{
try
{
if(NOT_TESTING(TEST_7) && pFCBHeader->Resource != NULL)
{
if(!ExIsResourceAcquiredSharedLite(pFCBHeader->Resource))
{
bHaveResource = ExAcquireResourceExclusiveLite(
pFCBHeader->Resource, FALSE);
if(!bHaveResource)
leave;
}
}

if(!bHaveResource)
leave;

if(pFCBHeader->PagingIoResource != NULL &&
(!ExIsResourceAcquiredSharedLite(pFCBHeader->PagingIoResource)))
{
if(NOT_TESTING(TEST_8))
{
bHavePageResource = ExAcquireResourceExclusiveLite(
pFCBHeader->PagingIoResource, FALSE);
if(!bHavePageResource)
leave;
}
}
if(!bHavePageResource)
leave;

CcFlushCache(pSection, 0, 0, NULL);

// If there are no mapped views of the image section,
// MmFlushImageSection destroys the image section and
// returns any used pages to the free list.
if (pSection->ImageSectionObject != NULL && NOT_TESTING(TEST_10))
retMmFlushImageSection = MmFlushImageSection(pSection, MmFlushForWrite);

// The CcPurgeCacheSection routine purges all or a portion of
// a cached file from the system cache.
// CcPurgeCacheSection will not purge mapped files.
if (pSection->DataSectionObject != NULL && NOT_TESTING(TEST_11))
retCcPurgeCacheSection = CcPurgeCacheSection(pSection, NULL, 0, TRUE);
else
bRetVal =TRUE;

if(NOT_TESTING(TEST_NO_MM_CLOSE))
retMmForceSectionClosed = MmForceSectionClosed(pSection, FALSE );
else
retMmForceSectionClosed = 2;//MmForceSectionClosed(pSection, TRUE );

//retCcUninitializeCacheMap = CcUninitializeCacheMap(FileObject, NULL, NULL);

//MmForceSectionClosed
/*MmForceSectionClosed returns TRUE if the sections were successfully deleted
or no sections were found, FALSE otherwise.

Note If there are one or more outstanding write probes on the file’s data section,
MmFlushImageSection returns FALSE. */

bRunToEnd = TRUE;

}
except (EXCEPTION_EXECUTE_HANDLER) {
DebugTrace( DEBUG_TRACE_ERROR,
(“[ClearSections2]: Failure on cache Clearup\n”));
}
}
finally{

if(bHavePageResource)
ExReleaseResourceLite(pFCBHeader->PagingIoResource);

if(bHaveResource)
ExReleaseResourceLite(pFCBHeader->Resource);

KeLeaveCriticalRegion();
}
return bRetVal;
}

This is an FSD (not a filter)?

Surely this hinges on thi question:

I observed the CcPurgeCacheSection cause MJ_CLOSE issued.
You bet it will sometimes inline, sometimes posted.

Will it also cause the status of pFCBHeader->PagingIoResource changed
somehow?

I don’t know. What does your code for handling MJ_CLOSE do?

“Rod Widdowson” wrote in message
news:xxxxx@ntfsd…
> This is an FSD (not a filter)?

Based on the source path it looks like he has a filter:

c:\smartlock\cryptominifilter\cryptodriver

Sounds like they’re playing with the lower locks and cache trying to get
something evicted and running into the expected sorts of horribleness…

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Rod Widdowson” wrote in message
news:xxxxx@ntfsd…
> This is an FSD (not a filter)?
>
> Surely this hinges on thi question:
>
>> I observed the CcPurgeCacheSection cause MJ_CLOSE issued.
> You bet it will sometimes inline, sometimes posted.
>
>> Will it also cause the status of pFCBHeader->PagingIoResource changed
>> somehow?
>
> I don’t know. What does your code for handling MJ_CLOSE do?
>
>

> Sounds like they’re playing with the lower locks and cache trying to get

something evicted and running into the expected sorts of horribleness…

Ayup, I suspected as much but (having not spotted the file names), wanted to
give OP the benefit of the doubt.

In

http://www.osronline.com/article.cfm?article=560

I liked this quote:

Over the years we have seen a number of different filters that try to:

  • Flush/purge the underlying file system’s cache. - Acquire locks
    (typically via the common header) in hopes that the underlying file system
    uses that specific locking model (a dangerous assumption, in fact). - Uses
    undocumented fields in the underlying file system’s control blocks to
    determine caching behavior (this is a problem for encryption filters
    sitting on the network redirector, since the redirector may change caching
    policy “in flight”).

If this really is a filter then it hits all three buttons…