Solution for shutdown problem

At last…
I have found a solution for shutdown problem, but I do not really
understand what’s going on.

When I intercepted FSCTL requests coming to the file system’s
control object, I just skiped IRP_MN_LOAD_FILE_SYSTEM requests.
As soon as I have tried to detach my filter object from recognizer’s
control object on IRP_MN_LOAD_FILE_SYSTEM, the problem is gone.

Could someone provide an explanation of what happens during mount
requests coming to fs recognizer.

  • Why not detaching from its object causes problem with shutdown?
  • Does FS recognizer delete its device object and when?
  • If the recognizer or someone below me (attached to recognizer) calls
    IoDeleteDevice, will I get FastIoDetachDevice?
  • Is it safe to delete the filter device (attached to recognizer’s stack) on
    IRP_MN_LOAD_FILE_SYSTEM?
  • Does it always calls DeregisterFileSystem and when?
  • I use FsRegistrationChange notification to detach from it and delete
    the filter device object, is it safe in that time?

I am sorry for too much questions.

Thanks in advance,
Leonid.

>> Why not detaching from its object causes problem with shutdown

Good question. I cant see clearly from that stack backtrace how advanced is
the in-progress system shutdown operation, and what exactly happens. Nor do
I think that it worths sinking into those routines to really
learn why.

> Could someone provide an explanation of what happens during mount
> requests coming to fs recognizer.

Grosso modo:

The IO manager sense that a mount operation is required. It calls each
registered file system inorder, asking itself to see if it can mount on the
physicall media in question. Since a FS recognizer always registers itself
like a file system,
(basically , it impersonates a real file system to have a chanche to look at
the mount requests), the recognizer device
will get a chanche to look at the mount request.

During the mount request, it analyze the media , and if it finds that the FS
for which it acts as a recognizer can be mounted on it, it will return back
to the IO manager a special status code STATUS_FS_DRIVER_REQUIRED.
If the IO manager gets back this status code it will send to the FS
recognizer device a IRP_MJ_FILE_SYSTEM_CONTROL with IRP_MN_LOAD_FILE_SYSTEM.
In turn, the recognizer loads the real file system via ZwLoadDriver(), and
on success the FsRecognizer nicely deregisters itself as a file system using
IoDeregisterFileSystem()

> IoDeleteDevicewill I get FastIoDetachDevice?

FastIoDetach is allways called upon a call to IoDeleteDevice() only and only
if the DeviceObject->ReferenceCount
reaches 0. This is an indication the no outstanding references exist and
that the device object can be safely deleted.
In this situation, if any attached device exists , and its driver has fastIo
support , and FastIoDetach entry is not NULL
it will be called.

I talk now about standard MS recognizers , since they can be written in more
than one way.

> Does it always calls DeregisterFileSystem and when?

Usually FsRecognizers register shutdown notifactions. They call
IoUnregisterFileSystem upon succesfully
loading a file system driver, thus in IRP_MJ_FILE_SYTEM_CONTROL with minor
code IRP_MN_LOAD_FILE_SYSTEM (They dont anymore see IRP_MN_MOUNT…) , or in
system shutdown, in the IRP_MJ_SHUTDOWN, before deleteing the device object.

> Does FS recognizer delete its device object and when

Yes they do. As far as I know, they do this in system shutdown handlers for
the device.

> Is it safe to delete the filter device (attached to recognizer’s stack)
on
> IRP_MN_LOAD_FILE_SYSTEM?

After Ms , is the preffered way. Detach upon recieving
IRP_MN_LOAD_FILE_SYSTEM , send the request down
to the file system recognizer device and wait for the request to complete.
If the recognizer failed to load the file system
(explicilty exculde STATUS_IMAGE_ALREADY_LOADED), reattach to the recognizer
device, and complete the request. If not , delete your device and complete
the request.

----- Original Message -----
From: “Leonid Zhigunov”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Monday, September 02, 2002 7:17 PM
Subject: [ntfsd] Solution for shutdown problem

> At last…
> I have found a solution for shutdown problem, but I do not really
> understand what’s going on.
>
> When I intercepted FSCTL requests coming to the file system’s
> control object, I just skiped IRP_MN_LOAD_FILE_SYSTEM requests.
> As soon as I have tried to detach my filter object from recognizer’s
> control object on IRP_MN_LOAD_FILE_SYSTEM, the problem is gone.
>
> Could someone provide an explanation of what happens during mount
> requests coming to fs recognizer.
>
> - Why not detaching from its object causes problem with shutdown?
> - Does FS recognizer delete its device object and when?
> - If the recognizer or someone below me (attached to recognizer) calls
> , IoDeleteDevicewill I get FastIoDetachDevice?
> - Is it safe to delete the filter device (attached to recognizer’s stack)
on
> IRP_MN_LOAD_FILE_SYSTEM?
> - IoDeleteDevicewill I get FastIoDetachDevice?

> - I use FsRegistrationChange notification to detach from it and delete
> the filter device object, is it safe in that time?
>
> I am sorry for too much questions.
>
> Thanks in advance,
> Leonid.
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

I do not detach my filter devices from FS recognizers and everything works
just fine. I don’t see any reason you have such a problem.

-htfv

----- Original Message -----
From: “Leonid Zhigunov”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Monday, September 02, 2002 7:17 PM
Subject: [ntfsd] Solution for shutdown problem

