What's problem causing minifilter unload hanging?

Hello,

My minifilter uses a communication port and contexts of instance and stream
handle. When I unload the filter using “fltmc unload myfilter”, the command
hangs until reboot the system. I cannot trace the problem. It seems all
contexts are released when unload routine is called. Any help is
appreciated.

Regards,
Shangwu

Unfortunately, the simple answer is: no, you are not releasing all object
references.

Check the documentation very carefully for all indications of when an object
must be dereferenced after it is created or referenced.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shangwu
Sent: Friday, May 06, 2005 4:54 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] What’s problem causing minifilter unload hanging?

Hello,

My minifilter uses a communication port and contexts of instance and stream
handle. When I unload the filter using “fltmc unload myfilter”, the command
hangs until reboot the system. I cannot trace the problem. It seems all
contexts are released when unload routine is called. Any help is
appreciated.

Regards,
Shangwu


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

> My minifilter uses a communication port and contexts of instance and

stream
handle. When I unload the filter using “fltmc unload myfilter”, the
command
hangs until reboot the system. I cannot trace the problem. It seems all
contexts are released when unload routine is called. Any help is
appreciated.

Try using the filter manager from the checked build, that gives you better
diagnostics if you are leaking contexts (as I suspect).

Its really important to keep on unloading your minifilter during
development, that way you find those leaking contents (and pool because
you’ll have verifier on as well, right?) as soon as you write the code which
causes the leak.

/rod

Thanks Rod. Where can I get the checked version of the filter manager?

Regards,
Shangwu

“Rod Widdowson” wrote in message news:xxxxx@ntfsd…
>> My minifilter uses a communication port and contexts of instance and
>> stream
>> handle. When I unload the filter using “fltmc unload myfilter”, the
>> command
>> hangs until reboot the system. I cannot trace the problem. It seems all
>> contexts are released when unload routine is called. Any help is
>> appreciated.
>
> Try using the filter manager from the checked build, that gives you better
> diagnostics if you are leaking contexts (as I suspect).
>
> Its really important to keep on unloading your minifilter during
> development, that way you find those leaking contents (and pool because
> you’ll have verifier on as well, right?) as soon as you write the code
> which causes the leak.
>
> /rod
>
>

Shangwu,

I would get it from the checked OS distribution kit, just like any other
checked OS component. W2K3 SP1 and WXP SP2 both are available as
checked packages, so you can obtain the filter manager component from
the appropriate version for your test environment. The DDK has a nice
article about mixing and matching checked and free components together.

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 Shangwu
Sent: Monday, May 09, 2005 12:00 PM
To: ntfsd redirect
Subject: Re:[ntfsd] What’s problem causing minifilter unload hanging?

Thanks Rod. Where can I get the checked version of the filter manager?

Regards,
Shangwu

“Rod Widdowson” wrote in message
news:xxxxx@ntfsd…
>> My minifilter uses a communication port and contexts of instance and
>> stream
>> handle. When I unload the filter using “fltmc unload myfilter”, the
>> command
>> hangs until reboot the system. I cannot trace the problem. It seems
all
>> contexts are released when unload routine is called. Any help is
>> appreciated.
>
> Try using the filter manager from the checked build, that gives you
better
> diagnostics if you are leaking contexts (as I suspect).
>
> Its really important to keep on unloading your minifilter during
> development, that way you find those leaking contents (and pool
because
> you’ll have verifier on as well, right?) as soon as you write the code

> which causes the leak.
>
> /rod
>
>


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

Tony,

Thank you for providing the information. After I replaced the filter manager
fltmgr.sys with a checked version from XP SP2 checked build, I got an error
message as below.

c:\>fltmc load myfilter

Load failed with error: 0x80070002
The system cannot find the file specified.

It was fine for the original filter manager driver. How can I fix this
problem?
I couldn’t find the DDK article you mentioned. So I directly replaced the
driver file in system32\drivers and it seems loaded without complain.

Regards,

Shangwu

“Tony Mason” wrote in message news:xxxxx@ntfsd…
Shangwu,

I would get it from the checked OS distribution kit, just like any other
checked OS component. W2K3 SP1 and WXP SP2 both are available as
checked packages, so you can obtain the filter manager component from
the appropriate version for your test environment. The DDK has a nice
article about mixing and matching checked and free components together.

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 Shangwu
Sent: Monday, May 09, 2005 12:00 PM
To: ntfsd redirect
Subject: Re:[ntfsd] What’s problem causing minifilter unload hanging?

Thanks Rod. Where can I get the checked version of the filter manager?

Regards,
Shangwu

“Rod Widdowson” wrote in message
news:xxxxx@ntfsd…
>> My minifilter uses a communication port and contexts of instance and
>> stream
>> handle. When I unload the filter using “fltmc unload myfilter”, the
>> command
>> hangs until reboot the system. I cannot trace the problem. It seems
all
>> contexts are released when unload routine is called. Any help is
>> appreciated.
>
> Try using the filter manager from the checked build, that gives you
better
> diagnostics if you are leaking contexts (as I suspect).
>
> Its really important to keep on unloading your minifilter during
> development, that way you find those leaking contents (and pool
because
> you’ll have verifier on as well, right?) as soon as you write the code

> which causes the leak.
>
> /rod
>
>


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

I found the following code causing the unload problem. Please adevise me if
something is wrong in a minifilter context. -Thanks.

VOID MfSetFileAllocation(PFILE_OBJECT FileObject,
PLARGE_INTEGER AllocationSize, PIO_STATUS_BLOCK IoStatusBlock)
{
PIRP irp;
PDEVICE_OBJECT fsdDevice = IoGetRelatedDeviceObject(FileObject);
KEVENT event;
PIO_STACK_LOCATION ioStackLocation;

// Allocate an irp for this request.
irp = IoAllocateIrp(fsdDevice->StackSize, FALSE);
if (NULL == irp)
{
IoStatusBlock->Status = STATUS_INSUFFICIENT_RESOURCES;
IoStatusBlock->Information = 0;
return;
}

irp->AssociatedIrp.SystemBuffer = AllocationSize;
irp->UserEvent = &event;
irp->UserIosb = IoStatusBlock;

irp->Tail.Overlay.Thread = PsGetCurrentThread();
irp->Tail.Overlay.OriginalFileObject = FileObject;
irp->RequestorMode = KernelMode;

// Initialize the event
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

// Set up the I/O stack location.
ioStackLocation = IoGetNextIrpStackLocation(irp);

ioStackLocation->MajorFunction = IRP_MJ_SET_INFORMATION;
ioStackLocation->DeviceObject = fsdDevice;
ioStackLocation->FileObject = FileObject;

ioStackLocation->Parameters.SetFile.Length = sizeof(LARGE_INTEGER);
ioStackLocation->Parameters.SetFile.FileInformationClass =
FileAllocationInformation;

ioStackLocation->Parameters.SetFile.FileObject = 0;
ioStackLocation->Parameters.SetFile.AdvanceOnly = FALSE;

// Set the completion routine.
IoSetCompletionRoutine(irp, MfIoCompletion, IoStatusBlock,
TRUE, TRUE, TRUE);
// Send it to the FSD
IoCallDriver(fsdDevice, irp);

// Wait for the I/O
KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, 0);
}

