FltWrite in pagingio pre-write

NTFSD
1

Has anyone seen an assertion like this before in FltWrite?

*** Assertion failed: IrpContext->TopLevelIrpContext->CleanupStructure ==
NULL
*** Source File: d:\xpsprtm\base\fs\ntfs\write.c, line 1127

This happens in a pre-write callback where I am writing to a separate write
data log file I am maintaining, before passing on the data for the
originally requested operation. This error happens in paging io pre-write
callbacks but does not happen in cached io callbacks. Does anyone know what
causes this or how to fix it? Nothing in the docs says anything about
top-level-irps being a problem for FltWrite.

I checked and IoGetTopLevelIrp() is returning a pointer to an Irp so this
call is initiated by the file system (NTFS). What kind of operation is the
file system doing in this type of call? I’m not really familiar with
top-level-irps.

2

NTFS doesn’t really store an IRP in the ETHREAD->TopLevelIrp field
(which is what is returned from IoGetTopLevelIrp). It stores a data
structure in which it keeps track of thread specific data. Think of the
TopLevelIrp field as a piece of file-system owned thread local storage.

The assert is NTFS telling you that some invariant of its internal
operations has been violated. My guess is that its locking is an issue.

You say “this happens in a pre-write callback”. I suspect if you dig a
bit deeper (try “kv” in WinDBG) you’ll see that this pre-write is itself
further embedded within the processing of some OTHER call. I have no
idea how Filter Manager is buffering you from these issues…

My suggestion: write to your log file from a different thread. In other
words, POST this to a worker thread and have it written from that worker
thread. That way you don’t worry about the state issues from
re-entrant calls.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Monday, April 11, 2005 5:56 PM
To: ntfsd redirect
Subject: [ntfsd] FltWrite in pagingio pre-write

Has anyone seen an assertion like this before in FltWrite?

*** Assertion failed: IrpContext->TopLevelIrpContext->CleanupStructure

NULL
*** Source File: d:\xpsprtm\base\fs\ntfs\write.c, line 1127

This happens in a pre-write callback where I am writing to a separate
write
data log file I am maintaining, before passing on the data for the
originally requested operation. This error happens in paging io
pre-write
callbacks but does not happen in cached io callbacks. Does anyone know
what
causes this or how to fix it? Nothing in the docs says anything about
top-level-irps being a problem for FltWrite.

I checked and IoGetTopLevelIrp() is returning a pointer to an Irp so
this
call is initiated by the file system (NTFS). What kind of operation is
the
file system doing in this type of call? I’m not really familiar with
top-level-irps.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

3

> I have no idea how Filter Manager is buffering you from these issues…

Apparently it isn’t. :slight_smile:

Thanks again…

“Tony Mason” wrote in message news:xxxxx@ntfsd…
NTFS doesn’t really store an IRP in the ETHREAD->TopLevelIrp field
(which is what is returned from IoGetTopLevelIrp). It stores a data
structure in which it keeps track of thread specific data. Think of the
TopLevelIrp field as a piece of file-system owned thread local storage.

The assert is NTFS telling you that some invariant of its internal
operations has been violated. My guess is that its locking is an issue.

You say “this happens in a pre-write callback”. I suspect if you dig a
bit deeper (try “kv” in WinDBG) you’ll see that this pre-write is itself
further embedded within the processing of some OTHER call. I have no
idea how Filter Manager is buffering you from these issues…

My suggestion: write to your log file from a different thread. In other
words, POST this to a worker thread and have it written from that worker
thread. That way you don’t worry about the state issues from
re-entrant calls.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Monday, April 11, 2005 5:56 PM
To: ntfsd redirect
Subject: [ntfsd] FltWrite in pagingio pre-write

Has anyone seen an assertion like this before in FltWrite?

Assertion failed: IrpContext->TopLevelIrpContext->CleanupStructure
==
NULL
 Source File: d:\xpsprtm\base\fs\ntfs\write.c, line 1127

This happens in a pre-write callback where I am writing to a separate
write
data log file I am maintaining, before passing on the data for the
originally requested operation. This error happens in paging io
pre-write
callbacks but does not happen in cached io callbacks. Does anyone know
what
causes this or how to fix it? Nothing in the docs says anything about
top-level-irps being a problem for FltWrite.

I checked and IoGetTopLevelIrp() is returning a pointer to an Irp so
this
call is initiated by the file system (NTFS). What kind of operation is
the
file system doing in this type of call? I’m not really familiar with
top-level-irps.

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

4

The goal of the filter manager was never to eliminate all that you need
to know to write a filter.

It is wrong for a filter to issue an IO to the file system while
TopLevelIrp has a non-zero value. If you do this you may deadlock the
system.

The filter manager has very basic minifilter verifier support built into
it. We are greatly enhancing this for longhorn which should help to
track down these types of issues.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Monday, April 11, 2005 4:58 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FltWrite in pagingio pre-write

