Win2K hanged on ExReleaseResourceForThread

NTFSD
1

Hi,

I want to flush data on IRP_MJ_CLEANUP. I write codes like following:

KeEnterCriticalRegion()
ExAcquireResourceExclusiveLite(Resource, TRUE);
ExAcquireResourceExclusiveLite(PagingIoResource, TRUE);

CcFlushCache(SectionObjectPointers, NULL, 0, &IoStatusBlock);
if( SectionObjectPointers->ImageSectionObject != NULL )
MmFlushImageSection(SectionObjectPointers, MmFlushForWrite);

ExReleaseResourceLite(PagingIoResource);
ExReleaseResourceLite(Resource);
KeLeaveCriticalRegion();

But system hanged soon. By SoftICE, I see there is an infinite loop in
ExReleaseResourceForThread.

Thanks a lot.

Zm Chen

2

You need to fix this code. You can’t assume that the resource
acquisition heirarchy for the filesystem you’ve attached to is Main
Resource then PagingIoResource. Ntfs, for example, acquires them in the
opposite order. If you violate the locking heirarchy you WILL deadlock
the system sooner or later. Fortunately, there is a way to acquire them
both safely (assuming you’re at the top level and neither of the
resources have been pre-acquired for the thread - CLEANUP is a safe time
to do this). First, acquire the main resource exclusive with Wait set to
TRUE. Then, try to acquire the paging I/O resources with Wait set to
FALSE. If ExAcquireResourceExclusiveLite returns FALSE, then back off by
releasing the main resource and pausing the thread for a short period of
time with KeDelayExecutionThread. Repeat until both resources have been
acquired.

It doesn’t matter what order you release them in.

  • Nick Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Zm Chen
Sent: Thursday, May 22, 2003 2:34 AM
To: File Systems Developers
Subject: [ntfsd] Win2K hanged on ExReleaseResourceForThread

Hi,

I want to flush data on IRP_MJ_CLEANUP. I write codes like following:

KeEnterCriticalRegion()
ExAcquireResourceExclusiveLite(Resource, TRUE);
ExAcquireResourceExclusiveLite(PagingIoResource, TRUE);

CcFlushCache(SectionObjectPointers, NULL, 0, &IoStatusBlock);
if( SectionObjectPointers->ImageSectionObject != NULL )
MmFlushImageSection(SectionObjectPointers,
MmFlushForWrite);

ExReleaseResourceLite(PagingIoResource);
ExReleaseResourceLite(Resource);
KeLeaveCriticalRegion();

But system hanged soon. By SoftICE, I see there is an
infinite loop in ExReleaseResourceForThread.

Thanks a lot.

Zm Chen

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

>I want to flush data on IRP_MJ_CLEANUP. I write codes like following:

KeEnterCriticalRegion()
ExAcquireResourceExclusiveLite(Resource, TRUE);
ExAcquireResourceExclusiveLite(PagingIoResource, TRUE);

CcFlushCache(SectionObjectPointers, NULL, 0, &IoStatusBlock);
if( SectionObjectPointers->ImageSectionObject != NULL )
MmFlushImageSection(SectionObjectPointers, MmFlushForWrite);

MmFlushImageSection may have side effect of dereferencing the file object.
As the result FCB may disappear making PagingIoResource and Resource
invalid.

ExReleaseResourceLite(PagingIoResource);
ExReleaseResourceLite(Resource);
KeLeaveCriticalRegion();

But system hanged soon. By SoftICE, I see there is an infinite loop in
ExReleaseResourceForThread

You can avoid the problem by using ObReferenceObject for FileObject before
you Acquired resources and dereference it after you have released
resources.

Alexei.

4

Surely in the case of a handle close, the system does not decrease the
pointer count on the file object until after it’s sent down the cleanup.

  • Nick Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
Sent: Thursday, May 22, 2003 1:20 PM
To: File Systems Developers
Subject: [ntfsd] Re: Win2K hanged on ExReleaseResourceForThread

>I want to flush data on IRP_MJ_CLEANUP. I write codes like following:
>
>KeEnterCriticalRegion()
ExAcquireResourceExclusiveLite(Resource, TRUE);
>ExAcquireResourceExclusiveLite(PagingIoResource, TRUE);
>
>CcFlushCache(SectionObjectPointers, NULL, 0, &IoStatusBlock); if(
>SectionObjectPointers->ImageSectionObject != NULL )
>MmFlushImageSection(SectionObjectPointers, MmFlushForWrite);

MmFlushImageSection may have side effect of dereferencing the
file object. As the result FCB may disappear making
PagingIoResource and Resource invalid.

>ExReleaseResourceLite(PagingIoResource);
>ExReleaseResourceLite(Resource);
>KeLeaveCriticalRegion();

>But system hanged soon. By SoftICE, I see there is an
infinite loop in
>ExReleaseResourceForThread

You can avoid the problem by using ObReferenceObject for
FileObject before you Acquired resources and dereference it
after you have released resources.

Alexei.

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

“Nick Ryan” wrote in message news:xxxxx@ntfsd…
>
> Surely in the case of a handle close, the system does not decrease the
> pointer count on the file object until after it’s sent down the cleanup.
>