NTSTATUS MfIoCompletion(PDEVICE_OBJECT DeviceObject, PIRP Irp, PVOID
Context)
{
PIO_STATUS_BLOCK IoStatusBlock = (PIO_STATUS_BLOCK)Context;

// Copy the status information
IoStatusBlock->Status = Irp->IoStatus.Status;
IoStatusBlock->Information = Irp->IoStatus.Information;

// Free the IRP
IoFreeIrp(Irp);

KeSetEvent(Irp->UserEvent, 0, FALSE);

return STATUS_MORE_PROCESSING_REQUIRED;
}

“Shangwu” wrote in message news:xxxxx@ntfsd…
> Tony,
>
> Thank you for providing the information. After I replaced the filter
> manager fltmgr.sys with a checked version from XP SP2 checked build, I got
> an error message as below.
>
> c:>fltmc load myfilter
>
> Load failed with error: 0x80070002
> The system cannot find the file specified.
>
> It was fine for the original filter manager driver. How can I fix this
> problem?
> I couldn’t find the DDK article you mentioned. So I directly replaced the
> driver file in system32\drivers and it seems loaded without complain.
>
> Regards,
>
> Shangwu
>
>
> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> Shangwu,
>
> I would get it from the checked OS distribution kit, just like any other
> checked OS component. W2K3 SP1 and WXP SP2 both are available as
> checked packages, so you can obtain the filter manager component from
> the appropriate version for your test environment. The DDK has a nice
> article about mixing and matching checked and free components together.
>
> 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 Shangwu
> Sent: Monday, May 09, 2005 12:00 PM
> To: ntfsd redirect
> Subject: Re:[ntfsd] What’s problem causing minifilter unload hanging?
>
> Thanks Rod. Where can I get the checked version of the filter manager?
>
> Regards,
> Shangwu
>
> “Rod Widdowson” wrote in message
> news:xxxxx@ntfsd…
>>> My minifilter uses a communication port and contexts of instance and
>>> stream
>>> handle. When I unload the filter using “fltmc unload myfilter”, the
>>> command
>>> hangs until reboot the system. I cannot trace the problem. It seems
> all
>>> contexts are released when unload routine is called. Any help is
>>> appreciated.
>>
>> Try using the filter manager from the checked build, that gives you
> better
>> diagnostics if you are leaking contexts (as I suspect).
>>
>> Its really important to keep on unloading your minifilter during
>> development, that way you find those leaking contents (and pool
> because
>> you’ll have verifier on as well, right?) as soon as you write the code
>
>> which causes the leak.
>>
>> /rod
>>
>>
>
>
>
> —
> 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
>
>
>

A few things I see wrong. Others may see more:

  1. Do not set Irp->OriginalFileObject. Ain’t your field to mess with.
  2. Your completion routine accesses the Irp after freeing it.
  3. Why are you doing Irp based I/O in a minifilter? You should use
    FltSetInformationFile.
  4. Your completion routine deletes the Irp, however, by using
    IoGetRelatedDeviceObject, you have sent it to the top of the filesystem
    stack. Filters layered above you (including Filter Manager) may have set a
    completion routine for the Irp. The Irp is now lost from their perspective.
  • Dan.

At 03:14 PM 5/10/2005 -0400, you wrote:

I found the following code causing the unload problem. Please adevise me if
something is wrong in a minifilter context. -Thanks.

VOID MfSetFileAllocation(PFILE_OBJECT FileObject,
PLARGE_INTEGER AllocationSize, PIO_STATUS_BLOCK IoStatusBlock)
{
PIRP irp;
PDEVICE_OBJECT fsdDevice = IoGetRelatedDeviceObject(FileObject);
KEVENT event;
PIO_STACK_LOCATION ioStackLocation;

// Allocate an irp for this request.
irp = IoAllocateIrp(fsdDevice->StackSize, FALSE);
if (NULL == irp)
{
IoStatusBlock->Status = STATUS_INSUFFICIENT_RESOURCES;
IoStatusBlock->Information = 0;
return;
}

irp->AssociatedIrp.SystemBuffer = AllocationSize;
irp->UserEvent = &event;
irp->UserIosb = IoStatusBlock;

irp->Tail.Overlay.Thread = PsGetCurrentThread();
irp->Tail.Overlay.OriginalFileObject = FileObject;
irp->RequestorMode = KernelMode;

// Initialize the event
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

// Set up the I/O stack location.
ioStackLocation = IoGetNextIrpStackLocation(irp);

ioStackLocation->MajorFunction = IRP_MJ_SET_INFORMATION;
ioStackLocation->DeviceObject = fsdDevice;
ioStackLocation->FileObject = FileObject;

ioStackLocation->Parameters.SetFile.Length = sizeof(LARGE_INTEGER);
ioStackLocation->Parameters.SetFile.FileInformationClass =
FileAllocationInformation;

ioStackLocation->Parameters.SetFile.FileObject = 0;
ioStackLocation->Parameters.SetFile.AdvanceOnly = FALSE;

// Set the completion routine.
IoSetCompletionRoutine(irp, MfIoCompletion, IoStatusBlock,
TRUE, TRUE, TRUE);
// Send it to the FSD
IoCallDriver(fsdDevice, irp);

// Wait for the I/O
KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, 0);
}