I have no idea how Filter Manager is buffering you from these
issues…

Apparently it isn’t. :slight_smile:

Thanks again…

“Tony Mason” wrote in message news:xxxxx@ntfsd…
NTFS doesn’t really store an IRP in the ETHREAD->TopLevelIrp field
(which is what is returned from IoGetTopLevelIrp). It stores a data
structure in which it keeps track of thread specific data. Think of the
TopLevelIrp field as a piece of file-system owned thread local storage.

The assert is NTFS telling you that some invariant of its internal
operations has been violated. My guess is that its locking is an issue.

You say “this happens in a pre-write callback”. I suspect if you dig a
bit deeper (try “kv” in WinDBG) you’ll see that this pre-write is itself
further embedded within the processing of some OTHER call. I have no
idea how Filter Manager is buffering you from these issues…

My suggestion: write to your log file from a different thread. In other
words, POST this to a worker thread and have it written from that worker
thread. That way you don’t worry about the state issues from
re-entrant calls.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Monday, April 11, 2005 5:56 PM
To: ntfsd redirect
Subject: [ntfsd] FltWrite in pagingio pre-write

Has anyone seen an assertion like this before in FltWrite?

Assertion failed: IrpContext->TopLevelIrpContext->CleanupStructure
==
NULL
 Source File: d:\xpsprtm\base\fs\ntfs\write.c, line 1127

This happens in a pre-write callback where I am writing to a separate
write
data log file I am maintaining, before passing on the data for the
originally requested operation. This error happens in paging io
pre-write
callbacks but does not happen in cached io callbacks. Does anyone know
what
causes this or how to fix it? Nothing in the docs says anything about
top-level-irps being a problem for FltWrite.

I checked and IoGetTopLevelIrp() is returning a pointer to an Irp so
this
call is initiated by the file system (NTFS). What kind of operation is
the
file system doing in this type of call? I’m not really familiar with
top-level-irps.

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

5

Anything bad I say about the mini-filter I do with great appreciation for
it. After writing a legacy filter I truly enjoy rewriting it as a
mini-filter.

One comment: When I first started writing my legacy filter I did not really
know about or appreciate the mini-filter. It was only when this message
board suggested it, did I look into it. The ifs kit needs to have a
“CONSIDER USING A MINI-FILTER” message on every page. :slight_smile:

“Neal Christiansen” wrote in message
news:xxxxx@ntfsd…
The goal of the filter manager was never to eliminate all that you need
to know to write a filter.

It is wrong for a filter to issue an IO to the file system while
TopLevelIrp has a non-zero value. If you do this you may deadlock the
system.

The filter manager has very basic minifilter verifier support built into
it. We are greatly enhancing this for longhorn which should help to
track down these types of issues.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Monday, April 11, 2005 4:58 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FltWrite in pagingio pre-write

> I have no idea how Filter Manager is buffering you from these
issues…

Apparently it isn’t. :slight_smile:

Thanks again…

“Tony Mason” wrote in message news:xxxxx@ntfsd…
NTFS doesn’t really store an IRP in the ETHREAD->TopLevelIrp field
(which is what is returned from IoGetTopLevelIrp). It stores a data
structure in which it keeps track of thread specific data. Think of the
TopLevelIrp field as a piece of file-system owned thread local storage.

The assert is NTFS telling you that some invariant of its internal
operations has been violated. My guess is that its locking is an issue.

You say “this happens in a pre-write callback”. I suspect if you dig a
bit deeper (try “kv” in WinDBG) you’ll see that this pre-write is itself
further embedded within the processing of some OTHER call. I have no
idea how Filter Manager is buffering you from these issues…

My suggestion: write to your log file from a different thread. In other
words, POST this to a worker thread and have it written from that worker
thread. That way you don’t worry about the state issues from
re-entrant calls.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Monday, April 11, 2005 5:56 PM
To: ntfsd redirect
Subject: [ntfsd] FltWrite in pagingio pre-write

Has anyone seen an assertion like this before in FltWrite?

Assertion failed: IrpContext->TopLevelIrpContext->CleanupStructure
==
NULL
 Source File: d:\xpsprtm\base\fs\ntfs\write.c, line 1127

This happens in a pre-write callback where I am writing to a separate
write
data log file I am maintaining, before passing on the data for the
originally requested operation. This error happens in paging io
pre-write
callbacks but does not happen in cached io callbacks. Does anyone know
what
causes this or how to fix it? Nothing in the docs says anything about
top-level-irps being a problem for FltWrite.

I checked and IoGetTopLevelIrp() is returning a pointer to an Irp so
this
call is initiated by the file system (NTFS). What kind of operation is
the
file system doing in this type of call? I’m not really familiar with
top-level-irps.

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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