trying to debug a crash

[OSR_Community_User]

I have written a fairly simple minifilter that I’m using to track opens and
closes on files. When the file is closed, I want to know if the file was
modified. I didn’t see anything in the information provided in
IRP_MJ_CLEANUP that would tell me this (if it is there, could someone tell
me where to look?), so I decided to use a StreamContext to determine the
information.

So, basically, I’m doing the following:

1. During the post callback for an IRP_MJ_CREATE, I create and set a
   StreamContext for the file.

2. During the post callback for an IPR_MJ_WRITE, I acquire the context and
   set my bool value to true, indicating that this file was modified during the
   processing.

3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context and
   check the bool to see if this file was modified.

This seems to run OK, but after a while, the process in #2 calls an OS
crash. I finally have WinDbg running (although not optimally - I can’t seem
to get symbol loading working yet), and right before the crash, I do see a
bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.

Here is the relevant code for the PostWriteCallback - anything obvious?

FLT_POSTOP_CALLBACK_STATUS

PostWriteCallback (

__inout PFLT_CALLBACK_DATA Data,

__in PCFLT_RELATED_OBJECTS FltObjects,

__in PVOID CompletionContext,

__in FLT_POST_OPERATION_FLAGS Flags

)

{

PT_STREAM_HANDLE_CONTEXT fileContext = NULL;

FLT_POSTOP_CALLBACK_STATUS returnStatus =
FLT_POSTOP_FINISHED_PROCESSING;

NTSTATUS status;

UNREFERENCED_PARAMETER( CompletionContext );

UNREFERENCED_PARAMETER( Flags );

if( FltObjects->FileObject == NULL )

{

DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );

return returnStatus;

}

if ( Data->IoStatus.Status != STATUS_SUCCESS )

{

DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
STATUS_SUCCESS\n” );

return returnStatus;

}

status = FltGetStreamHandleContext( FltObjects->Instance,

FltObjects->FileObject,

&fileContext );

if (NT_SUCCESS( status )) {

if( fileContext ) {

fileContext->FileModified = TRUE;

FltReleaseContext( fileContext );

}

}

return returnStatus;

}

–

Andrew Cheyne

Senior Software Developer

GridIron Software

[Lyndon_J_Clarke-2]

IRQL?

“Andrew Cheyne” wrote in message
news:xxxxx@ntfsd…
I have written a fairly simple minifilter that I’m using to track opens and
closes on files. When the file is closed, I want to know if the file was
modified. I didn’t see anything in the information provided in
IRP_MJ_CLEANUP that would tell me this (if it is there, could someone tell
me where to look?), so I decided to use a StreamContext to determine the
information.

So, basically, I’m doing the following:

1. During the post callback for an IRP_MJ_CREATE, I create and set a
StreamContext for the file.
2. During the post callback for an IPR_MJ_WRITE, I acquire the context and
set my bool value to true, indicating that this file was modified during the
processing.
3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context and
check the bool to see if this file was modified.

This seems to run OK, but after a while, the process in #2 calls an OS
crash. I finally have WinDbg running (although not optimally - I can’t seem
to get symbol loading working yet), and right before the crash, I do see a
bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.

Here is the relevant code for the PostWriteCallback - anything obvious?

FLT_POSTOP_CALLBACK_STATUS
PostWriteCallback (
inout PFLT_CALLBACK_DATA Data,
in PCFLT_RELATED_OBJECTS FltObjects,
in PVOID CompletionContext,
in FLT_POST_OPERATION_FLAGS Flags
)
{
PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
FLT_POSTOP_CALLBACK_STATUS returnStatus =
FLT_POSTOP_FINISHED_PROCESSING;
NTSTATUS status;

UNREFERENCED_PARAMETER( CompletionContext );
UNREFERENCED_PARAMETER( Flags );

if( FltObjects->FileObject == NULL )
{
DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
return returnStatus;
}
if ( Data->IoStatus.Status != STATUS_SUCCESS )
{
DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
STATUS_SUCCESS\n” );
return returnStatus;
}

status = FltGetStreamHandleContext( FltObjects->Instance,
FltObjects->FileObject,
&fileContext );

if (NT_SUCCESS( status )) {
if( fileContext ) {
fileContext->FileModified = TRUE;
FltReleaseContext( fileContext );
}
}
return returnStatus;
}

–
Andrew Cheyne
Senior Software Developer
GridIron Software

[OSR_Community_User]

Lyndon - I’m not sure what you’re asking. I’m relatively new to MiniFilter
development.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: May 17, 2007 4:58 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] trying to debug a crash

IRQL?

“Andrew Cheyne” wrote in message
news:xxxxx@ntfsd…
I have written a fairly simple minifilter that I’m using to track opens and
closes on files. When the file is closed, I want to know if the file was
modified. I didn’t see anything in the information provided in
IRP_MJ_CLEANUP that would tell me this (if it is there, could someone tell
me where to look?), so I decided to use a StreamContext to determine the
information.

So, basically, I’m doing the following:

1. During the post callback for an IRP_MJ_CREATE, I create and set a
StreamContext for the file.
2. During the post callback for an IPR_MJ_WRITE, I acquire the context and
set my bool value to true, indicating that this file was modified during the

processing.
3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context and
check the bool to see if this file was modified.

This seems to run OK, but after a while, the process in #2 calls an OS
crash. I finally have WinDbg running (although not optimally - I can’t seem
to get symbol loading working yet), and right before the crash, I do see a
bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.

Here is the relevant code for the PostWriteCallback - anything obvious?

FLT_POSTOP_CALLBACK_STATUS
PostWriteCallback (
inout PFLT_CALLBACK_DATA Data,
in PCFLT_RELATED_OBJECTS FltObjects,
in PVOID CompletionContext,
in FLT_POST_OPERATION_FLAGS Flags
)
{
PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
FLT_POSTOP_CALLBACK_STATUS returnStatus =
FLT_POSTOP_FINISHED_PROCESSING;
NTSTATUS status;

UNREFERENCED_PARAMETER( CompletionContext );
UNREFERENCED_PARAMETER( Flags );

if( FltObjects->FileObject == NULL )
{
DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
return returnStatus;
}
if ( Data->IoStatus.Status != STATUS_SUCCESS )
{
DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
STATUS_SUCCESS\n” );
return returnStatus;
}

status = FltGetStreamHandleContext( FltObjects->Instance,
FltObjects->FileObject,
&fileContext );

if (NT_SUCCESS( status )) {
if( fileContext ) {
fileContext->FileModified = TRUE;
FltReleaseContext( fileContext );
}
}
return returnStatus;
}

–
Andrew Cheyne
Senior Software Developer
GridIron Software

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

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

[Frank_Friemel]

You can not call FltGetStreamHandleContext inside PostXXXX function. IRQL may be to high at that point.

Instead: Call “FltGetStreamHandleContext” at PreXXXX, increase the reference count of the Context pointer and assign it to “*CompletionContext”. Then return with FLT_PREOP_SUCCESS_WITH_CALLBACK. In PostXXXX you can Release the Context pointer when you’re done.

“Andrew Cheyne” wrote news:xxxxx@ntfsd…
I have written a fairly simple minifilter that I’m using to track opens and closes on files. When the file is closed, I want to know if the file was modified. I didn’t see anything in the information provided in IRP_MJ_CLEANUP that would tell me this (if it is there, could someone tell me where to look?), so I decided to use a StreamContext to determine the information.

So, basically, I’m doing the following:

1. During the post callback for an IRP_MJ_CREATE, I create and set a StreamContext for the file.

2. During the post callback for an IPR_MJ_WRITE, I acquire the context and set my bool value to true, indicating that this file was modified during the processing.

3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context and check the bool to see if this file was modified.

This seems to run OK, but after a while, the process in #2 calls an OS crash. I finally have WinDbg running (although not optimally - I can’t seem to get symbol loading working yet), and right before the crash, I do see a bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.

Here is the relevant code for the PostWriteCallback - anything obvious?

FLT_POSTOP_CALLBACK_STATUS

PostWriteCallback (

inout PFLT_CALLBACK_DATA Data,

in PCFLT_RELATED_OBJECTS FltObjects,

in PVOID CompletionContext,

in FLT_POST_OPERATION_FLAGS Flags

)

{

PT_STREAM_HANDLE_CONTEXT fileContext = NULL;

FLT_POSTOP_CALLBACK_STATUS returnStatus = FLT_POSTOP_FINISHED_PROCESSING;

NTSTATUS status;

UNREFERENCED_PARAMETER( CompletionContext );

UNREFERENCED_PARAMETER( Flags );

if( FltObjects->FileObject == NULL )

{

DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );

return returnStatus;

}

if ( Data->IoStatus.Status != STATUS_SUCCESS )

{

DbgPrint( “PostWriteCallback:: Data->IoStatus.Status != STATUS_SUCCESS\n” );

return returnStatus;

}

status = FltGetStreamHandleContext( FltObjects->Instance,

FltObjects->FileObject,

&fileContext );

if (NT_SUCCESS( status )) {

if( fileContext ) {

fileContext->FileModified = TRUE;

FltReleaseContext( fileContext );

}

}

return returnStatus;

}

–

Andrew Cheyne

Senior Software Developer