NTSTATUS MfIoCompletion(PDEVICE_OBJECT DeviceObject, PIRP Irp, PVOID
Context)
{
PIO_STATUS_BLOCK IoStatusBlock = (PIO_STATUS_BLOCK)Context;

// Copy the status information
IoStatusBlock->Status = Irp->IoStatus.Status;
IoStatusBlock->Information = Irp->IoStatus.Information;

// Free the IRP
IoFreeIrp(Irp);

KeSetEvent(Irp->UserEvent, 0, FALSE);

return STATUS_MORE_PROCESSING_REQUIRED;
}

“Shangwu” wrote in message news:xxxxx@ntfsd…
> > Tony,
> >
> > Thank you for providing the information. After I replaced the filter
> > manager fltmgr.sys with a checked version from XP SP2 checked build, I got
> > an error message as below.
> >
> > c:>fltmc load myfilter
> >
> > Load failed with error: 0x80070002
> > The system cannot find the file specified.
> >
> > It was fine for the original filter manager driver. How can I fix this
> > problem?
> > I couldn’t find the DDK article you mentioned. So I directly replaced the
> > driver file in system32\drivers and it seems loaded without complain.
> >
> > Regards,
> >
> > Shangwu
> >
> >
> > “Tony Mason” wrote in message news:xxxxx@ntfsd…
> > Shangwu,
> >
> > I would get it from the checked OS distribution kit, just like any other
> > checked OS component. W2K3 SP1 and WXP SP2 both are available as
> > checked packages, so you can obtain the filter manager component from
> > the appropriate version for your test environment. The DDK has a nice
> > article about mixing and matching checked and free components together.
> >
> > 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 Shangwu
> > Sent: Monday, May 09, 2005 12:00 PM
> > To: ntfsd redirect
> > Subject: Re:[ntfsd] What’s problem causing minifilter unload hanging?
> >
> > Thanks Rod. Where can I get the checked version of the filter manager?
> >
> > Regards,
> > Shangwu
> >
> > “Rod Widdowson” wrote in message
> > news:xxxxx@ntfsd…
> >>> My minifilter uses a communication port and contexts of instance and
> >>> stream
> >>> handle. When I unload the filter using “fltmc unload myfilter”, the
> >>> command
> >>> hangs until reboot the system. I cannot trace the problem. It seems
> > all
> >>> contexts are released when unload routine is called. Any help is
> >>> appreciated.
> >>
> >> Try using the filter manager from the checked build, that gives you
> > better
> >> diagnostics if you are leaking contexts (as I suspect).
> >>
> >> Its really important to keep on unloading your minifilter during
> >> development, that way you find those leaking contents (and pool
> > because
> >> you’ll have verifier on as well, right?) as soon as you write the code
> >
> >> which causes the leak.
> >>
> >> /rod
> >>
> >>
> >
> >
> >
> > —
> > 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@privtek.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com

Actually, my 4th point is wrong, since your completion routine will be last
to execute. I was thinking about where your driver was in the filesystem
stack instead of where your stack location was for this particular I/O.

  • Dan.

At 03:14 PM 5/10/2005 -0400, you wrote:

I found the following code causing the unload problem. Please adevise me if
something is wrong in a minifilter context. -Thanks.

VOID MfSetFileAllocation(PFILE_OBJECT FileObject,
PLARGE_INTEGER AllocationSize, PIO_STATUS_BLOCK IoStatusBlock)
{
PIRP irp;
PDEVICE_OBJECT fsdDevice = IoGetRelatedDeviceObject(FileObject);
KEVENT event;
PIO_STACK_LOCATION ioStackLocation;

// Allocate an irp for this request.
irp = IoAllocateIrp(fsdDevice->StackSize, FALSE);
if (NULL == irp)
{
IoStatusBlock->Status = STATUS_INSUFFICIENT_RESOURCES;
IoStatusBlock->Information = 0;
return;
}

irp->AssociatedIrp.SystemBuffer = AllocationSize;
irp->UserEvent = &event;
irp->UserIosb = IoStatusBlock;

irp->Tail.Overlay.Thread = PsGetCurrentThread();
irp->Tail.Overlay.OriginalFileObject = FileObject;
irp->RequestorMode = KernelMode;

// Initialize the event
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

// Set up the I/O stack location.
ioStackLocation = IoGetNextIrpStackLocation(irp);

ioStackLocation->MajorFunction = IRP_MJ_SET_INFORMATION;
ioStackLocation->DeviceObject = fsdDevice;
ioStackLocation->FileObject = FileObject;

ioStackLocation->Parameters.SetFile.Length = sizeof(LARGE_INTEGER);
ioStackLocation->Parameters.SetFile.FileInformationClass =
FileAllocationInformation;

ioStackLocation->Parameters.SetFile.FileObject = 0;
ioStackLocation->Parameters.SetFile.AdvanceOnly = FALSE;

// Set the completion routine.
IoSetCompletionRoutine(irp, MfIoCompletion, IoStatusBlock,
TRUE, TRUE, TRUE);
// Send it to the FSD
IoCallDriver(fsdDevice, irp);

// Wait for the I/O
KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, 0);
}

NTSTATUS MfIoCompletion(PDEVICE_OBJECT DeviceObject, PIRP Irp, PVOID
Context)
{
PIO_STATUS_BLOCK IoStatusBlock = (PIO_STATUS_BLOCK)Context;

// Copy the status information
IoStatusBlock->Status = Irp->IoStatus.Status;
IoStatusBlock->Information = Irp->IoStatus.Information;

// Free the IRP
IoFreeIrp(Irp);

KeSetEvent(Irp->UserEvent, 0, FALSE);

return STATUS_MORE_PROCESSING_REQUIRED;
}