> At last…
> I have found a solution for shutdown problem, but I do not really
> understand what’s going on.
>
> When I intercepted FSCTL requests coming to the file system’s
> control object, I just skiped IRP_MN_LOAD_FILE_SYSTEM requests.
> As soon as I have tried to detach my filter object from recognizer’s
> control object on IRP_MN_LOAD_FILE_SYSTEM, the problem is gone.
>
> Could someone provide an explanation of what happens during mount
> requests coming to fs recognizer.
>
> - Why not detaching from its object causes problem with shutdown?
> - Does FS recognizer delete its device object and when?
> - If the recognizer or someone below me (attached to recognizer) calls
> IoDeleteDevice, will I get FastIoDetachDevice?
> - Is it safe to delete the filter device (attached to recognizer’s stack)
on
> IRP_MN_LOAD_FILE_SYSTEM?
> - Does it always calls DeregisterFileSystem and when?
> - I use FsRegistrationChange notification to detach from it and delete
> the filter device object, is it safe in that time?
>
> I am sorry for too much questions.
>
> Thanks in advance,
> Leonid.
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>

At least, it always happens on Windows 2000 Professional with NTFS and
FAT partitions, if I try to shutdown (restart) the system without logging
in.

I have tested the filter on few systems with similar configuration, but the
result
is the same - the system hangs.

Leonid.

“Alexey Logachyov” wrote in message news:xxxxx@ntfsd…
>
> I do not detach my filter devices from FS recognizers and everything works
> just fine. I don’t see any reason you have such a problem.
>
> -htfv
>
> ----- Original Message -----
> From: “Leonid Zhigunov”
> Newsgroups: ntfsd
> To: “File Systems Developers”
> Sent: Monday, September 02, 2002 7:17 PM
> Subject: [ntfsd] Solution for shutdown problem
>
>
> > At last…
> > I have found a solution for shutdown problem, but I do not really
> > understand what’s going on.
> >
> > When I intercepted FSCTL requests coming to the file system’s
> > control object, I just skiped IRP_MN_LOAD_FILE_SYSTEM requests.
> > As soon as I have tried to detach my filter object from recognizer’s
> > control object on IRP_MN_LOAD_FILE_SYSTEM, the problem is gone.
> >
> > Could someone provide an explanation of what happens during mount
> > requests coming to fs recognizer.
> >
> > - Why not detaching from its object causes problem with shutdown?
> > - Does FS recognizer delete its device object and when?
> > - If the recognizer or someone below me (attached to recognizer) calls
> > IoDeleteDevice, will I get FastIoDetachDevice?
> > - Is it safe to delete the filter device (attached to recognizer’s
stack)
> on
> > IRP_MN_LOAD_FILE_SYSTEM?
> > - Does it always calls DeregisterFileSystem and when?
> > - I use FsRegistrationChange notification to detach from it and delete
> > the filter device object, is it safe in that time?
> >
> > I am sorry for too much questions.
> >
> > Thanks in advance,
> > Leonid.
> >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>
>

I have made a mistake and I am sorry that misleaded you.
Really, the problem was not in the detaching from a recognizer.

It was an error in my code, which was even harder to detect.
Unfortunatelly, nobody can point me on it, though I have sent
the code to this list (problem with shutdown 3).

The problem with shutdown has been caused by the first two
lines in DriverEntry:

for (i = 0; i < IRP_MJ_MAXIMUM_FUNCTION; i++) {
DriverObject->MajorFunction[i] = I2kIrpDispatch;
}

The problem with Delayed Write error has been caused also
by the first two lines, but in I2kIrpDispatch:

Irp->IoStatus.Status = STATUS_INVALID_DEVICE_REQUEST;
Irp->IoStatus.Information = 0;

wich were executed before passing the request to the next device
in the logical volume device stack. So, it means that nobody
below my filter touches Irp->IoStatus. I did not expect this.

Thanks a lot to all for your help.

Kind regards,
Leonid.

Good find! These sorts of problems are a bit more common than you might think. FASTFAT used to return an uninitialized variable from its dispatch routine for IRP_MJ_CLOSE. Because the “IO Manager” doesn’t check the return code for this IRP, everything worked fine.

-----Original Message-----
From: Leonid Zhigunov [mailto:xxxxx@progate.spb.ru]
Sent: Wednesday, September 04, 2002 7:49 AM
To: File Systems Developers
Subject: [ntfsd] Re: Solution for shutdown problem

I have made a mistake and I am sorry that misleaded you.
Really, the problem was not in the detaching from a recognizer.

It was an error in my code, which was even harder to detect.
Unfortunatelly, nobody can point me on it, though I have sent
the code to this list (problem with shutdown 3).

The problem with shutdown has been caused by the first two
lines in DriverEntry:

for (i = 0; i < IRP_MJ_MAXIMUM_FUNCTION; i++) {
DriverObject->MajorFunction[i] = I2kIrpDispatch;
}

The problem with Delayed Write error has been caused also
by the first two lines, but in I2kIrpDispatch:

Irp->IoStatus.Status = STATUS_INVALID_DEVICE_REQUEST;
Irp->IoStatus.Information = 0;

wich were executed before passing the request to the next device
in the logical volume device stack. So, it means that nobody
below my filter touches Irp->IoStatus. I did not expect this.

Thanks a lot to all for your help.

Kind regards,
Leonid.


You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%