GridIron Software

[OSR_Community_User]

Frank,

A thousand cases of beer for you.

Is this in the documentation anywhere?

And, what is the IRQL? I’ve tried to find references in the documentation
that explain what it is, but nothing that actually explains it in a way that
makes any sense.

Thanks again!

Andrew

---

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of frank
Sent: May 18, 2007 4:24 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] trying to debug a crash

You can not call FltGetStreamHandleContext inside PostXXXX function. IRQL
may be to high at that point.

Instead: Call “FltGetStreamHandleContext” at PreXXXX, increase the reference
count of the Context pointer and assign it to “*CompletionContext”. Then
return with FLT_PREOP_SUCCESS_WITH_CALLBACK. In PostXXXX you can Release the
Context pointer when you’re done.

“Andrew Cheyne” wrote news:xxxxx@ntfsd…

I have written a fairly simple minifilter that I’m using to track opens and
closes on files. When the file is closed, I want to know if the file was
modified. I didn’t see anything in the information provided in
IRP_MJ_CLEANUP that would tell me this (if it is there, could someone tell
me where to look?), so I decided to use a StreamContext to determine the
information.

So, basically, I’m doing the following:

1. During the post callback for an IRP_MJ_CREATE, I create and set a
StreamContext for the file.

2. During the post callback for an IPR_MJ_WRITE, I acquire the context and
set my bool value to true, indicating that this file was modified during the
processing.

3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context and
check the bool to see if this file was modified.

This seems to run OK, but after a while, the process in #2 calls an OS
crash. I finally have WinDbg running (although not optimally - I can’t seem
to get symbol loading working yet), and right before the crash, I do see a
bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.

Here is the relevant code for the PostWriteCallback - anything obvious?

FLT_POSTOP_CALLBACK_STATUS

PostWriteCallback (

inout PFLT_CALLBACK_DATA Data,

in PCFLT_RELATED_OBJECTS FltObjects,

in PVOID CompletionContext,

in FLT_POST_OPERATION_FLAGS Flags

)

{

PT_STREAM_HANDLE_CONTEXT fileContext = NULL;

FLT_POSTOP_CALLBACK_STATUS returnStatus =
FLT_POSTOP_FINISHED_PROCESSING;

NTSTATUS status;

UNREFERENCED_PARAMETER( CompletionContext );

UNREFERENCED_PARAMETER( Flags );

if( FltObjects->FileObject == NULL )

{

DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );

return returnStatus;

}

if ( Data->IoStatus.Status != STATUS_SUCCESS )

{

DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
STATUS_SUCCESS\n” );

return returnStatus;

}

status = FltGetStreamHandleContext( FltObjects->Instance,

FltObjects->FileObject,

&fileContext );

if (NT_SUCCESS( status )) {

if( fileContext ) {

fileContext->FileModified = TRUE;

FltReleaseContext( fileContext );

}

}

return returnStatus;

}

–

Andrew Cheyne

Senior Software Developer

GridIron Software

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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

Andrew

IRQL has to be one of the most basic conecpts for drivers.RTFM.

Lyndon

“Andrew Cheyne” wrote in message
news:xxxxx@ntfsd…
> Lyndon - I’m not sure what you’re asking. I’m relatively new to MiniFilter
> development.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: May 17, 2007 4:58 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] trying to debug a crash
>
> IRQL?
>
> “Andrew Cheyne” wrote in message
> news:xxxxx@ntfsd…
> I have written a fairly simple minifilter that I’m using to track opens
> and
> closes on files. When the file is closed, I want to know if the file was
> modified. I didn’t see anything in the information provided in
> IRP_MJ_CLEANUP that would tell me this (if it is there, could someone tell
> me where to look?), so I decided to use a StreamContext to determine the
> information.
>
> So, basically, I’m doing the following:
>
> 1. During the post callback for an IRP_MJ_CREATE, I create and set a
> StreamContext for the file.
> 2. During the post callback for an IPR_MJ_WRITE, I acquire the context and
> set my bool value to true, indicating that this file was modified during
> the
>
> processing.
> 3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context
> and
> check the bool to see if this file was modified.
>
> This seems to run OK, but after a while, the process in #2 calls an OS
> crash. I finally have WinDbg running (although not optimally - I can’t
> seem
> to get symbol loading working yet), and right before the crash, I do see a
> bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.
>
> Here is the relevant code for the PostWriteCallback - anything obvious?
>
> FLT_POSTOP_CALLBACK_STATUS
> PostWriteCallback (
> inout PFLT_CALLBACK_DATA Data,
> in PCFLT_RELATED_OBJECTS FltObjects,
> in PVOID CompletionContext,
> in FLT_POST_OPERATION_FLAGS Flags
> )
> {
> PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
> FLT_POSTOP_CALLBACK_STATUS returnStatus =
> FLT_POSTOP_FINISHED_PROCESSING;
> NTSTATUS status;
>
> UNREFERENCED_PARAMETER( CompletionContext );
> UNREFERENCED_PARAMETER( Flags );
>
>
> if( FltObjects->FileObject == NULL )
> {
> DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
> return returnStatus;
> }
> if ( Data->IoStatus.Status != STATUS_SUCCESS )
> {
> DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
> STATUS_SUCCESS\n” );
> return returnStatus;
> }
>
> status = FltGetStreamHandleContext( FltObjects->Instance,
> FltObjects->FileObject,
> &fileContext );
>
> if (NT_SUCCESS( status )) {
> if( fileContext ) {
> fileContext->FileModified = TRUE;
> FltReleaseContext( fileContext );
> }
> }
> return returnStatus;
> }
>
> –
> Andrew Cheyne
> Senior Software Developer
> GridIron Software
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gridironsoftware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

[OSR_Community_User]

Lyndon,

Thanks for your help. The primary document that Microsoft provides for
writing a minifilter is the “Filter Driver Development Guide”. I have been
using this in conjunction with the provided minifilter samples to develop
the driver. Nowhere in the samples or the documentation specific to
minifilters does it mention IRQL.

I’m glad that you’d RTFM’d everything, though, and can be so helpful to
others who are just starting out in driver development.

Cheers,
Andrew

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: May 18, 2007 10:26 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] trying to debug a crash

Andrew

IRQL has to be one of the most basic conecpts for drivers.RTFM.

Lyndon

“Andrew Cheyne” wrote in message
news:xxxxx@ntfsd…
> Lyndon - I’m not sure what you’re asking. I’m relatively new to MiniFilter
> development.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: May 17, 2007 4:58 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] trying to debug a crash
>
> IRQL?
>
> “Andrew Cheyne” wrote in message
> news:xxxxx@ntfsd…
> I have written a fairly simple minifilter that I’m using to track opens
> and
> closes on files. When the file is closed, I want to know if the file was
> modified. I didn’t see anything in the information provided in
> IRP_MJ_CLEANUP that would tell me this (if it is there, could someone tell
> me where to look?), so I decided to use a StreamContext to determine the
> information.
>
> So, basically, I’m doing the following:
>
> 1. During the post callback for an IRP_MJ_CREATE, I create and set a
> StreamContext for the file.
> 2. During the post callback for an IPR_MJ_WRITE, I acquire the context and
> set my bool value to true, indicating that this file was modified during
> the
>
> processing.
> 3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context
> and
> check the bool to see if this file was modified.
>
> This seems to run OK, but after a while, the process in #2 calls an OS
> crash. I finally have WinDbg running (although not optimally - I can’t
> seem
> to get symbol loading working yet), and right before the crash, I do see a
> bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.
>
> Here is the relevant code for the PostWriteCallback - anything obvious?
>
> FLT_POSTOP_CALLBACK_STATUS
> PostWriteCallback (
> inout PFLT_CALLBACK_DATA Data,
> in PCFLT_RELATED_OBJECTS FltObjects,
> in PVOID CompletionContext,
> in FLT_POST_OPERATION_FLAGS Flags
> )
> {
> PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
> FLT_POSTOP_CALLBACK_STATUS returnStatus =
> FLT_POSTOP_FINISHED_PROCESSING;
> NTSTATUS status;
>
> UNREFERENCED_PARAMETER( CompletionContext );
> UNREFERENCED_PARAMETER( Flags );
>
>
> if( FltObjects->FileObject == NULL )
> {
> DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
> return returnStatus;
> }
> if ( Data->IoStatus.Status != STATUS_SUCCESS )
> {
> DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
> STATUS_SUCCESS\n” );
> return returnStatus;
> }
>
> status = FltGetStreamHandleContext( FltObjects->Instance,
> FltObjects->FileObject,
> &fileContext );
>
> if (NT_SUCCESS( status )) {
> if( fileContext ) {
> fileContext->FileModified = TRUE;
> FltReleaseContext( fileContext );
> }
> }
> return returnStatus;
> }
>
> –
> Andrew Cheyne
> Senior Software Developer
> GridIron Software
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gridironsoftware.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@gridironsoftware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

Andrew

Your rudeness doesnt phase me

If you are just cant be bothered to discover where to read about bsics for
yourself then you might read one of the standard basics books such as
Viscarola and Mason. There are also some excellent courses run by OSR which
can be recommended.

Lyndon