“Shangwu” wrote in message news:xxxxx@ntfsd…
> > Tony,
> >
> > Thank you for providing the information. After I replaced the filter
> > manager fltmgr.sys with a checked version from XP SP2 checked build, I got
> > an error message as below.
> >
> > c:>fltmc load myfilter
> >
> > Load failed with error: 0x80070002
> > The system cannot find the file specified.
> >
> > It was fine for the original filter manager driver. How can I fix this
> > problem?
> > I couldn’t find the DDK article you mentioned. So I directly replaced the
> > driver file in system32\drivers and it seems loaded without complain.
> >
> > Regards,
> >
> > Shangwu
> >
> >
> > “Tony Mason” wrote in message news:xxxxx@ntfsd…
> > Shangwu,
> >
> > I would get it from the checked OS distribution kit, just like any other
> > checked OS component. W2K3 SP1 and WXP SP2 both are available as
> > checked packages, so you can obtain the filter manager component from
> > the appropriate version for your test environment. The DDK has a nice
> > article about mixing and matching checked and free components together.
> >
> > 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 Shangwu
> > Sent: Monday, May 09, 2005 12:00 PM
> > To: ntfsd redirect
> > Subject: Re:[ntfsd] What’s problem causing minifilter unload hanging?
> >
> > Thanks Rod. Where can I get the checked version of the filter manager?
> >
> > Regards,
> > Shangwu
> >
> > “Rod Widdowson” wrote in message
> > news:xxxxx@ntfsd…
> >>> My minifilter uses a communication port and contexts of instance and
> >>> stream
> >>> handle. When I unload the filter using “fltmc unload myfilter”, the
> >>> command
> >>> hangs until reboot the system. I cannot trace the problem. It seems
> > all
> >>> contexts are released when unload routine is called. Any help is
> >>> appreciated.
> >>
> >> Try using the filter manager from the checked build, that gives you
> > better
> >> diagnostics if you are leaking contexts (as I suspect).
> >>
> >> Its really important to keep on unloading your minifilter during
> >> development, that way you find those leaking contents (and pool
> > because
> >> you’ll have verifier on as well, right?) as soon as you write the code
> >
> >> which causes the leak.
> >>
> >> /rod
> >>
> >>
> >
> >
> >
> > —
> > 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@privtek.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com

Dan,

Thank you for the information. Even I changed the code according to your
suggestion, the unload still hangs. The reason I use IRP based I/O is that
it should be more efficient than call functions. Later I’ll use functions if
this problem cannot be overcome.

Regards,

Shangwu

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>A few things I see wrong. Others may see more:
>
> 1) Do not set Irp->OriginalFileObject. Ain’t your field to mess with.
> 2) Your completion routine accesses the Irp after freeing it.
> 3) Why are you doing Irp based I/O in a minifilter? You should use
> FltSetInformationFile.
> 4) Your completion routine deletes the Irp, however, by using
> IoGetRelatedDeviceObject, you have sent it to the top of the filesystem
> stack. Filters layered above you (including Filter Manager) may have set
> a completion routine for the Irp. The Irp is now lost from their
> perspective.
>
> - Dan.
>
> At 03:14 PM 5/10/2005 -0400, you wrote:
>>I found the following code causing the unload problem. Please adevise me
>>if
>>something is wrong in a minifilter context. -Thanks.
>>
>>VOID MfSetFileAllocation(PFILE_OBJECT FileObject,
>> PLARGE_INTEGER AllocationSize, PIO_STATUS_BLOCK IoStatusBlock)
>>{
>> PIRP irp;
>> PDEVICE_OBJECT fsdDevice = IoGetRelatedDeviceObject(FileObject);
>> KEVENT event;
>> PIO_STACK_LOCATION ioStackLocation;
>>
>> // Allocate an irp for this request.
>> irp = IoAllocateIrp(fsdDevice->StackSize, FALSE);
>> if (NULL == irp)
>> {
>> IoStatusBlock->Status = STATUS_INSUFFICIENT_RESOURCES;
>> IoStatusBlock->Information = 0;
>> return;
>> }
>>
>> irp->AssociatedIrp.SystemBuffer = AllocationSize;
>> irp->UserEvent = &event;
>> irp->UserIosb = IoStatusBlock;
>>
>> irp->Tail.Overlay.Thread = PsGetCurrentThread();
>> irp->Tail.Overlay.OriginalFileObject = FileObject;
>> irp->RequestorMode = KernelMode;
>>
>> // Initialize the event
>> KeInitializeEvent(&event, SynchronizationEvent, FALSE);
>>
>> // Set up the I/O stack location.
>> ioStackLocation = IoGetNextIrpStackLocation(irp);
>>
>> ioStackLocation->MajorFunction = IRP_MJ_SET_INFORMATION;
>> ioStackLocation->DeviceObject = fsdDevice;
>> ioStackLocation->FileObject = FileObject;
>>
>> ioStackLocation->Parameters.SetFile.Length = sizeof(LARGE_INTEGER);
>> ioStackLocation->Parameters.SetFile.FileInformationClass =
>>FileAllocationInformation;
>>
>> ioStackLocation->Parameters.SetFile.FileObject = 0;
>> ioStackLocation->Parameters.SetFile.AdvanceOnly = FALSE;
>>
>> // Set the completion routine.
>> IoSetCompletionRoutine(irp, MfIoCompletion, IoStatusBlock,
>> TRUE, TRUE, TRUE);
>> // Send it to the FSD
>> IoCallDriver(fsdDevice, irp);
>>
>> // Wait for the I/O
>> KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, 0);
>>}
>>
>>NTSTATUS MfIoCompletion(PDEVICE_OBJECT DeviceObject, PIRP Irp, PVOID
>>Context)
>>{
>> PIO_STATUS_BLOCK IoStatusBlock = (PIO_STATUS_BLOCK)Context;
>>
>> // Copy the status information
>> IoStatusBlock->Status = Irp->IoStatus.Status;
>> IoStatusBlock->Information = Irp->IoStatus.Information;
>>
>> // Free the IRP
>> IoFreeIrp(Irp);
>>
>> KeSetEvent(Irp->UserEvent, 0, FALSE);
>>
>> return STATUS_MORE_PROCESSING_REQUIRED;
>>}
>>
>>“Shangwu” wrote in message news:xxxxx@ntfsd…
>> > Tony,
>> >
>> > Thank you for providing the information. After I replaced the filter
>> > manager fltmgr.sys with a checked version from XP SP2 checked build, I
>> > got
>> > an error message as below.
>> >
>> > c:>fltmc load myfilter
>> >
>> > Load failed with error: 0x80070002
>> > The system cannot find the file specified.
>> >
>> > It was fine for the original filter manager driver. How can I fix this
>> > problem?
>> > I couldn’t find the DDK article you mentioned. So I directly replaced
>> > the
>> > driver file in system32\drivers and it seems loaded without complain.
>> >
>> > Regards,
>> >
>> > Shangwu
>> >
>> >
>> > “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> > Shangwu,
>> >
>> > I would get it from the checked OS distribution kit, just like any
>> > other
>> > checked OS component. W2K3 SP1 and WXP SP2 both are available as
>> > checked packages, so you can obtain the filter manager component from
>> > the appropriate version for your test environment. The DDK has a nice
>> > article about mixing and matching checked and free components together.
>> >
>> > 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 Shangwu
>> > Sent: Monday, May 09, 2005 12:00 PM
>> > To: ntfsd redirect
>> > Subject: Re:[ntfsd] What’s problem causing minifilter unload hanging?
>> >
>> > Thanks Rod. Where can I get the checked version of the filter manager?
>> >
>> > Regards,
>> > Shangwu
>> >
>> > “Rod Widdowson” wrote in message
>> > news:xxxxx@ntfsd…
>> >>> My minifilter uses a communication port and contexts of instance and
>> >>> stream
>> >>> handle. When I unload the filter using “fltmc unload myfilter”, the
>> >>> command
>> >>> hangs until reboot the system. I cannot trace the problem. It seems
>> > all
>> >>> contexts are released when unload routine is called. Any help is
>> >>> appreciated.
>> >>
>> >> Try using the filter manager from the checked build, that gives you
>> > better
>> >> diagnostics if you are leaking contexts (as I suspect).
>> >>
>> >> Its really important to keep on unloading your minifilter during
>> >> development, that way you find those leaking contents (and pool
>> > because
>> >> you’ll have verifier on as well, right?) as soon as you write the code
>> >
>> >> which causes the leak.
>> >>
>> >> /rod
>> >>
>> >>
>> >
>> >
>> >
>> > —
>> > 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@privtek.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