Yes, that is true if IRP is not completed yet. Zm Chen experience problems
releasing resource after he successfully acquired it. This leads to believe
that the resource becomes invalid while he is holding it. He didn’t specify
if he is actually doing this after he sent IRP down. If IRP is already
completed then FileObject may be dereferenced; you can’t be sure when
IoManager dereference FileObject - on return from Dispatch routine or as a
post processing of IRP completion.
At least it will be interesting to hear from Zm Chen if referencing of the
FileObject helps along with additional details on what he is actually doing.

Alexei.

6

Thank you very much Nick and Alexei:

At least it will be interesting to hear from Zm Chen if referencing of the
FileObject helps along with additional details on what he is actually doing.

Actually, before I posted my first post on this problem, I have tried the following
code:

ObReference(FileObject);

KeEnterCriticalRegion()
ExAcquireResourceExclusiveLite(Resource, TRUE);
ExAcquireResourceExclusiveLite(PagingIoResource, TRUE);

CcFlushCache(SectionObjectPointers, NULL, 0, &IoStatusBlock);
if( SectionObjectPointers->ImageSectionObject != NULL )
MmFlushImageSection(SectionObjectPointers, MmFlushForWrite);

ExReleaseResourceLite(PagingIoResource);
ExReleaseResourceLite(Resource);
KeLeaveCriticalRegion();

ObDereference(FileObject);

But this didn’t help. And, the above code is executed before completing the IRP_MJ_CLEANUP IRP.

Zm Chen

7

Hi,

I have tried Nick’s method and debugging code in Ntfs a partition, it works.

But my problem dosen’t solved. Well, what I want to do is:

I write an user mode app, if it’s running, access to some predefined files
are allowed. If not, access will be declined.

The problem now is: if the app is running and I have written to some files,
then I terminate the app at once. Sooner or later, Win2K pop up a message
saying that lazy writter failed to write data back the access controlled files.

Are there any problems in my designation?

Thank you for any suggestions.

Chen

8

> to do this). First, acquire the main resource exclusive with Wait
set to

TRUE. Then, try to acquire the paging I/O resources with Wait set to
FALSE. If ExAcquireResourceExclusiveLite returns FALSE, then back
off by

Maybe calling the underlying FS’s FastIo callbacks related to
locking - AcquireForCreateSection and such - is a better idea?

Max

9

Calling the AcquireForCcFlush callback would be the cleanest solution,
but I recall being told at the latest Plugfest that this was not
intended for use by filters wanting to call CcFlushCache, and I didn’t
ask for further elaboraiton. You mentioned in an earlier list message
that NT4’s FastFat doesn’t even implement that callback, so one would
have to call FsRtlAcquireFileForCcFlush (it’s an …Ex function in XP
apparently) at the very least in order to take advantage of the fallback
behavior.

A quick look at the disassembly of FsRtlAcquireFileForCcFlushEx doesn’t
reveal anything unexpected. Calling it would have the advantage of
invoking the CcFlush pre- and post- acquire callbacks of any filters
who’ve registered such callbacks, which may be nice if you’re layered
over a filter who wants to pre-acquire his own resources. Can anybody at
Microsoft post-document this function for us on the fly?

  • Nick Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Friday, May 23, 2003 12:06 AM
To: File Systems Developers
Subject: [ntfsd] RE: Win2K hanged on ExReleaseResourceForThread

> to do this). First, acquire the main resource exclusive with Wait
set to
> TRUE. Then, try to acquire the paging I/O resources with
Wait set to
> FALSE. If ExAcquireResourceExclusiveLite returns FALSE, then back
off by

Maybe calling the underlying FS’s FastIo callbacks related to
locking - AcquireForCreateSection and such - is a better idea?

Max

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

10

Well, my inexperience with WinDbg shows… I forgot that x nt!* will
display all symbols, both exported and unexported (unlike SoftIce’s exp
command). FsRtlAcquireFileForCcFlush/Ex and FsRtlReleaseFileForCcFlush
are both unexported functions, and are thus incurably outside the scope
of our devious plans. Would have been convenient, though.

  • Nick Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nick Ryan
Sent: Friday, May 23, 2003 11:10 AM
To: File Systems Developers
Subject: [ntfsd] RE: Win2K hanged on ExReleaseResourceForThread

Calling the AcquireForCcFlush callback would be the cleanest
solution, but I recall being told at the latest Plugfest that
this was not intended for use by filters wanting to call
CcFlushCache, and I didn’t ask for further elaboraiton. You
mentioned in an earlier list message that NT4’s FastFat
doesn’t even implement that callback, so one would have to
call FsRtlAcquireFileForCcFlush (it’s an …Ex function in XP
apparently) at the very least in order to take advantage of
the fallback behavior.

A quick look at the disassembly of
FsRtlAcquireFileForCcFlushEx doesn’t reveal anything
unexpected. Calling it would have the advantage of invoking
the CcFlush pre- and post- acquire callbacks of any filters
who’ve registered such callbacks, which may be nice if you’re
layered over a filter who wants to pre-acquire his own
resources. Can anybody at Microsoft post-document this
function for us on the fly?

  • Nick Ryan

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
> S. Shatskih
> Sent: Friday, May 23, 2003 12:06 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: Win2K hanged on ExReleaseResourceForThread
>
>
> > to do this). First, acquire the main resource exclusive with Wait
> set to
> > TRUE. Then, try to acquire the paging I/O resources with
> Wait set to
> > FALSE. If ExAcquireResourceExclusiveLite returns FALSE, then back
> off by
>
> Maybe calling the underlying FS’s FastIo callbacks related to
> locking - AcquireForCreateSection and such - is a better idea?
>
> Max
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com