“Andrew Cheyne” wrote in message
news:xxxxx@ntfsd…
> Lyndon,
>
> Thanks for your help. The primary document that Microsoft provides for
> writing a minifilter is the “Filter Driver Development Guide”. I have been
> using this in conjunction with the provided minifilter samples to develop
> the driver. Nowhere in the samples or the documentation specific to
> minifilters does it mention IRQL.
>
> I’m glad that you’d RTFM’d everything, though, and can be so helpful to
> others who are just starting out in driver development.
>
> Cheers,
> Andrew
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: May 18, 2007 10:26 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] trying to debug a crash
>
> Andrew
>
> IRQL has to be one of the most basic conecpts for drivers.RTFM.
>
> Lyndon
>
> “Andrew Cheyne” wrote in message
> news:xxxxx@ntfsd…
>> Lyndon - I’m not sure what you’re asking. I’m relatively new to
>> MiniFilter
>> development.
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: May 17, 2007 4:58 PM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] trying to debug a crash
>>
>> IRQL?
>>
>> “Andrew Cheyne” wrote in message
>> news:xxxxx@ntfsd…
>> I have written a fairly simple minifilter that I’m using to track opens
>> and
>> closes on files. When the file is closed, I want to know if the file was
>> modified. I didn’t see anything in the information provided in
>> IRP_MJ_CLEANUP that would tell me this (if it is there, could someone
>> tell
>> me where to look?), so I decided to use a StreamContext to determine the
>> information.
>>
>> So, basically, I’m doing the following:
>>
>> 1. During the post callback for an IRP_MJ_CREATE, I create and set a
>> StreamContext for the file.
>> 2. During the post callback for an IPR_MJ_WRITE, I acquire the context
>> and
>> set my bool value to true, indicating that this file was modified during
>> the
>>
>> processing.
>> 3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context
>> and
>> check the bool to see if this file was modified.
>>
>> This seems to run OK, but after a while, the process in #2 calls an OS
>> crash. I finally have WinDbg running (although not optimally - I can’t
>> seem
>> to get symbol loading working yet), and right before the crash, I do see
>> a
>> bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.
>>
>> Here is the relevant code for the PostWriteCallback - anything obvious?
>>
>> FLT_POSTOP_CALLBACK_STATUS
>> PostWriteCallback (
>> inout PFLT_CALLBACK_DATA Data,
>> in PCFLT_RELATED_OBJECTS FltObjects,
>> in PVOID CompletionContext,
>> in FLT_POST_OPERATION_FLAGS Flags
>> )
>> {
>> PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
>> FLT_POSTOP_CALLBACK_STATUS returnStatus =
>> FLT_POSTOP_FINISHED_PROCESSING;
>> NTSTATUS status;
>>
>> UNREFERENCED_PARAMETER( CompletionContext );
>> UNREFERENCED_PARAMETER( Flags );
>>
>>
>> if( FltObjects->FileObject == NULL )
>> {
>> DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
>> return returnStatus;
>> }
>> if ( Data->IoStatus.Status != STATUS_SUCCESS )
>> {
>> DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
>> STATUS_SUCCESS\n” );
>> return returnStatus;
>> }
>>
>> status = FltGetStreamHandleContext( FltObjects->Instance,
>> FltObjects->FileObject,
>> &fileContext );
>>
>> if (NT_SUCCESS( status )) {
>> if( fileContext ) {
>> fileContext->FileModified = TRUE;
>> FltReleaseContext( fileContext );
>> }
>> }
>> return returnStatus;
>> }
>>
>> –
>> Andrew Cheyne
>> Senior Software Developer
>> GridIron Software
>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@gridironsoftware.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@gridironsoftware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

[OSR_Community_User]

Andrew,

page 7: “The Filter Manager guarantees that these callbacks will be called at passive IRQL.”

page 22: “A minifilter can call FltGetFileNameInformation() at any point during its IO
processing when it is executing an IRQL less than DPC.”

Quoted from
http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/FilterDriverDeveloperGuide.doc

Not that I like the style Lindon has chosen, but please, don’t ask “What is DPC?” here, ok?

Thank you for your cooperation.

-------------- Original message --------------
From: “Lyndon J Clarke”

> Andrew
>
> Your rudeness doesnt phase me
>
> If you are just cant be bothered to discover where to read about bsics for
> yourself then you might read one of the standard basics books such as
> Viscarola and Mason. There are also some excellent courses run by OSR which
> can be recommended.
>
> Lyndon
>
> “Andrew Cheyne” wrote in message
> news:xxxxx@ntfsd…
> > Lyndon,
> >
> > Thanks for your help. The primary document that Microsoft provides for
> > writing a minifilter is the “Filter Driver Development Guide”. I have been
> > using this in conjunction with the provided minifilter samples to develop
> > the driver. Nowhere in the samples or the documentation specific to
> > minifilters does it mention IRQL.
> >
> > I’m glad that you’d RTFM’d everything, though, and can be so helpful to
> > others who are just starting out in driver development.
> >
> > Cheers,
> > Andrew
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> > Sent: May 18, 2007 10:26 AM
> > To: Windows File Systems Devs Interest List
> > Subject: Re:[ntfsd] trying to debug a crash
> >
> > Andrew
> >
> > IRQL has to be one of the most basic conecpts for drivers.RTFM.
> >
> > Lyndon
> >
> > “Andrew Cheyne” wrote in message
> > news:xxxxx@ntfsd…
> >> Lyndon - I’m not sure what you’re asking. I’m relatively new to
> >> MiniFilter
> >> development.
> >>
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> >> Sent: May 17, 2007 4:58 PM
> >> To: Windows File Systems Devs Interest List
> >> Subject: Re:[ntfsd] trying to debug a crash
> >>
> >> IRQL?
> >>
> >> “Andrew Cheyne” wrote in message
> >> news:xxxxx@ntfsd…
> >> I have written a fairly simple minifilter that I’m using to track opens
> >> and
> >> closes on files. When the file is closed, I want to know if the file was
> >> modified. I didn’t see anything in the information provided in
> >> IRP_MJ_CLEANUP that would tell me this (if it is there, could someone
> >> tell
> >> me where to look?), so I decided to use a StreamContext to determine the
> >> information.
> >>
> >> So, basically, I’m doing the following:
> >>
> >> 1. During the post callback for an IRP_MJ_CREATE, I create and set a
> >> StreamContext for the file.
> >> 2. During the post callback for an IPR_MJ_WRITE, I acquire the context
> >> and
> >> set my bool value to true, indicating that this file was modified during
> >> the
> >>
> >> processing.
> >> 3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context
> >> and
> >> check the bool to see if this file was modified.
> >>
> >> This seems to run OK, but after a while, the process in #2 calls an OS
> >> crash. I finally have WinDbg running (although not optimally - I can’t
> >> seem
> >> to get symbol loading working yet), and right before the crash, I do see
> >> a
> >> bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.
> >>
> >> Here is the relevant code for the PostWriteCallback - anything obvious?
> >>
> >> FLT_POSTOP_CALLBACK_STATUS
> >> PostWriteCallback (
> >> inout PFLT_CALLBACK_DATA Data,
> >> in PCFLT_RELATED_OBJECTS FltObjects,
> >> in PVOID CompletionContext,
> >> in FLT_POST_OPERATION_FLAGS Flags
> >> )
> >> {
> >> PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
> >> FLT_POSTOP_CALLBACK_STATUS returnStatus =
> >> FLT_POSTOP_FINISHED_PROCESSING;
> >> NTSTATUS status;
> >>
> >> UNREFERENCED_PARAMETER( CompletionContext );
> >> UNREFERENCED_PARAMETER( Flags );
> >>
> >>
> >> if( FltObjects->FileObject == NULL )
> >> {
> >> DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
> >> return returnStatus;
> >> }
> >> if ( Data->IoStatus.Status != STATUS_SUCCESS )
> >> {
> >> DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
> >> STATUS_SUCCESS\n” );
> >> return returnStatus;
> >> }
> >>
> >> status = FltGetStreamHandleContext( FltObjects->Instance,
> >> FltObjects->FileObject,
> >> &fileContext );
> >>
> >> if (NT_SUCCESS( status )) {
> >> if( fileContext ) {
> >> fileContext->FileModified = TRUE;
> >> FltReleaseContext( fileContext );
> >> }
> >> }
> >> return returnStatus;
> >> }
> >>
> >> –
> >> Andrew Cheyne
> >> Senior Software Developer
> >> GridIron Software
> >>
> >>
> >>
> >>
> >> —
> >> Questions? First check the IFS FAQ at
> >> https://www.osronline.com/article.cfm?id=17
> >>
> >> You are currently subscribed to ntfsd as: xxxxx@gridironsoftware.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@gridironsoftware.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@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

So, I was curious what DPC meant, and Alex appears to be in an anti-social mood, so I Googled for it and on page 5 of the results I found a Microsoft link for “Deferred Procedure Calls”. I don’t want to spend the time to verify that this is the correct definition, but just in case anyone else was curious…

---- xxxxx@comcast.net wrote:

Andrew,

page 7: “The Filter Manager guarantees that these callbacks will be called at passive IRQL.”

page 22: “A minifilter can call FltGetFileNameInformation() at any point during its IO
processing when it is executing an IRQL less than DPC.”