>The reason I use IRP based I/O is that it should be more efficient than
call functions.

I doubt that it’s much more efficient than calling the Filter Manager
routines, especially considering that there may be filters above you doing
substantial processing.

The reason most of us rolled our own Irps in legacy filters was not
efficiency, it was to be able to send the Irp down without re-entering the
file system stack at the top. That’s why Filter Manager provides APIs to
do the same thing.

What does your minifilter do when it receives the callback generated by
your I/O? That could be what is causing your unload hang.

  • Dan.

At 04:08 PM 5/10/2005 -0400, you wrote:

Dan,

Thank you for the information. Even I changed the code according to your
suggestion, the unload still hangs. The reason I use IRP based I/O is that
it should be more efficient than call functions. Later I’ll use functions if
this problem cannot be overcome.

Regards,

Shangwu

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> >A few things I see wrong. Others may see more:
> >
> > 1) Do not set Irp->OriginalFileObject. Ain’t your field to mess with.
> > 2) Your completion routine accesses the Irp after freeing it.
> > 3) Why are you doing Irp based I/O in a minifilter? You should use
> > FltSetInformationFile.
> > 4) Your completion routine deletes the Irp, however, by using
> > IoGetRelatedDeviceObject, you have sent it to the top of the filesystem
> > stack. Filters layered above you (including Filter Manager) may have set
> > a completion routine for the Irp. The Irp is now lost from their
> > perspective.
> >
> > - Dan.
> >
> > At 03:14 PM 5/10/2005 -0400, you wrote:
> >>I found the following code causing the unload problem. Please adevise me
> >>if
> >>something is wrong in a minifilter context. -Thanks.
> >>
> >>VOID MfSetFileAllocation(PFILE_OBJECT FileObject,
> >> PLARGE_INTEGER AllocationSize, PIO_STATUS_BLOCK IoStatusBlock)
> >>{
> >> PIRP irp;
> >> PDEVICE_OBJECT fsdDevice = IoGetRelatedDeviceObject(FileObject);
> >> KEVENT event;
> >> PIO_STACK_LOCATION ioStackLocation;
> >>
> >> // Allocate an irp for this request.
> >> irp = IoAllocateIrp(fsdDevice->StackSize, FALSE);
> >> if (NULL == irp)
> >> {
> >> IoStatusBlock->Status = STATUS_INSUFFICIENT_RESOURCES;
> >> IoStatusBlock->Information = 0;
> >> return;
> >> }
> >>
> >> irp->AssociatedIrp.SystemBuffer = AllocationSize;
> >> irp->UserEvent = &event;
> >> irp->UserIosb = IoStatusBlock;
> >>
> >> irp->Tail.Overlay.Thread = PsGetCurrentThread();
> >> irp->Tail.Overlay.OriginalFileObject = FileObject;
> >> irp->RequestorMode = KernelMode;
> >>
> >> // Initialize the event
> >> KeInitializeEvent(&event, SynchronizationEvent, FALSE);
> >>
> >> // Set up the I/O stack location.
> >> ioStackLocation = IoGetNextIrpStackLocation(irp);
> >>
> >> ioStackLocation->MajorFunction = IRP_MJ_SET_INFORMATION;
> >> ioStackLocation->DeviceObject = fsdDevice;
> >> ioStackLocation->FileObject = FileObject;
> >>
> >> ioStackLocation->Parameters.SetFile.Length = sizeof(LARGE_INTEGER);
> >> ioStackLocation->Parameters.SetFile.FileInformationClass =
> >>FileAllocationInformation;
> >>
> >> ioStackLocation->Parameters.SetFile.FileObject = 0;
> >> ioStackLocation->Parameters.SetFile.AdvanceOnly = FALSE;
> >>
> >> // Set the completion routine.
> >> IoSetCompletionRoutine(irp, MfIoCompletion, IoStatusBlock,
> >> TRUE, TRUE, TRUE);
> >> // Send it to the FSD
> >> IoCallDriver(fsdDevice, irp);
> >>
> >> // Wait for the I/O
> >> KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, 0);
> >>}
> >>
> >>NTSTATUS MfIoCompletion(PDEVICE_OBJECT DeviceObject, PIRP Irp, PVOID
> >>Context)
> >>{
> >> PIO_STATUS_BLOCK IoStatusBlock = (PIO_STATUS_BLOCK)Context;
> >>
> >> // Copy the status information
> >> IoStatusBlock->Status = Irp->IoStatus.Status;
> >> IoStatusBlock->Information = Irp->IoStatus.Information;
> >>
> >> // Free the IRP
> >> IoFreeIrp(Irp);
> >>
> >> KeSetEvent(Irp->UserEvent, 0, FALSE);
> >>
> >> return STATUS_MORE_PROCESSING_REQUIRED;
> >>}
> >>
> >>“Shangwu” wrote in message news:xxxxx@ntfsd…
> >> > Tony,
> >> >
> >> > Thank you for providing the information. After I replaced the filter
> >> > manager fltmgr.sys with a checked version from XP SP2 checked build, I
> >> > got
> >> > an error message as below.
> >> >
> >> > c:>fltmc load myfilter
> >> >
> >> > Load failed with error: 0x80070002
> >> > The system cannot find the file specified.
> >> >
> >> > It was fine for the original filter manager driver. How can I fix this
> >> > problem?
> >> > I couldn’t find the DDK article you mentioned. So I directly replaced
> >> > the
> >> > driver file in system32\drivers and it seems loaded without complain.
> >> >
> >> > Regards,
> >> >
> >> > Shangwu
> >> >
> >> >
> >> > “Tony Mason” wrote in message news:xxxxx@ntfsd…
> >> > Shangwu,
> >> >
> >> > I would get it from the checked OS distribution kit, just like any
> >> > other
> >> > checked OS component. W2K3 SP1 and WXP SP2 both are available as
> >> > checked packages, so you can obtain the filter manager component from
> >> > the appropriate version for your test environment. The DDK has a nice
> >> > article about mixing and matching checked and free components together.
> >> >
> >> > 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 Shangwu
> >> > Sent: Monday, May 09, 2005 12:00 PM
> >> > To: ntfsd redirect
> >> > Subject: Re:[ntfsd] What’s problem causing minifilter unload hanging?
> >> >
> >> > Thanks Rod. Where can I get the checked version of the filter manager?
> >> >
> >> > Regards,
> >> > Shangwu
> >> >
> >> > “Rod Widdowson” wrote in message
> >> > news:xxxxx@ntfsd…
> >> >>> My minifilter uses a communication port and contexts of instance and
> >> >>> stream
> >> >>> handle. When I unload the filter using “fltmc unload myfilter”, the
> >> >>> command
> >> >>> hangs until reboot the system. I cannot trace the problem. It seems
> >> > all
> >> >>> contexts are released when unload routine is called. Any help is
> >> >>> appreciated.
> >> >>
> >> >> Try using the filter manager from the checked build, that gives you
> >> > better
> >> >> diagnostics if you are leaking contexts (as I suspect).
> >> >>
> >> >> Its really important to keep on unloading your minifilter during
> >> >> development, that way you find those leaking contents (and pool
> >> > because
> >> >> you’ll have verifier on as well, right?) as soon as you write the code
> >> >
> >> >> which causes the leak.
> >> >>
> >> >> /rod
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > —
> >> > 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@privtek.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@privtek.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com