Quoted from
http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/FilterDriverDeveloperGuide.doc

Not that I like the style Lindon has chosen, but please, don’t ask “What is DPC?” here, ok?

Thank you for your cooperation.

-------------- Original message --------------
From: “Lyndon J Clarke”
>
> > Andrew
> >
> > Your rudeness doesnt phase me
> >
> > If you are just cant be bothered to discover where to read about bsics for
> > yourself then you might read one of the standard basics books such as
> > Viscarola and Mason. There are also some excellent courses run by OSR which
> > can be recommended.
> >
> > Lyndon
> >
> > “Andrew Cheyne” wrote in message
> > news:xxxxx@ntfsd…
> > > Lyndon,
> > >
> > > Thanks for your help. The primary document that Microsoft provides for
> > > writing a minifilter is the “Filter Driver Development Guide”. I have been
> > > using this in conjunction with the provided minifilter samples to develop
> > > the driver. Nowhere in the samples or the documentation specific to
> > > minifilters does it mention IRQL.
> > >
> > > I’m glad that you’d RTFM’d everything, though, and can be so helpful to
> > > others who are just starting out in driver development.
> > >
> > > Cheers,
> > > Andrew
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> > > Sent: May 18, 2007 10:26 AM
> > > To: Windows File Systems Devs Interest List
> > > Subject: Re:[ntfsd] trying to debug a crash
> > >
> > > Andrew
> > >
> > > IRQL has to be one of the most basic conecpts for drivers.RTFM.
> > >
> > > Lyndon
> > >
> > > “Andrew Cheyne” wrote in message
> > > news:xxxxx@ntfsd…
> > >> Lyndon - I’m not sure what you’re asking. I’m relatively new to
> > >> MiniFilter
> > >> development.
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: xxxxx@lists.osr.com
> > >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> > >> Sent: May 17, 2007 4:58 PM
> > >> To: Windows File Systems Devs Interest List
> > >> Subject: Re:[ntfsd] trying to debug a crash
> > >>
> > >> IRQL?
> > >>
> > >> “Andrew Cheyne” wrote in message
> > >> news:xxxxx@ntfsd…
> > >> I have written a fairly simple minifilter that I’m using to track opens
> > >> and
> > >> closes on files. When the file is closed, I want to know if the file was
> > >> modified. I didn’t see anything in the information provided in
> > >> IRP_MJ_CLEANUP that would tell me this (if it is there, could someone
> > >> tell
> > >> me where to look?), so I decided to use a StreamContext to determine the
> > >> information.
> > >>
> > >> So, basically, I’m doing the following:
> > >>
> > >> 1. During the post callback for an IRP_MJ_CREATE, I create and set a
> > >> StreamContext for the file.
> > >> 2. During the post callback for an IPR_MJ_WRITE, I acquire the context
> > >> and
> > >> set my bool value to true, indicating that this file was modified during
> > >> the
> > >>
> > >> processing.
> > >> 3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context
> > >> and
> > >> check the bool to see if this file was modified.
> > >>
> > >> This seems to run OK, but after a while, the process in #2 calls an OS
> > >> crash. I finally have WinDbg running (although not optimally - I can’t
> > >> seem
> > >> to get symbol loading working yet), and right before the crash, I do see
> > >> a
> > >> bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.
> > >>
> > >> Here is the relevant code for the PostWriteCallback - anything obvious?
> > >>
> > >> FLT_POSTOP_CALLBACK_STATUS
> > >> PostWriteCallback (
> > >> inout PFLT_CALLBACK_DATA Data,
> > >> in PCFLT_RELATED_OBJECTS FltObjects,
> > >> in PVOID CompletionContext,
> > >> in FLT_POST_OPERATION_FLAGS Flags
> > >> )
> > >> {
> > >> PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
> > >> FLT_POSTOP_CALLBACK_STATUS returnStatus =
> > >> FLT_POSTOP_FINISHED_PROCESSING;
> > >> NTSTATUS status;
> > >>
> > >> UNREFERENCED_PARAMETER( CompletionContext );
> > >> UNREFERENCED_PARAMETER( Flags );
> > >>
> > >>
> > >> if( FltObjects->FileObject == NULL )
> > >> {
> > >> DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
> > >> return returnStatus;
> > >> }
> > >> if ( Data->IoStatus.Status != STATUS_SUCCESS )
> > >> {
> > >> DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
> > >> STATUS_SUCCESS\n” );
> > >> return returnStatus;
> > >> }
> > >>
> > >> status = FltGetStreamHandleContext( FltObjects->Instance,
> > >> FltObjects->FileObject,
> > >> &fileContext );
> > >>
> > >> if (NT_SUCCESS( status )) {
> > >> if( fileContext ) {
> > >> fileContext->FileModified = TRUE;
> > >> FltReleaseContext( fileContext );
> > >> }
> > >> }
> > >> return returnStatus;
> > >> }
> > >>
> > >> –
> > >> Andrew Cheyne
> > >> Senior Software Developer
> > >> GridIron Software
> > >>
> > >>
> > >>
> > >>
> > >> —
> > >> Questions? First check the IFS FAQ at
> > >> https://www.osronline.com/article.cfm?id=17
> > >>
> > >> You are currently subscribed to ntfsd as: xxxxx@gridironsoftware.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@gridironsoftware.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@comcast.net
> > 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@cox.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

If I sounded anti-social, I am sorry, that was not my intent at all.

The intent was to point out that IRQL are mentioned in the document you read.

Actually, after you said that IRQL is never mentioned in some document about drivers, I was curious: is it at all possible? The concept is absolutely fundamental, as Lyndon pointed out, that’s why I took the trouble to check it out.

I am and will be doing my best to stay a socialite I actually am.

-------------- Original message --------------
From:

> So, I was curious what DPC meant, and Alex appears to be in an anti-social mood,
> so I Googled for it and on page 5 of the results I found a Microsoft link for
> “Deferred Procedure Calls”. I don’t want to spend the time to verify that this
> is the correct definition, but just in case anyone else was curious…
>
> ---- xxxxx@comcast.net wrote:
> > Andrew,
> >
> > page 7: “The Filter Manager guarantees that these callbacks will be called at
> passive IRQL.”
> >
> > page 22: “A minifilter can call FltGetFileNameInformation() at any point
> during its IO
> > processing when it is executing an IRQL less than DPC.”
> >
> > Quoted from
> >
> http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b4
> 5/FilterDriverDeveloperGuide.doc
> >
> > Not that I like the style Lindon has chosen, but please, don’t ask “What is
> DPC?” here, ok?
> >
> > Thank you for your cooperation.
> >
> >
> >
> > -------------- Original message --------------
> > From: “Lyndon J Clarke”
> >
> > > Andrew
> > >
> > > Your rudeness doesnt phase me
> > >
> > > If you are just cant be bothered to discover where to read about bsics for
> > > yourself then you might read one of the standard basics books such as
> > > Viscarola and Mason. There are also some excellent courses run by OSR which
> > > can be recommended.
> > >
> > > Lyndon
> > >
> > > “Andrew Cheyne” wrote in message
> > > news:xxxxx@ntfsd…
> > > > Lyndon,
> > > >
> > > > Thanks for your help. The primary document that Microsoft provides for
> > > > writing a minifilter is the “Filter Driver Development Guide”. I have been
> > > > using this in conjunction with the provided minifilter samples to develop
> > > > the driver. Nowhere in the samples or the documentation specific to
> > > > minifilters does it mention IRQL.
> > > >
> > > > I’m glad that you’d RTFM’d everything, though, and can be so helpful to
> > > > others who are just starting out in driver development.
> > > >
> > > > Cheers,
> > > > Andrew
> > > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> > > > Sent: May 18, 2007 10:26 AM
> > > > To: Windows File Systems Devs Interest List
> > > > Subject: Re:[ntfsd] trying to debug a crash
> > > >
> > > > Andrew
> > > >
> > > > IRQL has to be one of the most basic conecpts for drivers.RTFM.
> > > >
> > > > Lyndon
> > > >
> > > > “Andrew Cheyne” wrote in message
> > > > news:xxxxx@ntfsd…
> > > >> Lyndon - I’m not sure what you’re asking. I’m relatively new to
> > > >> MiniFilter
> > > >> development.
> > > >>
> > > >>
> > > >> -----Original Message-----
> > > >> From: xxxxx@lists.osr.com
> > > >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> > > >> Sent: May 17, 2007 4:58 PM
> > > >> To: Windows File Systems Devs Interest List
> > > >> Subject: Re:[ntfsd] trying to debug a crash
> > > >>
> > > >> IRQL?
> > > >>
> > > >> “Andrew Cheyne” wrote in message
> > > >> news:xxxxx@ntfsd…
> > > >> I have written a fairly simple minifilter that I’m using to track opens
> > > >> and
> > > >> closes on files. When the file is closed, I want to know if the file was
> > > >> modified. I didn’t see anything in the information provided in
> > > >> IRP_MJ_CLEANUP that would tell me this (if it is there, could someone
> > > >> tell
> > > >> me where to look?), so I decided to use a StreamContext to determine the
> > > >> information.
> > > >>
> > > >> So, basically, I’m doing the following:
> > > >>
> > > >> 1. During the post callback for an IRP_MJ_CREATE, I create and set a
> > > >> StreamContext for the file.
> > > >> 2. During the post callback for an IPR_MJ_WRITE, I acquire the context
> > > >> and
> > > >> set my bool value to true, indicating that this file was modified during
> > > >> the
> > > >>
> > > >> processing.
> > > >> 3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context
> > > >> and
> > > >> check the bool to see if this file was modified.
> > > >>
> > > >> This seems to run OK, but after a while, the process in #2 calls an OS
> > > >> crash. I finally have WinDbg running (although not optimally - I can’t
> > > >> seem
> > > >> to get symbol loading working yet), and right before the crash, I do see
> > > >> a
> > > >> bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.
> > > >>
> > > >> Here is the relevant code for the PostWriteCallback - anything obvious?
> > > >>
> > > >> FLT_POSTOP_CALLBACK_STATUS
> > > >> PostWriteCallback (
> > > >> inout PFLT_CALLBACK_DATA Data,
> > > >> in PCFLT_RELATED_OBJECTS FltObjects,
> > > >> in PVOID CompletionContext,
> > > >> in FLT_POST_OPERATION_FLAGS Flags
> > > >> )
> > > >> {
> > > >> PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
> > > >> FLT_POSTOP_CALLBACK_STATUS returnStatus =
> > > >> FLT_POSTOP_FINISHED_PROCESSING;
> > > >> NTSTATUS status;
> > > >>
> > > >> UNREFERENCED_PARAMETER( CompletionContext );
> > > >> UNREFERENCED_PARAMETER( Flags );
> > > >>
> > > >>
> > > >> if( FltObjects->FileObject == NULL )
> > > >> {
> > > >> DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
> > > >> return returnStatus;
> > > >> }
> > > >> if ( Data->IoStatus.Status != STATUS_SUCCESS )
> > > >> {
> > > >> DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
> > > >> STATUS_SUCCESS\n” );
> > > >> return returnStatus;
> > > >> }
> > > >>
> > > >> status = FltGetStreamHandleContext( FltObjects->Instance,
> > > >> FltObjects->FileObject,
> > > >> &fileContext );
> > > >>
> > > >> if (NT_SUCCESS( status )) {
> > > >> if( fileContext ) {
> > > >> fileContext->FileModified = TRUE;
> > > >> FltReleaseContext( fileContext );
> > > >> }
> > > >> }
> > > >> return returnStatus;
> > > >> }
> > > >>
> > > >> –
> > > >> Andrew Cheyne
> > > >> Senior Software Developer
> > > >> GridIron Software
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> —
> > > >> Questions? First check the IFS FAQ at
> > > >> https://www.osronline.com/article.cfm?id=17
> > > >>
> > > >> You are currently subscribed to ntfsd as: xxxxx@gridironsoftware.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@gridironsoftware.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@comcast.net
> > > 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@cox.net
> > 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@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

Alex - if this personage could evem be bothered for a moment to type “IRQL”
into Google the second thing he would get is the familiar
http://www.microsoft.com/whdc/driver/kernel/IRQL.mspx - but instead he
prefers to waste human time - and be rude with that - and you prefer to
dislike the style I choose?

wrote in message news:xxxxx@ntfsd…
Andrew,

page 7: “The Filter Manager guarantees that these callbacks will be called
at passive IRQL.”

page 22: “A minifilter can call FltGetFileNameInformation() at any point
during its IO
processing when it is executing an IRQL less than DPC.”

Quoted from
http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/FilterDriverDeveloperGuide.doc

Not that I like the style Lindon has chosen, but please, don’t ask “What is
DPC?” here, ok?

Thank you for your cooperation.

-------------- Original message --------------
From: “Lyndon J Clarke”

> Andrew
>
> Your rudeness doesnt phase me
>
> If you are just cant be bothered to discover where to read about bsics for
> yourself then you might read one of the standard basics books such as
> Viscarola and Mason. There are also some excellent courses run by OSR
> which
> can be recommended.
>
> Lyndon
>
> “Andrew Cheyne” wrote in message
> news:xxxxx@ntfsd…
> > Lyndon,
> >
> > Thanks for your help. The primary document that Microsoft provides for
> > writing a minifilter is the “Filter Driver Development Guide”. I have
> > been
> > using this in conjunction with the provided minifilter samples to
> > develop
> > the driver. Nowhere in the samples or the documentation specific to
> > minifilters does it mention IRQL.
> >
> > I’m glad that you’d RTFM’d everything, though, and can be so helpful to
> > others who are just starting out in driver development.
> >
> > Cheers,
> > Andrew
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> > Sent: May 18, 2007 10:26 AM
> > To: Windows File Systems Devs Interest List
> > Subject: Re:[ntfsd] trying to debug a crash
> >
> > Andrew
> >
> > IRQL has to be one of the most basic conecpts for drivers.RTFM.
> >
> > Lyndon
> >
> > “Andrew Cheyne” wrote in message
> > news:xxxxx@ntfsd…
> >> Lyndon - I’m not sure what you’re asking. I’m relatively new to
> ; >> MiniFilter
> >> development.
> >>
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> >> Sent: May 17, 2007 4:58 PM
> >> To: Windows File Systems Devs Interest List
> >> Subject: Re:[ntfsd] trying to debug a crash
> >>
> >> IRQL?
> >>
> >> “Andrew Cheyne” wrote in message
> >> news:xxxxx@ntfsd…
> >> I have written a fairly simple minifilter that I’m using to track opens
> >> and
> >> closes on files. When the file is closed, I want to know if the file
> >> was
> >> modified. I didn’t see anything in the information provided in
> >> IRP_MJ_CLEANUP that would tell me this (if it is there, could so meone
> >> tell
> >> me where to look?), so I decided to use a StreamContext to determine
> >> the
> >> information.
> >>
> >> So, basically, I’m doing the following:
> >>
> >> 1. During the post callback for an IRP_MJ_CREATE, I create and set a
> >> StreamContext for the file.
> >> 2. During the post callback for an IPR_MJ_WRITE, I acquire the context
> >> and
> >> set my bool value to true, indicating that this file was modified
> >> during
> >> the
> >>
> >> processing.
> >> 3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context
> >> and
> >> check the bool to see if this file was modified.
> >>
> >> This seems to run OK, but after a while, the process in #2 calls an OS
> >> crash. I finally have WinDbg running (alth ough not optimally - I can’t
> >> seem
> >> to get symbol loading working yet), and right before the crash, I do
> >> see
> >> a
> >> bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.
> >>
> >> Here is the relevant code for the PostWriteCallback - anything obvious?
> >>
> >> FLT_POSTOP_CALLBACK_STATUS
> >> PostWriteCallback (
> >> inout PFLT_CALLBACK_DATA Data,
> >> in PCFLT_RELATED_OBJECTS FltObjects,
> >> in PVOID CompletionContext,
> >> in FLT_POST_OPERATION_FLAGS Flags
> >> )
> >> {
> >> PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
> >> FLT_POSTOP_CALLBACK_STATUS returnStatus =
> >> FLT_POSTOP_FINISHED_PROCESSING;
> >> NTSTATUS status;
> >>
> >> UNREFERENCED_PARAMETER( CompletionConte xt );
> >> UNREFERENCED_PARAMETER( Flags );
> >>
> >>
> >> if( FltObjects->FileObject == NULL )
> >> {
> >> DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
> >> return returnStatus;
> >> }
> >> if ( Data->IoStatus.Status != STATUS_SUCCESS )
> >> {
> >> DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
> >> STATUS_SUCCESS\n” );
> >> return returnStatus;
> >> }
> >>
> >> status = FltGetStreamHandleContext( FltObjects->Instance,
> >> FltObjects->FileObject,
> >> &fileContext );
> >>
> >> if (NT_SUCCESS( status )) {
> >> if( fileContext ) {
> >> fileContext->FileModified = TRUE;
> >> FltReleaseContext( fileContext );
> >> }
> >> } > >> return returnStatus;
> >> }
> >>
> >> –
> >> Andrew Cheyne
> >> Senior Software Developer
> >> GridIron Software
> >>
> >>
> >>
> >>
> >> —
> >> Questions? First check the IFS FAQ at
> >> https://www.osronline.com/article.cfm?id=17
> >>
> >> You are currently subscribed to ntfsd as: xxxxx@gridironsoftware.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@gridironsoftware.com
> > To unsubscribe send a blank email to xxxxx@list s.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@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

http://www.google.co.uk/search?hl=en&q=IRQL&btnG=Google+Search&meta=

You are the .NET expert that Anton mentions, we have found you at last.