Dan,

Thank you again. My callback routine to issue IRP based I/O is a pre-read
routine. If I remove the IRP based I/O, everything is fine.

Regards,

Shangwu

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> >The reason I use IRP based I/O is that it should be more efficient than
> call functions.
>
> I doubt that it’s much more efficient than calling the Filter Manager
> routines, especially considering that there may be filters above you doing
> substantial processing.
>
> The reason most of us rolled our own Irps in legacy filters was not
> efficiency, it was to be able to send the Irp down without re-entering the
> file system stack at the top. That’s why Filter Manager provides APIs to
> do the same thing.
>
> What does your minifilter do when it receives the callback generated by
> your I/O? That could be what is causing your unload hang.
>
> - Dan.
>
> At 04:08 PM 5/10/2005 -0400, you wrote:
>>Dan,
>>
>>Thank you for the information. Even I changed the code according to your
>>suggestion, the unload still hangs. The reason I use IRP based I/O is that
>>it should be more efficient than call functions. Later I’ll use functions
>>if
>>this problem cannot be overcome.
>>
>>Regards,
>>
>>Shangwu
>>
>>“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>> >A few things I see wrong. Others may see more:
>> >
>> > 1) Do not set Irp->OriginalFileObject. Ain’t your field to mess with.
>> > 2) Your completion routine accesses the Irp after freeing it.
>> > 3) Why are you doing Irp based I/O in a minifilter? You should use
>> > FltSetInformationFile.
>> > 4) Your completion routine deletes the Irp, however, by using
>> > IoGetRelatedDeviceObject, you have sent it to the top of the filesystem
>> > stack. Filters layered above you (including Filter Manager) may have
>> > set
>> > a completion routine for the Irp. The Irp is now lost from their
>> > perspective.
>> >
>> > - Dan.
>> >
>> > At 03:14 PM 5/10/2005 -0400, you wrote:
>> >>I found the following code causing the unload problem. Please adevise
>> >>me
>> >>if
>> >>something is wrong in a minifilter context. -Thanks.
>> >>
>> >>VOID MfSetFileAllocation(PFILE_OBJECT FileObject,
>> >> PLARGE_INTEGER AllocationSize, PIO_STATUS_BLOCK IoStatusBlock)
>> >>{
>> >> PIRP irp;
>> >> PDEVICE_OBJECT fsdDevice = IoGetRelatedDeviceObject(FileObject);
>> >> KEVENT event;
>> >> PIO_STACK_LOCATION ioStackLocation;
>> >>
>> >> // Allocate an irp for this request.
>> >> irp = IoAllocateIrp(fsdDevice->StackSize, FALSE);
>> >> if (NULL == irp)
>> >> {
>> >> IoStatusBlock->Status = STATUS_INSUFFICIENT_RESOURCES;
>> >> IoStatusBlock->Information = 0;
>> >> return;
>> >> }
>> >>
>> >> irp->AssociatedIrp.SystemBuffer = AllocationSize;
>> >> irp->UserEvent = &event;
>> >> irp->UserIosb = IoStatusBlock;
>> >>
>> >> irp->Tail.Overlay.Thread = PsGetCurrentThread();
>> >> irp->Tail.Overlay.OriginalFileObject = FileObject;
>> >> irp->RequestorMode = KernelMode;
>> >>
>> >> // Initialize the event
>> >> KeInitializeEvent(&event, SynchronizationEvent, FALSE);
>> >>
>> >> // Set up the I/O stack location.
>> >> ioStackLocation = IoGetNextIrpStackLocation(irp);
>> >>
>> >> ioStackLocation->MajorFunction = IRP_MJ_SET_INFORMATION;
>> >> ioStackLocation->DeviceObject = fsdDevice;
>> >> ioStackLocation->FileObject = FileObject;
>> >>
>> >> ioStackLocation->Parameters.SetFile.Length =
>> >> sizeof(LARGE_INTEGER);
>> >> ioStackLocation->Parameters.SetFile.FileInformationClass =
>> >>FileAllocationInformation;
>> >>
>> >> ioStackLocation->Parameters.SetFile.FileObject = 0;
>> >> ioStackLocation->Parameters.SetFile.AdvanceOnly = FALSE;
>> >>
>> >> // Set the completion routine.
>> >> IoSetCompletionRoutine(irp, MfIoCompletion, IoStatusBlock,
>> >> TRUE, TRUE, TRUE);
>> >> // Send it to the FSD
>> >> IoCallDriver(fsdDevice, irp);
>> >>
>> >> // Wait for the I/O
>> >> KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, 0);
>> >>}
>> >>
>> >>NTSTATUS MfIoCompletion(PDEVICE_OBJECT DeviceObject, PIRP Irp, PVOID
>> >>Context)
>> >>{
>> >> PIO_STATUS_BLOCK IoStatusBlock = (PIO_STATUS_BLOCK)Context;
>> >>
>> >> // Copy the status information
>> >> IoStatusBlock->Status = Irp->IoStatus.Status;
>> >> IoStatusBlock->Information = Irp->IoStatus.Information;
>> >>
>> >> // Free the IRP
>> >> IoFreeIrp(Irp);
>> >>
>> >> KeSetEvent(Irp->UserEvent, 0, FALSE);
>> >>
>> >> return STATUS_MORE_PROCESSING_REQUIRED;
>> >>}
>> >>
>> >>“Shangwu” wrote in message news:xxxxx@ntfsd…
>> >> > Tony,
>> >> >
>> >> > Thank you for providing the information. After I replaced the filter
>> >> > manager fltmgr.sys with a checked version from XP SP2 checked build,
>> >> > I
>> >> > got
>> >> > an error message as below.
>> >> >
>> >> > c:>fltmc load myfilter
>> >> >
>> >> > Load failed with error: 0x80070002
>> >> > The system cannot find the file specified.
>> >> >
>> >> > It was fine for the original filter manager driver. How can I fix
>> >> > this
>> >> > problem?
>> >> > I couldn’t find the DDK article you mentioned. So I directly
>> >> > replaced
>> >> > the
>> >> > driver file in system32\drivers and it seems loaded without
>> >> > complain.
>> >> >
>> >> > Regards,
>> >> >
>> >> > Shangwu
>> >> >
>> >> >
>> >> > “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> >> > Shangwu,
>> >> >
>> >> > I would get it from the checked OS distribution kit, just like any
>> >> > other
>> >> > checked OS component. W2K3 SP1 and WXP SP2 both are available as
>> >> > checked packages, so you can obtain the filter manager component
>> >> > from
>> >> > the appropriate version for your test environment. The DDK has a
>> >> > nice
>> >> > article about mixing and matching checked and free components
>> >> > together.
>> >> >
>> >> > 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 Shangwu
>> >> > Sent: Monday, May 09, 2005 12:00 PM
>> >> > To: ntfsd redirect
>> >> > Subject: Re:[ntfsd] What’s problem causing minifilter unload
>> >> > hanging?
>> >> >
>> >> > Thanks Rod. Where can I get the checked version of the filter
>> >> > manager?
>> >> >
>> >> > Regards,
>> >> > Shangwu
>> >> >
>> >> > “Rod Widdowson” wrote in message
>> >> > news:xxxxx@ntfsd…
>> >> >>> My minifilter uses a communication port and contexts of instance
>> >> >>> and
>> >> >>> stream
>> >> >>> handle. When I unload the filter using “fltmc unload myfilter”,
>> >> >>> the
>> >> >>> command
>> >> >>> hangs until reboot the system. I cannot trace the problem. It
>> >> >>> seems
>> >> > all
>> >> >>> contexts are released when unload routine is called. Any help is
>> >> >>> appreciated.
>> >> >>
>> >> >> Try using the filter manager from the checked build, that gives you
>> >> > better
>> >> >> diagnostics if you are leaking contexts (as I suspect).
>> >> >>
>> >> >> Its really important to keep on unloading your minifilter during
>> >> >> development, that way you find those leaking contents (and pool
>> >> > because
>> >> >> you’ll have verifier on as well, right?) as soon as you write the
>> >> >> code
>> >> >
>> >> >> which causes the leak.
>> >> >>
>> >> >> /rod
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > —
>> >> > 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@privtek.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@privtek.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