“Andrew Cheyne” wrote in message
news:xxxxx@ntfsd…
> Lyndon,
>
> Thanks for your help. The primary document that Microsoft provides for
> writing a minifilter is the “Filter Driver Development Guide”. I have been
> using this in conjunction with the provided minifilter samples to develop
> the driver. Nowhere in the samples or the documentation specific to
> minifilters does it mention IRQL.
>
> I’m glad that you’d RTFM’d everything, though, and can be so helpful to
> others who are just starting out in driver development.
>
> Cheers,
> Andrew
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: May 18, 2007 10:26 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] trying to debug a crash
>
> Andrew
>
> IRQL has to be one of the most basic conecpts for drivers.RTFM.
>
> Lyndon
>
> “Andrew Cheyne” wrote in message
> news:xxxxx@ntfsd…
>> Lyndon - I’m not sure what you’re asking. I’m relatively new to
>> MiniFilter
>> development.
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: May 17, 2007 4:58 PM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] trying to debug a crash
>>
>> IRQL?
>>
>> “Andrew Cheyne” wrote in message
>> news:xxxxx@ntfsd…
>> I have written a fairly simple minifilter that I’m using to track opens
>> and
>> closes on files. When the file is closed, I want to know if the file was
>> modified. I didn’t see anything in the information provided in
>> IRP_MJ_CLEANUP that would tell me this (if it is there, could someone
>> tell
>> me where to look?), so I decided to use a StreamContext to determine the
>> information.
>>
>> So, basically, I’m doing the following:
>>
>> 1. During the post callback for an IRP_MJ_CREATE, I create and set a
>> StreamContext for the file.
>> 2. During the post callback for an IPR_MJ_WRITE, I acquire the context
>> and
>> set my bool value to true, indicating that this file was modified during
>> the
>>
>> processing.
>> 3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context
>> and
>> check the bool to see if this file was modified.
>>
>> This seems to run OK, but after a while, the process in #2 calls an OS
>> crash. I finally have WinDbg running (although not optimally - I can’t
>> seem
>> to get symbol loading working yet), and right before the crash, I do see
>> a
>> bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.
>>
>> Here is the relevant code for the PostWriteCallback - anything obvious?
>>
>> FLT_POSTOP_CALLBACK_STATUS
>> PostWriteCallback (
>> inout PFLT_CALLBACK_DATA Data,
>> in PCFLT_RELATED_OBJECTS FltObjects,
>> in PVOID CompletionContext,
>> in FLT_POST_OPERATION_FLAGS Flags
>> )
>> {
>> PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
>> FLT_POSTOP_CALLBACK_STATUS returnStatus =
>> FLT_POSTOP_FINISHED_PROCESSING;
>> NTSTATUS status;
>>
>> UNREFERENCED_PARAMETER( CompletionContext );
>> UNREFERENCED_PARAMETER( Flags );
>>
>>
>> if( FltObjects->FileObject == NULL )
>> {
>> DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
>> return returnStatus;
>> }
>> if ( Data->IoStatus.Status != STATUS_SUCCESS )
>> {
>> DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
>> STATUS_SUCCESS\n” );
>> return returnStatus;
>> }
>>
>> status = FltGetStreamHandleContext( FltObjects->Instance,
>> FltObjects->FileObject,
>> &fileContext );
>>
>> if (NT_SUCCESS( status )) {
>> if( fileContext ) {
>> fileContext->FileModified = TRUE;
>> FltReleaseContext( fileContext );
>> }
>> }
>> return returnStatus;
>> }
>>
>> –
>> Andrew Cheyne
>> Senior Software Developer
>> GridIron Software
>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@gridironsoftware.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@gridironsoftware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

[OSR_Community_User]

Oh…
Neither of us sees each other, and everyone (me included) has made stupidest mistakes…
I understand your furor, but give him (and me, next time I say something stupid, you just wait) some slack…

You will probably agree that it’s still much better than “I have a BSOD in my driver, can you fix it for me, please”, followed by DH’s inhumanely patient questions “what was the exception?” etc.

-------------- Original message --------------
From: “Lyndon J Clarke”

> Alex - if this personage could evem be bothered for a moment to type “IRQL”
> into Google the second thing he would get is the familiar
> http://www.microsoft.com/whdc/driver/kernel/IRQL.mspx - but instead he
> prefers to waste human time - and be rude with that - and you prefer to
> dislike the style I choose?
>
> wrote in message news:xxxxx@ntfsd…
> Andrew,
>
> page 7: “The Filter Manager guarantees that these callbacks will be called
> at passive IRQL.”
>
> page 22: “A minifilter can call FltGetFileNameInformation() at any point
> during its IO
> processing when it is executing an IRQL less than DPC.”
>
> Quoted from
> http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b4
> 5/FilterDriverDeveloperGuide.doc
>
> Not that I like the style Lindon has chosen, but please, don’t ask “What is
> DPC?” here, ok?
>
> Thank you for your cooperation.
>
>
>
> -------------- Original message --------------
> From: “Lyndon J Clarke”
>
> > Andrew
> >
> > Your rudeness doesnt phase me
> >
> > If you are just cant be bothered to discover where to read about bsics for
> > yourself then you might read one of the standard basics books such as
> > Viscarola and Mason. There are also some excellent courses run by OSR
> > which
> > can be recommended.
> >
> > Lyndon
> >
> > “Andrew Cheyne” wrote in message
> > news:xxxxx@ntfsd…
> > > Lyndon,
> > >
> > > Thanks for your help. The primary document that Microsoft provides for
> > > writing a minifilter is the “Filter Driver Development Guide”. I have
> > > been
> > > using this in conjunction with the provided minifilter samples to
> > > develop
> > > the driver. Nowhere in the samples or the documentation specific to
> > > minifilters does it mention IRQL.
> > >
> > > I’m glad that you’d RTFM’d everything, though, and can be so helpful to
> > > others who are just starting out in driver development.
> > >
> > > Cheers,
> > > Andrew
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> > > Sent: May 18, 2007 10:26 AM
> > > To: Windows File Systems Devs Interest List
> > > Subject: Re:[ntfsd] trying to debug a crash
> > >
> > > Andrew
> > >
> > > IRQL has to be one of the most basic conecpts for drivers.RTFM.
> > >
> > > Lyndon
> > >
> > > “Andrew Cheyne” wrote in message
> > > news:xxxxx@ntfsd…
> > >> Lyndon - I’m not sure what you’re asking. I’m relatively new to
> > ; >> MiniFilter
> > >> development.
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: xxxxx@lists.osr.com
> > >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> > >> Sent: May 17, 2007 4:58 PM
> > >> To: Windows File Systems Devs Interest List
> > >> Subject: Re:[ntfsd] trying to debug a crash
> > >>
> > >> IRQL?
> > >>
> > >> “Andrew Cheyne” wrote in message
> > >> news:xxxxx@ntfsd…
> > >> I have written a fairly simple minifilter that I’m using to track opens
> > >> and
> > >> closes on files. When the file is closed, I want to know if the file
> > >> was
> > >> modified. I didn’t see anything in the information provided in
> > >> IRP_MJ_CLEANUP that would tell me this (if it is there, could so meone
> > >> tell
> > >> me where to look?), so I decided to use a StreamContext to determine
> > >> the
> > >> information.
> > >>
> > >> So, basically, I’m doing the following:
> > >>
> > >> 1. During the post callback for an IRP_MJ_CREATE, I create and set a
> > >> StreamContext for the file.
> > >> 2. During the post callback for an IPR_MJ_WRITE, I acquire the context
> > >> and
> > >> set my bool value to true, indicating that this file was modified
> > >> during
> > >> the
> > >>
> > >> processing.
> > >> 3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the context
> > >> and
> > >> check the bool to see if this file was modified.
> > >>
> > >> This seems to run OK, but after a while, the process in #2 calls an OS
> > >> crash. I finally have WinDbg running (alth ough not optimally - I can’t
> > >> seem
> > >> to get symbol loading working yet), and right before the crash, I do
> > >> see
> > >> a
> > >> bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.
> > >>
> > >> Here is the relevant code for the PostWriteCallback - anything obvious?
> > >>
> > >> FLT_POSTOP_CALLBACK_STATUS
> > >> PostWriteCallback (
> > >> inout PFLT_CALLBACK_DATA Data,
> > >> in PCFLT_RELATED_OBJECTS FltObjects,
> > >> in PVOID CompletionContext,
> > >> in FLT_POST_OPERATION_FLAGS Flags
> > >> )
> > >> {
> > >> PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
> > >> FLT_POSTOP_CALLBACK_STATUS returnStatus =
> > >> FLT_POSTOP_FINISHED_PROCESSING;
> > >> NTSTATUS status;
> > >>
> > >> UNREFERENCED_PARAMETER( CompletionConte xt );
> > >> UNREFERENCED_PARAMETER( Flags );
> > >>
> > >>
> > >> if( FltObjects->FileObject == NULL )
> > >> {
> > >> DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
> > >> return returnStatus;
> > >> }
> > >> if ( Data->IoStatus.Status != STATUS_SUCCESS )
> > >> {
> > >> DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
> > >> STATUS_SUCCESS\n” );
> > >> return returnStatus;
> > >> }
> > >>
> > >> status = FltGetStreamHandleContext( FltObjects->Instance,
> > >> FltObjects->FileObject,
> > >> &fileContext );
> > >>
> > >> if (NT_SUCCESS( status )) {
> > >> if( fileContext ) {
> > >> fileContext->FileModified = TRUE;
> > >> FltReleaseContext( fileContext );
> > >> }
> > >> } > >> return returnStatus;
> > >> }
> > >>
> > >> –
> > >> Andrew Cheyne
> > >> Senior Software Developer
> > >> GridIron Software
> > >>
> > >>
> > >>
> > >>
> > >> —
> > >> Questions? First check the IFS FAQ at
> > >> https://www.osronline.com/article.cfm?id=17
> > >>
> > >> You are currently subscribed to ntfsd as: xxxxx@gridironsoftware.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@gridironsoftware.com
> > > To unsubscribe send a blank email to xxxxx@list s.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@comcast.net
> > 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@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