The original author is not calling IoCompleteRequest after delaying the Irp
(after the call to KeWaitForSingleObject). Thus a lost io, and unload
doesn’t occur.

Thanks,
Rob

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-208788-
xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Tuesday, May 10, 2005 5:09 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Re:What’s problem causing minifilter unload hanging?

>The reason I use IRP based I/O is that it should be more efficient than
call functions.

I doubt that it’s much more efficient than calling the Filter Manager
routines, especially considering that there may be filters above you doing
substantial processing.

The reason most of us rolled our own Irps in legacy filters was not
efficiency, it was to be able to send the Irp down without re-entering the
file system stack at the top. That’s why Filter Manager provides APIs to
do the same thing.

What does your minifilter do when it receives the callback generated by
your I/O? That could be what is causing your unload hang.

  • Dan.

At 04:08 PM 5/10/2005 -0400, you wrote:
>Dan,
>
>Thank you for the information. Even I changed the code according to your
>suggestion, the unload still hangs. The reason I use IRP based I/O is
that
>it should be more efficient than call functions. Later I’ll use functions
if
>this problem cannot be overcome.
>
>Regards,
>
>Shangwu
>
>“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> > >A few things I see wrong. Others may see more:
> > >
> > > 1) Do not set Irp->OriginalFileObject. Ain’t your field to mess with.
> > > 2) Your completion routine accesses the Irp after freeing it.
> > > 3) Why are you doing Irp based I/O in a minifilter? You should use
> > > FltSetInformationFile.
> > > 4) Your completion routine deletes the Irp, however, by using
> > > IoGetRelatedDeviceObject, you have sent it to the top of the
> filesystem
> > > stack. Filters layered above you (including Filter Manager) may have
> set
> > > a completion routine for the Irp. The Irp is now lost from their
> > > perspective.
> > >
> > > - Dan.
> > >
> > > At 03:14 PM 5/10/2005 -0400, you wrote:
> > >>I found the following code causing the unload problem. Please adevise
> me
> > >>if
> > >>something is wrong in a minifilter context. -Thanks.
> > >>
> > >>VOID MfSetFileAllocation(PFILE_OBJECT FileObject,
> > >> PLARGE_INTEGER AllocationSize, PIO_STATUS_BLOCK IoStatusBlock)
> > >>{
> > >> PIRP irp;
> > >> PDEVICE_OBJECT fsdDevice = IoGetRelatedDeviceObject(FileObject);
> > >> KEVENT event;
> > >> PIO_STACK_LOCATION ioStackLocation;
> > >>
> > >> // Allocate an irp for this request.
> > >> irp = IoAllocateIrp(fsdDevice->StackSize, FALSE);
> > >> if (NULL == irp)
> > >> {
> > >> IoStatusBlock->Status = STATUS_INSUFFICIENT_RESOURCES;
> > >> IoStatusBlock->Information = 0;
> > >> return;
> > >> }
> > >>
> > >> irp->AssociatedIrp.SystemBuffer = AllocationSize;
> > >> irp->UserEvent = &event;
> > >> irp->UserIosb = IoStatusBlock;
> > >>
> > >> irp->Tail.Overlay.Thread = PsGetCurrentThread();
> > >> irp->Tail.Overlay.OriginalFileObject = FileObject;
> > >> irp->RequestorMode = KernelMode;
> > >>
> > >> // Initialize the event
> > >> KeInitializeEvent(&event, SynchronizationEvent, FALSE);
> > >>
> > >> // Set up the I/O stack location.
> > >> ioStackLocation = IoGetNextIrpStackLocation(irp);
> > >>
> > >> ioStackLocation->MajorFunction = IRP_MJ_SET_INFORMATION;
> > >> ioStackLocation->DeviceObject = fsdDevice;
> > >> ioStackLocation->FileObject = FileObject;
> > >>
> > >> ioStackLocation->Parameters.SetFile.Length =
> sizeof(LARGE_INTEGER);
> > >> ioStackLocation->Parameters.SetFile.FileInformationClass =
> > >>FileAllocationInformation;
> > >>
> > >> ioStackLocation->Parameters.SetFile.FileObject = 0;
> > >> ioStackLocation->Parameters.SetFile.AdvanceOnly = FALSE;
> > >>
> > >> // Set the completion routine.
> > >> IoSetCompletionRoutine(irp, MfIoCompletion, IoStatusBlock,
> > >> TRUE, TRUE, TRUE);
> > >> // Send it to the FSD
> > >> IoCallDriver(fsdDevice, irp);
> > >>
> > >> // Wait for the I/O
> > >> KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, 0);
> > >>}
> > >>
> > >>NTSTATUS MfIoCompletion(PDEVICE_OBJECT DeviceObject, PIRP Irp, PVOID
> > >>Context)
> > >>{
> > >> PIO_STATUS_BLOCK IoStatusBlock = (PIO_STATUS_BLOCK)Context;
> > >>
> > >> // Copy the status information
> > >> IoStatusBlock->Status = Irp->IoStatus.Status;
> > >> IoStatusBlock->Information = Irp->IoStatus.Information;
> > >>
> > >> // Free the IRP
> > >> IoFreeIrp(Irp);
> > >>
> > >> KeSetEvent(Irp->UserEvent, 0, FALSE);
> > >>
> > >> return STATUS_MORE_PROCESSING_REQUIRED;
> > >>}
> > >>
> > >>“Shangwu” wrote in message news:xxxxx@ntfsd…
> > >> > Tony,
> > >> >
> > >> > Thank you for providing the information. After I replaced the
> filter
> > >> > manager fltmgr.sys with a checked version from XP SP2 checked
> build, I
> > >> > got
> > >> > an error message as below.
> > >> >
> > >> > c:>fltmc load myfilter
> > >> >
> > >> > Load failed with error: 0x80070002
> > >> > The system cannot find the file specified.
> > >> >
> > >> > It was fine for the original filter manager driver. How can I fix
> this
> > >> > problem?
> > >> > I couldn’t find the DDK article you mentioned. So I directly
> replaced
> > >> > the
> > >> > driver file in system32\drivers and it seems loaded without
> complain.
> > >> >
> > >> > Regards,
> > >> >
> > >> > Shangwu
> > >> >
> > >> >
> > >> > “Tony Mason” wrote in message news:xxxxx@ntfsd…
> > >> > Shangwu,
> > >> >
> > >> > I would get it from the checked OS distribution kit, just like any
> > >> > other
> > >> > checked OS component. W2K3 SP1 and WXP SP2 both are available as
> > >> > checked packages, so you can obtain the filter manager component
> from
> > >> > the appropriate version for your test environment. The DDK has a
> nice
> > >> > article about mixing and matching checked and free components
> together.
> > >> >
> > >> > 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 Shangwu
> > >> > Sent: Monday, May 09, 2005 12:00 PM
> > >> > To: ntfsd redirect
> > >> > Subject: Re:[ntfsd] What’s problem causing minifilter unload
> hanging?
> > >> >
> > >> > Thanks Rod. Where can I get the checked version of the filter
> manager?
> > >> >
> > >> > Regards,
> > >> > Shangwu
> > >> >
> > >> > “Rod Widdowson” wrote in message
> > >> > news:xxxxx@ntfsd…
> > >> >>> My minifilter uses a communication port and contexts of instance
> and
> > >> >>> stream
> > >> >>> handle. When I unload the filter using “fltmc unload myfilter”,
> the
> > >> >>> command
> > >> >>> hangs until reboot the system. I cannot trace the problem. It
> seems
> > >> > all
> > >> >>> contexts are released when unload routine is called. Any help is
> > >> >>> appreciated.
> > >> >>
> > >> >> Try using the filter manager from the checked build, that gives
> you
> > >> > better
> > >> >> diagnostics if you are leaking contexts (as I suspect).
> > >> >>
> > >> >> Its really important to keep on unloading your minifilter during
> > >> >> development, that way you find those leaking contents (and pool
> > >> > because
> > >> >> you’ll have verifier on as well, right?) as soon as you write the
> code
> > >> >
> > >> >> which causes the leak.
> > >> >>
> > >> >> /rod
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > —
> > >> > 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 leave-ntfsd-
> 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@privtek.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@privtek.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@cdp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com