Hello Alex

For sure we all make daft mistakes, for sure we all started somewhere
sometime … and I have been in both of these situations on this newsgroup,
and I have been grateful for the guidance I have received on this newsgroup,
and I try to give back as I can to others on this newsgroup.

I made here the daft mistake of venting frustration with the OP. It is clear
that for the OP the start is here and now and it is bad form to vent
frustration on someone in that situation. In this respect I apolgize to the
the OP, to you and the group in general.

I did however provide him with almost no doubt the absolute correct answer
to his original question.

I do not think that the OP in this case has just made a daft mistake, I
believe the OP has made an effort not to help himself to be in posession of
the most basic facts which he needs to do even the smallest amount of useful
kernel level development, and his posts indicate such a position. Let me
refer to the posts …

His code sample shows a call of FltGetStreamHandleContext in his post write
callack. This is a literal quite from the WDK page for this funtion
FltGetStreamHandleContext "Callers of FltGetStreamHandleContext must be
running at IRQL <= APC_LEVEL. ". You have provided relevant literal quotes
from the filter driver development guide document. It is proven fact that
the OP just did not in a meaningful fashion read the documentation provided
by Microsoft since to quote the OP “Nowhere in the samples or the
documentation specific to minifilters does it mention IRQL.”

To be frank I am tired of these kinds of posters and their questions but
still I tried to help the OP on this occasion; at least to point him in the
right direction. I continue to believe that his responses were
inappropriate.

Best Wishes
Lyndon

wrote in message news:xxxxx@ntfsd…
Oh…
Neither of us sees each other, and everyone (me included) has made
stupidest mistakes…
I understand your furor, but give him (and me, next time I say something
stupid, you just wait) some slack…

You will probably agree that it’s still much better than “I have a BSOD in
my driver, can you fix it for me, please”, followed by DH’s inhumanely
patient questions “what was the exception?” etc.

-------------- Original message --------------
From: “Lyndon J Clarke”

> Alex - if this personage could evem be bothered for a moment to type
> “IRQL”
> into Google the second thing he would get is the familiar
> http://www.microsoft.com/whdc/driver/kernel/IRQL.mspx - but instead he
> prefers to waste human time - and be rude with that - and you prefer to
> dislike the style I choose?
>
> wrote in message news:xxxxx@ntfsd…
> Andrew,
>
> page 7: “The Filter Manager guarantees that these callbacks will be called
> at passive IRQL.”
>
> page 22: “A minifilter can call FltGetFileNameInformation() at any point
> during its IO
> processing when it is executing an IRQL less than DPC.”
>
> Quoted from
> http://downlo
> ad.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b4
> 5/FilterDriverDeveloperGuide.doc
>
> Not that I like the style Lindon has chosen, but please, don’t ask “What
> is
> DPC?” here, ok?
>
> Thank you for your cooperation.
>
>
>
> -------------- Original message --------------
> From: “Lyndon J Clarke”
>
> > Andrew
> >
> > Your rudeness doesnt phase me
> >
> > If you are just cant be bothered to discover where to read about bsics
> > for
> > yourself then you might read one of the standard basics books such as
> > Viscarola and Mason. There are also some excellent courses run by OSR
> > which
> > can be recommended.
> >
> > Lyndon
> >
> > “Andrew Cheyne” wrote in message
> > news:xxxxx@ntfsd…
> > > Lyndon,
> > >
> > > Thanks for your help. The primary document that Microsoft provides for
> > > writing a minifilter is the “Filter Driver Development Guide”. I have
> > > been
> > > using this in conjunction with the provided minifilter samples to
> > > develop
> > > the driver. Nowhere in the samples or the documentation specific to
> > > minifilters does it mention IRQL.
> > >
> > > I’m glad that you’d RTFM’d everything, though, and can be so helpful
> > > to
> > > others who are just starting out in driver development.
> > >
> > > Cheers,
> > > Andrew
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J
> > > Clarke
> > > Sent: May 18, 2007 10:26 AM > > > To: Windows File Systems Devs
> > > Interest List
> > > Subject: Re:[ntfsd] trying to debug a crash
> > >
> > > Andrew
> > >
> > > IRQL has to be one of the most basic conecpts for drivers.RTFM.
> > >
> > > Lyndon
> > >
> > > “Andrew Cheyne” wrote in message
> > > news:xxxxx@ntfsd…
> > >> Lyndon - I’m not sure what you’re asking. I’m relatively new to
> > ; >> MiniFilter
> > >> development.
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: xxxxx@lists.osr.com
> > >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J
> > >> Clarke
> > >> Sent: May 17, 2007 4:58 PM
> > >> To: Windows File Systems Devs Interest List
> > >> Subject: Re:[ntfs d] trying to debug a crash
> > >>
> > >> IRQL?
> > >>
> > >> “Andrew Cheyne” wrote in message
> > >> news:xxxxx@ntfsd…
> > >> I have written a fairly simple minifilter that I’m using to track
> > >> opens
> > >> and
> > >> closes on files. When the file is closed, I want to know if the file
> > >> was
> > >> modified. I didn’t see anything in the information provided in
> > >> IRP_MJ_CLEANUP that would tell me this (if it is there, could so
> > >> meone
> > >> tell
> > >> me where to look?), so I decided to use a StreamContext to determine
> > >> the
> > >> information.
> > >>
> > >> So, basically, I’m doing the following:
> > >>
> > >> 1. During the post callback for an IRP_MJ_CREATE, I create and set a
> > >> StreamContext for the file.
> > >> 2. During the post callback for an IPR_MJ_WRITE, I acquire the
> > >> context
> > >> and
> > >> set my bool value to true, indicating that this file was modified
> > >> during
> > >> the
> > >>
> > >> processing.
> > >> 3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the
> > >> context
> > >> and
> > >> check the bool to see if this file was modified.
> > >>
> > >> This seems to run OK, but after a while, the process in #2 calls an
> > >> OS
> > >> crash. I finally have WinDbg running (alth ough not optimally - I
> > >> can’t
> > >> seem
> > >> to get symbol loading working yet), and right before the crash, I do
> > >> see
> > >> a
> > >> bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.
> > >>
> > >> Here is the relevant code for the PostWriteCallback - anything
> > >> obvious?
> > >>
> > >> FLT_POSTOP_CALLBACK_STATUS
> > >> PostWriteCallback (
> > >> inout PFLT_CALLBACK_DATA Data,
> > >> in PCFLT_RELATED_OBJECTS FltObjects,
> > >> in PVOID CompletionContext,
> > >> in FLT_POST_OPERATION_FLAGS Flags
> > >> )
> > >> {
> > >> PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
> > >> FLT_POSTOP_CALLBACK_STATUS returnStatus =
> > >> FLT_POSTOP_FINISHED_PROCESSING;
> > >> NTSTATUS status;
> > >>
> > >> UNREFERENCED_PARAMETER( CompletionConte xt );
> > >> UNREFERENCED_PARAMETER( Flags );
> > >>
> > >& gt;
> > >> if( FltObjects->FileObject == NULL )
> > >> {
> > >> DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
> > >> return returnStatus;
> > >> }
> > >> if ( Data->IoStatus.Status != STATUS_SUCCESS )
> > >> {
> > >> DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
> > >> STATUS_SUCCESS\n” );
> > >> return returnStatus;
> > >> }
> > >>
> > >> status = FltGetStreamHandleContext( FltObjects->Instance,
> > >> FltObjects->FileObject,
> > >> &fileContext );
> > >>
> > >> if (NT_SUCCESS( status )) {
> > >> if( fileContext ) {
> > >> fileContext->FileModified = TRUE;
> > >> FltReleaseContext( fileContext );
> > >> }
&g t; > >> } > >> return returnStatus;
> > >> }
> > >>
> > >> –
> > >> Andrew Cheyne
> > >> Senior Software Developer
> > >> GridIron Software
> > >>
> > >>
> > >>
> > >>
> > >> —
> > >> Questions? First check the IFS FAQ at
> > >> https://www.osronline.com/article.cfm?id=17
> > >>
> > >> You are currently subscribed to ntfsd as:
> > >> xxxxx@gridironsoftware.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@gridironsoftware.com
> > > To unsubscribe send a blank email to xxxxx@list
> > > s.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@comcast.net
> > 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@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

Forget it, Lyndon.
Not worth it, really. We are on the same page here.

You better answer my questions (since it’s Saturday):

1. My driver does not work. What shall I do?
2. I need a full path to the executable. How can I get it?
3. I wrote a FS filer, and it does not work with notepad, shall I change my filter or notepad instead?
4. Some say that C is better han C++ in the kernel, some say otherwise; as of now my driver is in fortran, what language shall I port it to?

That’s all for today:-)

-------------- Original message --------------
From: “Lyndon J Clarke”

> Hello Alex
>
> For sure we all make daft mistakes, for sure we all started somewhere
> sometime … and I have been in both of these situations on this newsgroup,
> and I have been grateful for the guidance I have received on this newsgroup,
> and I try to give back as I can to others on this newsgroup.
>
> I made here the daft mistake of venting frustration with the OP. It is clear
> that for the OP the start is here and now and it is bad form to vent
> frustration on someone in that situation. In this respect I apolgize to the
> the OP, to you and the group in general.
>
> I did however provide him with almost no doubt the absolute correct answer
> to his original question.
>
> I do not think that the OP in this case has just made a daft mistake, I
> believe the OP has made an effort not to help himself to be in posession of
> the most basic facts which he needs to do even the smallest amount of useful
> kernel level development, and his posts indicate such a position. Let me
> refer to the posts …
>
> His code sample shows a call of FltGetStreamHandleContext in his post write
> callack. This is a literal quite from the WDK page for this funtion
> FltGetStreamHandleContext "Callers of FltGetStreamHandleContext must be
> running at IRQL <= APC_LEVEL. ". You have provided relevant literal quotes
> from the filter driver development guide document. It is proven fact that
> the OP just did not in a meaningful fashion read the documentation provided
> by Microsoft since to quote the OP “Nowhere in the samples or the
> documentation specific to minifilters does it mention IRQL.”
>
> To be frank I am tired of these kinds of posters and their questions but
> still I tried to help the OP on this occasion; at least to point him in the
> right direction. I continue to believe that his responses were
> inappropriate.
>
> Best Wishes
> Lyndon
>
> wrote in message news:xxxxx@ntfsd…
> Oh…
> Neither of us sees each other, and everyone (me included) has made
> stupidest mistakes…
> I understand your furor, but give him (and me, next time I say something
> stupid, you just wait) some slack…
>
> You will probably agree that it’s still much better than “I have a BSOD in
> my driver, can you fix it for me, please”, followed by DH’s inhumanely
> patient questions “what was the exception?” etc.
>
>
> -------------- Original message --------------
> From: “Lyndon J Clarke”
>
> > Alex - if this personage could evem be bothered for a moment to type
> > “IRQL”
> > into Google the second thing he would get is the familiar
> > http://www.microsoft.com/whdc/driver/kernel/IRQL.mspx - but instead he
> > prefers to waste human time - and be rude with that - and you prefer to
> > dislike the style I choose?
> >
> > wrote in message news:xxxxx@ntfsd…
> > Andrew,
> >
> > page 7: “The Filter Manager guarantees that these callbacks will be called
> > at passive IRQL.”
> >
> > page 22: “A minifilter can call FltGetFileNameInformation() at any point
> > during its IO
> > processing when it is executing an IRQL less than DPC.”
> >
> > Quoted from
> > http://downlo
> > ad.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b4
> > 5/FilterDriverDeveloperGuide.doc
> >
> > Not that I like the style Lindon has chosen, but please, don’t ask “What
> > is
> > DPC?” here, ok?
> >
> > Thank you for your cooperation.
> >
> >
> >
> > -------------- Original message --------------
> > From: “Lyndon J Clarke”
> >
> > > Andrew
> > >
> > > Your rudeness doesnt phase me
> > >
> > > If you are just cant be bothered to discover where to read about bsics
> > > for
> > > yourself then you might read one of the standard basics books such as
> > > Viscarola and Mason. There are also some excellent courses run by OSR
> > > which
> > > can be recommended.
> > >
> > > Lyndon
> > >
> > > “Andrew Cheyne” wrote in message
> > > news:xxxxx@ntfsd…
> > > > Lyndon,
> > > >
> > > > Thanks for your help. The primary document that Microsoft provides for
> > > > writing a minifilter is the “Filter Driver Development Guide”. I have
> > > > been
> > > > using this in conjunction with the provided minifilter samples to
> > > > develop
> > > > the driver. Nowhere in the samples or the documentation specific to
> > > > minifilters does it mention IRQL.
> > > >
> > > > I’m glad that you’d RTFM’d everything, though, and can be so helpful
> > > > to
> > > > others who are just starting out in driver development.
> > > >
> > > > Cheers,
> > > > Andrew
> > > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J
> > > > Clarke
> > > > Sent: May 18, 2007 10:26 AM > > > To: Windows File Systems Devs
> > > > Interest List
> > > > Subject: Re:[ntfsd] trying to debug a crash
> > > >
> > > > Andrew
> > > >
> > > > IRQL has to be one of the most basic conecpts for drivers.RTFM.
> > > >
> > > > Lyndon
> > > >
> > > > “Andrew Cheyne” wrote in message
> > > > news:xxxxx@ntfsd…
> > > >> Lyndon - I’m not sure what you’re asking. I’m relatively new to
> > > ; >> MiniFilter
> > > >> development.
> > > >>
> > > >>
> > > >> -----Original Message-----
> > > >> From: xxxxx@lists.osr.com
> > > >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J
> > > >> Clarke
> > > >> Sent: May 17, 2007 4:58 PM
> > > >> To: Windows File Systems Devs Interest List
> > > >> Subject: Re:[ntfs d] trying to debug a crash
> > > >>
> > > >> IRQL?
> > > >>
> > > >> “Andrew Cheyne” wrote in message
> > > >> news:xxxxx@ntfsd…
> > > >> I have written a fairly simple minifilter that I’m using to track
> > > >> opens
> > > >> and
> > > >> closes on files. When the file is closed, I want to know if the file
> > > >> was
> > > >> modified. I didn’t see anything in the information provided in
> > > >> IRP_MJ_CLEANUP that would tell me this (if it is there, could so
> > > >> meone
> > > >> tell
> > > >> me where to look?), so I decided to use a StreamContext to determine
> > > >> the
> > > >> information.
> > > >>
> > > >> So, basically, I’m doing the following:
> > > >>
> > > >> 1. During the post callback for an IRP_MJ_CREATE, I create and set a
> > > >> StreamContext for the file.
> > > >> 2. During the post callback for an IPR_MJ_WRITE, I acquire the
> > > >> context
> > > >> and
> > > >> set my bool value to true, indicating that this file was modified
> > > >> during
> > > >> the
> > > >>
> > > >> processing.
> > > >> 3. During the pre callback for an IRP_MJ_CLEANUP, I acquire the
> > > >> context
> > > >> and
> > > >> check the bool to see if this file was modified.
> > > >>
> > > >> This seems to run OK, but after a while, the process in #2 calls an
> > > >> OS
> > > >> crash. I finally have WinDbg running (alth ough not optimally - I
> > > >> can’t
> > > >> seem
> > > >> to get symbol loading working yet), and right before the crash, I do
> > > >> see
> > > >> a
> > > >> bunch of instances where the Data->IoStatus.Status != STATUS_SUCCESS.
> > > >>
> > > >> Here is the relevant code for the PostWriteCallback - anything
> > > >> obvious?
> > > >>
> > > >> FLT_POSTOP_CALLBACK_STATUS
> > > >> PostWriteCallback (
> > > >> inout PFLT_CALLBACK_DATA Data,
> > > >> in PCFLT_RELATED_OBJECTS FltObjects,
> > > >> in PVOID CompletionContext,
> > > >> in FLT_POST_OPERATION_FLAGS Flags
> > > >> )
> > > >> {
> > > >> PT_STREAM_HANDLE_CONTEXT fileContext = NULL;
> > > >> FLT_POSTOP_CALLBACK_STATUS returnStatus =
> > > >> FLT_POSTOP_FINISHED_PROCESSING;
> > > >> NTSTATUS status;
> > > >>
> > > >> UNREFERENCED_PARAMETER( CompletionConte xt );
> > > >> UNREFERENCED_PARAMETER( Flags );
> > > >>
> > > >& gt;
> > > >> if( FltObjects->FileObject == NULL )
> > > >> {
> > > >> DbgPrint( “PostWriteCallback:: NULL FileObject?\n” );
> > > >> return returnStatus;
> > > >> }
> > > >> if ( Data->IoStatus.Status != STATUS_SUCCESS )
> > > >> {
> > > >> DbgPrint( “PostWriteCallback:: Data->IoStatus.Status !=
> > > >> STATUS_SUCCESS\n” );
> > > >> return returnStatus;
> > > >> }
> > > >>
> > > >> status = FltGetStreamHandleContext( FltObjects->Instance,
> > > >> FltObjects->FileObject,
> > > >> &fileContext );
> > > >>
> > > >> if (NT_SUCCESS( status )) {
> > > >> if( fileContext ) {
> > > >> fileContext->FileModified = TRUE;
> > > >> FltReleaseContext( fileContext );
> > > >> }
> &g t; > >> } > >> return returnStatus;
> > > >> }
> > > >>
> > > >> –
> > > >> Andrew Cheyne
> > > >> Senior Software Developer
> > > >> GridIron Software
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> —
> > > >> Questions? First check the IFS FAQ at
> > > >> https://www.osronline.com/article.cfm?id=17
> > > >>
> > > >> You are currently subscribed to ntfsd as:
> > > >> xxxxx@gridironsoftware.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@gridironsoftware.com
> > > > To unsubscribe send a blank email to xxxxx@list
> > > > s.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@comcast.net
> > > 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@comcast.net
> > 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@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com