Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed
on it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the
only system I have ever seen this problem on. All of our other NT4.0
systems are fine.

OK, here’s the meat of the matter. After our filter is loaded and we
have attached to all the appropriate devices (usually the media object
owned by disk/ftdisk), we build a table with some extended info on these
devices. Whenever, we receive a CREATE IRP, we lookup the DeviceObject
in the FileObject and, up until today, it has always been one that is in
our table. On this one system, the DeviceObject field points to an NTFS
device instead.

My question to this group is: Has anyone seen this problem and… a)
Knows why this is happening and what component is the cuprit or b) Has a
workaround.

There are no other filters that I can see involved here. What am I
missing?

We plan on rebuilding this system one component at a time to try and
isolate the problem. I will post the results here sometime next week.

/ted

Problem with NT4.0 FileObject.DeviceObjectWhy not use IoGetRelatedDeviceObject instead?
----- Original Message -----
From: Ted Hess
To: File Systems Developers
Sent: Saturday, July 26, 2003 1:25 AM
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed on it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only system I have ever seen this problem on. All of our other NT4.0 systems are fine.

OK, here’s the meat of the matter. After our filter is loaded and we have attached to all the appropriate devices (usually the media object owned by disk/ftdisk), we build a table with some extended info on these devices. Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the FileObject and, up until today, it has always been one that is in our table. On this one system, the DeviceObject field points to an NTFS device instead.

My question to this group is: Has anyone seen this problem and… a) Knows why this is happening and what component is the cuprit or b) Has a workaround.

There are no other filters that I can see involved here. What am I missing?

We plan on rebuilding this system one component at a time to try and isolate the problem. I will post the results here sometime next week.

/ted


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

Can you explain your way of attaching? Do you use IoDetachDevice, too? Do
you attach to FS or storage stack?

I’ve seen a crash dump where my driver received IRP from other driver that
attached to my device. My workaround was to check device found in IRPs
against a list of known devices and maintain usage counts for these devices.

Joze

-----Original Message-----
From: Ted Hess [mailto:xxxxx@livevault.com]
Sent: Friday, July 25, 2003 11:26 PM
To: File Systems Developers
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed on
it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
system I have ever seen this problem on. All of our other NT4.0 systems are
fine.
OK, here’s the meat of the matter. After our filter is loaded and we have
attached to all the appropriate devices (usually the media object owned by
disk/ftdisk), we build a table with some extended info on these devices.
Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
FileObject and, up until today, it has always been one that is in our table.
On this one system, the DeviceObject field points to an NTFS device instead.

My question to this group is: Has anyone seen this problem and… a) Knows
why this is happening and what component is the cuprit or b) Has a
workaround.
There are no other filters that I can see involved here. What am I missing?
We plan on rebuilding this system one component at a time to try and isolate
the problem. I will post the results here sometime next week.
/ted

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

IoGetRelatedDeviceObject() will return my filter driver (or someone above
me) – not what I’m looking for.

Good suggestion though…

/ted

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, July 25, 2003 8:06 PM
To: File Systems Developers
Subject: [ntfsd] Re: Problem with NT4.0 FileObject.DeviceObject

Why not use IoGetRelatedDeviceObject instead?

----- Original Message -----
From: Ted Hess mailto:xxxxx
To: File Systems Developers mailto:xxxxx
Sent: Saturday, July 26, 2003 1:25 AM
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed on
it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
system I have ever seen this problem on. All of our other NT4.0 systems are
fine.

OK, here’s the meat of the matter. After our filter is loaded and we have
attached to all the appropriate devices (usually the media object owned by
disk/ftdisk), we build a table with some extended info on these devices.
Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
FileObject and, up until today, it has always been one that is in our table.
On this one system, the DeviceObject field points to an NTFS device instead.

My question to this group is: Has anyone seen this problem and… a) Knows
why this is happening and what component is the cuprit or b) Has a
workaround.

There are no other filters that I can see involved here. What am I missing?

We plan on rebuilding this system one component at a time to try and isolate
the problem. I will post the results here sometime next week.

/ted


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


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

Are you looking for some device in storage stack (which
FileObject->DeviceObject usually points to)? You can get this from the
Vpb pointer passed down during mount.

Ted Hess wrote:

IoGetRelatedDeviceObject() will return my filter driver (or someone
above me) – not what I’m looking for.

Good suggestion though…

/ted

-----Original Message-----
*From:* Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
*Sent:* Friday, July 25, 2003 8:06 PM
*To:* File Systems Developers
*Subject:* [ntfsd] Re: Problem with NT4.0 FileObject.DeviceObject

Why not use IoGetRelatedDeviceObject instead?

----- Original Message -----
*From:* Ted Hess mailto:xxxxx
> To: File Systems Developers mailto:xxxxx
> Sent: Saturday, July 26, 2003 1:25 AM
> Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject
>
> We have an NT4.0 system in our lab that has the “kitchen sink”
> installed on it (Exchange, SQL, BackOffice, Site Server, IIS, etc.).
> It is the only system I have ever seen this problem on. All of our
> other NT4.0 systems are fine.
>
> OK, here’s the meat of the matter. After our filter is loaded and we
> have attached to all the appropriate devices (usually the media
> object owned by disk/ftdisk), we build a table with some extended
> info on these devices. Whenever, we receive a CREATE IRP, we lookup
> the DeviceObject in the FileObject and, up until today, it has
> always been one that is in our table. On this one system, the
> DeviceObject field points to an NTFS device instead.
>
> My question to this group is: Has anyone seen this problem and… a)
> Knows why this is happening and what component is the cuprit or b)
> Has a workaround.
>
> There are no other filters that I can see involved here. What am I
> missing?
>
> We plan on rebuilding this system one component at a time to try and
> isolate the problem. I will post the results here sometime next week.
>
> /ted
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@livevault.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com


- Nick Ryan (MVP for DDK)</mailto:xxxxx></mailto:xxxxx>

How are you attaching?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 8:12 AM
To: File Systems Developers
Subject: [ntfsd] Re: Problem with NT4.0 FileObject.DeviceObject

IoGetRelatedDeviceObject() will return my filter driver (or someone
above me) – not what I’m looking for.

Good suggestion though…

/ted

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, July 25, 2003 8:06 PM
To: File Systems Developers
Subject: [ntfsd] Re: Problem with NT4.0 FileObject.DeviceObject

Why not use IoGetRelatedDeviceObject instead?

----- Original Message -----

From: Ted Hess mailto:xxxxx

To: File Systems mailto:xxxxx Developers

Sent: Saturday, July 26, 2003 1:25 AM

Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed
on it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the
only system I have ever seen this problem on. All of our other NT4.0
systems are fine.

OK, here’s the meat of the matter. After our filter is loaded and we
have attached to all the appropriate devices (usually the media object
owned by disk/ftdisk), we build a table with some extended info on these
devices. Whenever, we receive a CREATE IRP, we lookup the DeviceObject
in the FileObject and, up until today, it has always been one that is in
our table. On this one system, the DeviceObject field points to an NTFS
device instead.

My question to this group is: Has anyone seen this problem and… a)
Knows why this is happening and what component is the cuprit or b) Has a
workaround.

There are no other filters that I can see involved here. What am I
missing?

We plan on rebuilding this system one component at a time to try and
isolate the problem. I will post the results here sometime next week.

/ted


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


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

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

Joze -

The problem I was querying about has really nothing to do with what I am
attaching to – that part of the puzzle is correct. The problem is what
DeviceObject is in the FileObject being passed down from above.

Please note: This anomoly showed up on an unusual configuration of one
particular NT4.0 system. I have no other problem (in this area) with any
other NT4/Win200/XP/WS03 systems.

/ted

-----Original Message-----
From: Joze Fabcic [mailto:xxxxx@hermes.si]
Sent: Monday, July 28, 2003 9:34 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Can you explain your way of attaching? Do you use IoDetachDevice, too? Do
you attach to FS or storage stack?

I’ve seen a crash dump where my driver received IRP from other driver that
attached to my device. My workaround was to check device found in IRPs
against a list of known devices and maintain usage counts for these devices.

Joze

-----Original Message-----
From: Ted Hess [mailto:xxxxx@livevault.com]
Sent: Friday, July 25, 2003 11:26 PM
To: File Systems Developers
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed on
it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
system I have ever seen this problem on. All of our other NT4.0 systems are
fine. OK, here’s the meat of the matter. After our filter is loaded and we
have attached to all the appropriate devices (usually the media object owned
by disk/ftdisk), we build a table with some extended info on these devices.
Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
FileObject and, up until today, it has always been one that is in our table.
On this one system, the DeviceObject field points to an NTFS device instead.

My question to this group is: Has anyone seen this problem and… a) Knows
why this is happening and what component is the cuprit or b) Has a
workaround. There are no other filters that I can see involved here. What am
I missing?
We plan on rebuilding this system one component at a time to try and isolate
the problem. I will post the results here sometime next week.
/ted

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


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

You must properly state your question. You have not done this. The
experts on this list are asking for more specific information and you
feel that it is not required. It is!

Given that you are with LiveVault, it may be that you are trying to
develop some sort of “open file”/snapshot software; I am not 100% sure,
but I have my suspicions.

We need to know how you are attaching to the device stack… Are you
loading a disk filter driver that attaches to partitions when the
AddDevice routine is called or are you writing a file system filter
driver that is attaching to the disk device objects at mount time?

If it is the latter, there are several problems that I know of in doing
this under NT 4.0. In my opinion, it is a bug in NT 4.0. The problems
that I am speaking of can appear to work for months and then all of a
sudden, every system you run it on will crash; something to do with the
distance between the Earth and Mars and that distance is about to reach
it closest it has been in almost 60,000,000 years. So, hold on to your
hat and please answer our questions.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 8:24 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Joze -

The problem I was querying about has really nothing to do with what I am
attaching to – that part of the puzzle is correct. The problem is what
DeviceObject is in the FileObject being passed down from above.

Please note: This anomoly showed up on an unusual configuration of one
particular NT4.0 system. I have no other problem (in this area) with any
other NT4/Win200/XP/WS03 systems.

/ted

-----Original Message-----
From: Joze Fabcic [mailto:xxxxx@hermes.si]
Sent: Monday, July 28, 2003 9:34 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Can you explain your way of attaching? Do you use IoDetachDevice, too?
Do
you attach to FS or storage stack?

I’ve seen a crash dump where my driver received IRP from other driver
that
attached to my device. My workaround was to check device found in IRPs
against a list of known devices and maintain usage counts for these
devices.

Joze

-----Original Message-----
From: Ted Hess [mailto:xxxxx@livevault.com]
Sent: Friday, July 25, 2003 11:26 PM
To: File Systems Developers
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed
on
it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
system I have ever seen this problem on. All of our other NT4.0 systems
are
fine. OK, here’s the meat of the matter. After our filter is loaded and
we
have attached to all the appropriate devices (usually the media object
owned
by disk/ftdisk), we build a table with some extended info on these
devices.
Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
FileObject and, up until today, it has always been one that is in our
table.
On this one system, the DeviceObject field points to an NTFS device
instead.

My question to this group is: Has anyone seen this problem and… a)
Knows
why this is happening and what component is the cuprit or b) Has a
workaround. There are no other filters that I can see involved here.
What am
I missing?
We plan on rebuilding this system one component at a time to try and
isolate
the problem. I will post the results here sometime next week.
/ted

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


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


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

Yes, I may have been a little too concise in my original post. I will
elaborate…

Our filter is built on top of OSR’s FDDK. It is through their recognizer and
filter that we do our actual work. We are both an open file manager and a
replication change filter.

To answer your specific question: We are a file system filter attaching to
the media device at mount / driver load time - no problem here.

What we see in a CREATE IRPs FileObject->DeviceObject is (usually - for the
last 6-yrs) the media device object mounted. On rare occasions we see the
NTFS device - we ignore it. In this instance, we are always seeing the NTFS
device. So… you can see my puzzlement.

No crash, no burn, no hiccups - in fact, on this system, we aren’t even
filtering.

My question to the group was really one of curiosity - I was just looking
for an explanation of the phenomenon. And, I have a moderately half-backed
plan for a workaround. I would however, dearly like to know how it happened.
(And yes, I can accept: “Your poorly written old filter is screwing with the
system…”)

/ted

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Monday, July 28, 2003 1:21 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

You must properly state your question. You have not done this. The experts
on this list are asking for more specific information and you feel that it
is not required. It is!

Given that you are with LiveVault, it may be that you are trying to develop
some sort of “open file”/snapshot software; I am not 100% sure, but I have
my suspicions.

We need to know how you are attaching to the device stack… Are you loading
a disk filter driver that attaches to partitions when the AddDevice routine
is called or are you writing a file system filter driver that is attaching
to the disk device objects at mount time?

If it is the latter, there are several problems that I know of in doing this
under NT 4.0. In my opinion, it is a bug in NT 4.0. The problems that I am
speaking of can appear to work for months and then all of a sudden, every
system you run it on will crash; something to do with the distance between
the Earth and Mars and that distance is about to reach it closest it has
been in almost 60,000,000 years. So, hold on to your hat and please answer
our questions.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 8:24 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Joze -

The problem I was querying about has really nothing to do with what I am
attaching to – that part of the puzzle is correct. The problem is what
DeviceObject is in the FileObject being passed down from above.

Please note: This anomoly showed up on an unusual configuration of one
particular NT4.0 system. I have no other problem (in this area) with any
other NT4/Win200/XP/WS03 systems.

/ted

-----Original Message-----
From: Joze Fabcic [mailto:xxxxx@hermes.si]
Sent: Monday, July 28, 2003 9:34 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Can you explain your way of attaching? Do you use IoDetachDevice, too? Do
you attach to FS or storage stack?

I’ve seen a crash dump where my driver received IRP from other driver that
attached to my device. My workaround was to check device found in IRPs
against a list of known devices and maintain usage counts for these devices.

Joze

-----Original Message-----
From: Ted Hess [mailto:xxxxx@livevault.com]
Sent: Friday, July 25, 2003 11:26 PM
To: File Systems Developers
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed on
it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
system I have ever seen this problem on. All of our other NT4.0 systems are
fine. OK, here’s the meat of the matter. After our filter is loaded and we
have attached to all the appropriate devices (usually the media object owned
by disk/ftdisk), we build a table with some extended info on these devices.
Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
FileObject and, up until today, it has always been one that is in our table.
On this one system, the DeviceObject field points to an NTFS device instead.

My question to this group is: Has anyone seen this problem and… a) Knows
why this is happening and what component is the cuprit or b) Has a
workaround. There are no other filters that I can see involved here. What am
I missing?
We plan on rebuilding this system one component at a time to try and isolate
the problem. I will post the results here sometime next week.
/ted

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


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


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


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

Actually, I would disagree with this characterization as unduly harsh (and I
agree we get many questions that are not adequately described on this list!)

Ted’s been participating in the list for many years, so I didn’t think this
was a newbie question. He also states that this is not an issue of
attachment, but rather of what is present in the file object in one specific
instance - he sees the other volumes map normally. To me that would rule
out an attachment issue.

My questions would be:

  • What is the file in question (path + name, ideally)
  • Which NTFS device object (it occurred to me that an open of the named NTFS
    device would appear in exactly this fashion)

Keep in mind that if it is \Ntfs the object won’t be associated with a
volume, even though it MAY be opened (it just doesn’t HAPPEN very often).
That’s my best guess…

Regards,

Tony

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

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Monday, July 28, 2003 1:21 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

You must properly state your question. You have not done this. The
experts on this list are asking for more specific information and you
feel that it is not required. It is!

Given that you are with LiveVault, it may be that you are trying to
develop some sort of “open file”/snapshot software; I am not 100% sure,
but I have my suspicions.

We need to know how you are attaching to the device stack… Are you
loading a disk filter driver that attaches to partitions when the
AddDevice routine is called or are you writing a file system filter
driver that is attaching to the disk device objects at mount time?

If it is the latter, there are several problems that I know of in doing
this under NT 4.0. In my opinion, it is a bug in NT 4.0. The problems
that I am speaking of can appear to work for months and then all of a
sudden, every system you run it on will crash; something to do with the
distance between the Earth and Mars and that distance is about to reach
it closest it has been in almost 60,000,000 years. So, hold on to your
hat and please answer our questions.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 8:24 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Joze -

The problem I was querying about has really nothing to do with what I am
attaching to – that part of the puzzle is correct. The problem is what
DeviceObject is in the FileObject being passed down from above.

Please note: This anomoly showed up on an unusual configuration of one
particular NT4.0 system. I have no other problem (in this area) with any
other NT4/Win200/XP/WS03 systems.

/ted

-----Original Message-----
From: Joze Fabcic [mailto:xxxxx@hermes.si]
Sent: Monday, July 28, 2003 9:34 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Can you explain your way of attaching? Do you use IoDetachDevice, too?
Do
you attach to FS or storage stack?

I’ve seen a crash dump where my driver received IRP from other driver
that
attached to my device. My workaround was to check device found in IRPs
against a list of known devices and maintain usage counts for these
devices.

Joze

-----Original Message-----
From: Ted Hess [mailto:xxxxx@livevault.com]
Sent: Friday, July 25, 2003 11:26 PM
To: File Systems Developers
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed
on
it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
system I have ever seen this problem on. All of our other NT4.0 systems
are
fine. OK, here’s the meat of the matter. After our filter is loaded and
we
have attached to all the appropriate devices (usually the media object
owned
by disk/ftdisk), we build a table with some extended info on these
devices.
Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
FileObject and, up until today, it has always been one that is in our
table.
On this one system, the DeviceObject field points to an NTFS device
instead.

My question to this group is: Has anyone seen this problem and… a)
Knows
why this is happening and what component is the cuprit or b) Has a
workaround. There are no other filters that I can see involved here.
What am
I missing?
We plan on rebuilding this system one component at a time to try and
isolate
the problem. I will post the results here sometime next week.
/ted

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


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


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


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

Maybe we should take this off-line.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 11:07 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Yes, I may have been a little too concise in my original post. I will
elaborate…

Our filter is built on top of OSR’s FDDK. It is through their recognizer
and
filter that we do our actual work. We are both an open file manager and
a
replication change filter.

To answer your specific question: We are a file system filter attaching
to
the media device at mount / driver load time - no problem here.

What we see in a CREATE IRPs FileObject->DeviceObject is (usually - for
the
last 6-yrs) the media device object mounted. On rare occasions we see
the
NTFS device - we ignore it. In this instance, we are always seeing the
NTFS
device. So… you can see my puzzlement.

No crash, no burn, no hiccups - in fact, on this system, we aren’t even
filtering.

My question to the group was really one of curiosity - I was just
looking
for an explanation of the phenomenon. And, I have a moderately
half-backed
plan for a workaround. I would however, dearly like to know how it
happened.
(And yes, I can accept: “Your poorly written old filter is screwing with
the
system…”)

/ted

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Monday, July 28, 2003 1:21 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

You must properly state your question. You have not done this. The
experts
on this list are asking for more specific information and you feel that
it
is not required. It is!

Given that you are with LiveVault, it may be that you are trying to
develop
some sort of “open file”/snapshot software; I am not 100% sure, but I
have
my suspicions.

We need to know how you are attaching to the device stack… Are you
loading
a disk filter driver that attaches to partitions when the AddDevice
routine
is called or are you writing a file system filter driver that is
attaching
to the disk device objects at mount time?

If it is the latter, there are several problems that I know of in doing
this
under NT 4.0. In my opinion, it is a bug in NT 4.0. The problems that I
am
speaking of can appear to work for months and then all of a sudden,
every
system you run it on will crash; something to do with the distance
between
the Earth and Mars and that distance is about to reach it closest it has
been in almost 60,000,000 years. So, hold on to your hat and please
answer
our questions.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 8:24 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Joze -

The problem I was querying about has really nothing to do with what I am
attaching to – that part of the puzzle is correct. The problem is what
DeviceObject is in the FileObject being passed down from above.

Please note: This anomoly showed up on an unusual configuration of one
particular NT4.0 system. I have no other problem (in this area) with any
other NT4/Win200/XP/WS03 systems.

/ted

-----Original Message-----
From: Joze Fabcic [mailto:xxxxx@hermes.si]
Sent: Monday, July 28, 2003 9:34 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Can you explain your way of attaching? Do you use IoDetachDevice, too?
Do
you attach to FS or storage stack?

I’ve seen a crash dump where my driver received IRP from other driver
that
attached to my device. My workaround was to check device found in IRPs
against a list of known devices and maintain usage counts for these
devices.

Joze

-----Original Message-----
From: Ted Hess [mailto:xxxxx@livevault.com]
Sent: Friday, July 25, 2003 11:26 PM
To: File Systems Developers
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed
on
it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
system I have ever seen this problem on. All of our other NT4.0 systems
are
fine. OK, here’s the meat of the matter. After our filter is loaded and
we
have attached to all the appropriate devices (usually the media object
owned
by disk/ftdisk), we build a table with some extended info on these
devices.
Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
FileObject and, up until today, it has always been one that is in our
table.
On this one system, the DeviceObject field points to an NTFS device
instead.

My question to this group is: Has anyone seen this problem and… a)
Knows
why this is happening and what component is the cuprit or b) Has a
workaround. There are no other filters that I can see involved here.
What am
I missing?
We plan on rebuilding this system one component at a time to try and
isolate
the problem. I will post the results here sometime next week.
/ted

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


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


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


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


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

My only issue with the post was not answering our questions to help him.
Maybe they are not the correct questions, but if someone is willing to
help, someone who has extensive experience in this area, it would be
proper to answer the question.

I know that Ted is not a newbie. Sorry if I made too much noise.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Monday, July 28, 2003 11:41 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Actually, I would disagree with this characterization as unduly harsh
(and I
agree we get many questions that are not adequately described on this
list!)

Ted’s been participating in the list for many years, so I didn’t think
this
was a newbie question. He also states that this is not an issue of
attachment, but rather of what is present in the file object in one
specific
instance - he sees the other volumes map normally. To me that would
rule
out an attachment issue.

My questions would be:

  • What is the file in question (path + name, ideally)
  • Which NTFS device object (it occurred to me that an open of the named
    NTFS
    device would appear in exactly this fashion)

Keep in mind that if it is \Ntfs the object won’t be associated with a
volume, even though it MAY be opened (it just doesn’t HAPPEN very
often).
That’s my best guess…

Regards,

Tony

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

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Monday, July 28, 2003 1:21 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

You must properly state your question. You have not done this. The
experts on this list are asking for more specific information and you
feel that it is not required. It is!

Given that you are with LiveVault, it may be that you are trying to
develop some sort of “open file”/snapshot software; I am not 100% sure,
but I have my suspicions.

We need to know how you are attaching to the device stack… Are you
loading a disk filter driver that attaches to partitions when the
AddDevice routine is called or are you writing a file system filter
driver that is attaching to the disk device objects at mount time?

If it is the latter, there are several problems that I know of in doing
this under NT 4.0. In my opinion, it is a bug in NT 4.0. The problems
that I am speaking of can appear to work for months and then all of a
sudden, every system you run it on will crash; something to do with the
distance between the Earth and Mars and that distance is about to reach
it closest it has been in almost 60,000,000 years. So, hold on to your
hat and please answer our questions.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 8:24 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Joze -

The problem I was querying about has really nothing to do with what I am
attaching to – that part of the puzzle is correct. The problem is what
DeviceObject is in the FileObject being passed down from above.

Please note: This anomoly showed up on an unusual configuration of one
particular NT4.0 system. I have no other problem (in this area) with any
other NT4/Win200/XP/WS03 systems.

/ted

-----Original Message-----
From: Joze Fabcic [mailto:xxxxx@hermes.si]
Sent: Monday, July 28, 2003 9:34 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Can you explain your way of attaching? Do you use IoDetachDevice, too?
Do
you attach to FS or storage stack?

I’ve seen a crash dump where my driver received IRP from other driver
that
attached to my device. My workaround was to check device found in IRPs
against a list of known devices and maintain usage counts for these
devices.

Joze

-----Original Message-----
From: Ted Hess [mailto:xxxxx@livevault.com]
Sent: Friday, July 25, 2003 11:26 PM
To: File Systems Developers
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed
on
it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
system I have ever seen this problem on. All of our other NT4.0 systems
are
fine. OK, here’s the meat of the matter. After our filter is loaded and
we
have attached to all the appropriate devices (usually the media object
owned
by disk/ftdisk), we build a table with some extended info on these
devices.
Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
FileObject and, up until today, it has always been one that is in our
table.
On this one system, the DeviceObject field points to an NTFS device
instead.

My question to this group is: Has anyone seen this problem and… a)
Knows
why this is happening and what component is the cuprit or b) Has a
workaround. There are no other filters that I can see involved here.
What am
I missing?
We plan on rebuilding this system one component at a time to try and
isolate
the problem. I will post the results here sometime next week.
/ted

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


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


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


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


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

I have seen something like this happen with drivers that were based on
the sfilter.c sample that came with the Windows 2000 IFS kit.
Specifically the problem was in SfFsControl while processing a mount
request in that it would look for a device object to use (from the
recognizer). All of this was to handle detaching from the volume (as
nt4.0 had a bug in that it would free the device object and then call
your dispatch routine). By removing this code (and always creating a
new one) I solved the issue. However I don’t support NT 4.0 so I cant
say what the solution for it would be. Later versions of the IFS kit
don’t even bother with this logic as it has been removed.

This case would only happen if the system FS was FAT, otherwise the file
system recognizer stuff would not be called for NTFS (as it is
implicitly loaded by the boot loader).

I am not sure why removing the code worked or what the actual problem
was, and this was several years ago, so I may be wrong.

Thanks,
Rob

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-ntfsd-
xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Monday, July 28, 2003 3:04 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Maybe we should take this off-line.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 11:07 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Yes, I may have been a little too concise in my original post. I will
elaborate…

Our filter is built on top of OSR’s FDDK. It is through their
recognizer
and
filter that we do our actual work. We are both an open file manager
and
a
replication change filter.

To answer your specific question: We are a file system filter
attaching
to
the media device at mount / driver load time - no problem here.

What we see in a CREATE IRPs FileObject->DeviceObject is (usually -
for
the
last 6-yrs) the media device object mounted. On rare occasions we see
the
NTFS device - we ignore it. In this instance, we are always seeing the
NTFS
device. So… you can see my puzzlement.

No crash, no burn, no hiccups - in fact, on this system, we aren’t
even
filtering.

My question to the group was really one of curiosity - I was just
looking
for an explanation of the phenomenon. And, I have a moderately
half-backed
plan for a workaround. I would however, dearly like to know how it
happened.
(And yes, I can accept: “Your poorly written old filter is screwing
with
the
system…”)

/ted

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Monday, July 28, 2003 1:21 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

You must properly state your question. You have not done this. The
experts
on this list are asking for more specific information and you feel
that
it
is not required. It is!

Given that you are with LiveVault, it may be that you are trying to
develop
some sort of “open file”/snapshot software; I am not 100% sure, but I
have
my suspicions.

We need to know how you are attaching to the device stack… Are you
loading
a disk filter driver that attaches to partitions when the AddDevice
routine
is called or are you writing a file system filter driver that is
attaching
to the disk device objects at mount time?

If it is the latter, there are several problems that I know of in
doing
this
under NT 4.0. In my opinion, it is a bug in NT 4.0. The problems that
I
am
speaking of can appear to work for months and then all of a sudden,
every
system you run it on will crash; something to do with the distance
between
the Earth and Mars and that distance is about to reach it closest it
has
been in almost 60,000,000 years. So, hold on to your hat and please
answer
our questions.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 8:24 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Joze -

The problem I was querying about has really nothing to do with what I
am
attaching to – that part of the puzzle is correct. The problem is
what
DeviceObject is in the FileObject being passed down from above.

Please note: This anomoly showed up on an unusual configuration of one
particular NT4.0 system. I have no other problem (in this area) with
any
other NT4/Win200/XP/WS03 systems.

/ted

-----Original Message-----
From: Joze Fabcic [mailto:xxxxx@hermes.si]
Sent: Monday, July 28, 2003 9:34 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Can you explain your way of attaching? Do you use IoDetachDevice, too?
Do
you attach to FS or storage stack?

I’ve seen a crash dump where my driver received IRP from other driver
that
attached to my device. My workaround was to check device found in IRPs
against a list of known devices and maintain usage counts for these
devices.

Joze

-----Original Message-----
From: Ted Hess [mailto:xxxxx@livevault.com]
Sent: Friday, July 25, 2003 11:26 PM
To: File Systems Developers
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink”
installed
on
it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
system I have ever seen this problem on. All of our other NT4.0
systems
are
fine. OK, here’s the meat of the matter. After our filter is loaded
and
we
have attached to all the appropriate devices (usually the media object
owned
by disk/ftdisk), we build a table with some extended info on these
devices.
Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
FileObject and, up until today, it has always been one that is in our
table.
On this one system, the DeviceObject field points to an NTFS device
instead.

My question to this group is: Has anyone seen this problem and… a)
Knows
why this is happening and what component is the cuprit or b) Has a
workaround. There are no other filters that I can see involved here.
What am
I missing?
We plan on rebuilding this system one component at a time to try and
isolate
the problem. I will post the results here sometime next week.
/ted

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


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


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


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


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


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

I’m beginning to regret ever mentioning the fact that I remember the DO of
the media device when I attach a filter device.

The question could have been quite simply put:

“On NT 4.0 – Other than when something directly opens the ntfs device, when
would one see that device (ntfs) in a FileObject.DeviceObject field in a
CREATE to a normal file on that volume?”

Normally, this field points to the media device object - usually a disk or
ftdisk device. And, if the VPB is valid: (FileObject->DeviceObject ==
FileObject->Vpb->RealDevice) Doesn’t it?

I’ll have this figured out in a bit (as soon as we re-build the system) and
then I’ll let you all know what we find out. Actually, I think Jamey is
right and it has more to do with the fact that Mars is way too close…

/ted

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Monday, July 28, 2003 5:15 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

I have seen something like this happen with drivers that were based on the
sfilter.c sample that came with the Windows 2000 IFS kit. Specifically the
problem was in SfFsControl while processing a mount request in that it would
look for a device object to use (from the recognizer). All of this was to
handle detaching from the volume (as nt4.0 had a bug in that it would free
the device object and then call your dispatch routine). By removing this
code (and always creating a new one) I solved the issue. However I don’t
support NT 4.0 so I cant say what the solution for it would be. Later
versions of the IFS kit don’t even bother with this logic as it has been
removed.

This case would only happen if the system FS was FAT, otherwise the file
system recognizer stuff would not be called for NTFS (as it is implicitly
loaded by the boot loader).

I am not sure why removing the code worked or what the actual problem was,
and this was several years ago, so I may be wrong.

Thanks,
Rob

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-ntfsd-
xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Monday, July 28, 2003 3:04 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Maybe we should take this off-line.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 11:07 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Yes, I may have been a little too concise in my original post. I will
elaborate…

Our filter is built on top of OSR’s FDDK. It is through their
recognizer
and
filter that we do our actual work. We are both an open file manager
and
a
replication change filter.

To answer your specific question: We are a file system filter
attaching
to
the media device at mount / driver load time - no problem here.

What we see in a CREATE IRPs FileObject->DeviceObject is (usually -
for
the
last 6-yrs) the media device object mounted. On rare occasions we see
the NTFS device - we ignore it. In this instance, we are always seeing
the NTFS
device. So… you can see my puzzlement.

No crash, no burn, no hiccups - in fact, on this system, we aren’t
even
filtering.

My question to the group was really one of curiosity - I was just
looking for an explanation of the phenomenon. And, I have a moderately
half-backed
plan for a workaround. I would however, dearly like to know how it
happened.
(And yes, I can accept: “Your poorly written old filter is screwing
with
the
system…”)

/ted

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Monday, July 28, 2003 1:21 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

You must properly state your question. You have not done this. The
experts on this list are asking for more specific information and you
feel
that
it
is not required. It is!

Given that you are with LiveVault, it may be that you are trying to
develop some sort of “open file”/snapshot software; I am not 100%
sure, but I have
my suspicions.

We need to know how you are attaching to the device stack… Are you
loading a disk filter driver that attaches to partitions when the
AddDevice routine
is called or are you writing a file system filter driver that is
attaching
to the disk device objects at mount time?

If it is the latter, there are several problems that I know of in
doing
this
under NT 4.0. In my opinion, it is a bug in NT 4.0. The problems that
I
am
speaking of can appear to work for months and then all of a sudden,
every system you run it on will crash; something to do with the
distance between
the Earth and Mars and that distance is about to reach it closest it
has
been in almost 60,000,000 years. So, hold on to your hat and please
answer our questions.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 8:24 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Joze -

The problem I was querying about has really nothing to do with what I
am
attaching to – that part of the puzzle is correct. The problem is
what
DeviceObject is in the FileObject being passed down from above.

Please note: This anomoly showed up on an unusual configuration of one
particular NT4.0 system. I have no other problem (in this area) with
any
other NT4/Win200/XP/WS03 systems.

/ted

-----Original Message-----
From: Joze Fabcic [mailto:xxxxx@hermes.si]
Sent: Monday, July 28, 2003 9:34 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Can you explain your way of attaching? Do you use IoDetachDevice, too?
Do you attach to FS or storage stack?

I’ve seen a crash dump where my driver received IRP from other driver
that attached to my device. My workaround was to check device found in
IRPs against a list of known devices and maintain usage counts for
these devices.

Joze

-----Original Message-----
From: Ted Hess [mailto:xxxxx@livevault.com]
Sent: Friday, July 25, 2003 11:26 PM
To: File Systems Developers
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink”
installed
on
it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
system I have ever seen this problem on. All of our other NT4.0
systems
are
fine. OK, here’s the meat of the matter. After our filter is loaded
and
we
have attached to all the appropriate devices (usually the media object
owned by disk/ftdisk), we build a table with some extended info on
these devices.
Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
FileObject and, up until today, it has always been one that is in our
table.
On this one system, the DeviceObject field points to an NTFS device
instead.

My question to this group is: Has anyone seen this problem and… a)
Knows why this is happening and what component is the cuprit or b) Has
a workaround. There are no other filters that I can see involved here.
What am
I missing?
We plan on rebuilding this system one component at a time to try and
isolate
the problem. I will post the results here sometime next week.
/ted

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


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


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


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


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


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


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

Maybe this could be added to the FAQ:

NT4 has a bug - IoRegisterFsRegistrationChange increments the
DeviceObject->ReferenceCount field on the first device object hanging
off this driver to prevent the driver from unload while the FS
registration callback is not revoked

a) BSOD if no device objects at all yet.

b) If this device object is exclusive - it will never be opened
(IopParseDevice fails CREATE for exclusive device objects with
ReferenceCount != 0); causing all sorts of problems.

NT5+ does not have this bug - it uses ObReferenceObject on the driver
object instead.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rob Green
Sent: Monday, July 28, 2003 2:15 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

I have seen something like this happen with drivers that were based on
the sfilter.c sample that came with the Windows 2000 IFS kit.
Specifically the problem was in SfFsControl while processing a mount
request in that it would look for a device object to use (from the
recognizer). All of this was to handle detaching from the volume (as
nt4.0 had a bug in that it would free the device object and then call
your dispatch routine). By removing this code (and always creating a
new one) I solved the issue. However I don’t support NT 4.0 so I cant
say what the solution for it would be. Later versions of the IFS kit
don’t even bother with this logic as it has been removed.

This case would only happen if the system FS was FAT, otherwise the file
system recognizer stuff would not be called for NTFS (as it is
implicitly loaded by the boot loader).

I am not sure why removing the code worked or what the actual problem
was, and this was several years ago, so I may be wrong.

Thanks,
Rob

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-ntfsd-
xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Monday, July 28, 2003 3:04 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Maybe we should take this off-line.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 11:07 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Yes, I may have been a little too concise in my original post. I will
elaborate…

Our filter is built on top of OSR’s FDDK. It is through their
recognizer
and
filter that we do our actual work. We are both an open file manager
and
a
replication change filter.

To answer your specific question: We are a file system filter
attaching
to
the media device at mount / driver load time - no problem here.

What we see in a CREATE IRPs FileObject->DeviceObject is (usually -
for
the
last 6-yrs) the media device object mounted. On rare occasions we see
the
NTFS device - we ignore it. In this instance, we are always seeing the
NTFS
device. So… you can see my puzzlement.

No crash, no burn, no hiccups - in fact, on this system, we aren’t
even
filtering.

My question to the group was really one of curiosity - I was just
looking
for an explanation of the phenomenon. And, I have a moderately
half-backed
plan for a workaround. I would however, dearly like to know how it
happened.
(And yes, I can accept: “Your poorly written old filter is screwing
with
the
system…”)

/ted

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Monday, July 28, 2003 1:21 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

You must properly state your question. You have not done this. The
experts
on this list are asking for more specific information and you feel
that
it
is not required. It is!

Given that you are with LiveVault, it may be that you are trying to
develop
some sort of “open file”/snapshot software; I am not 100% sure, but I
have
my suspicions.

We need to know how you are attaching to the device stack… Are you
loading
a disk filter driver that attaches to partitions when the AddDevice
routine
is called or are you writing a file system filter driver that is
attaching
to the disk device objects at mount time?

If it is the latter, there are several problems that I know of in
doing
this
under NT 4.0. In my opinion, it is a bug in NT 4.0. The problems that
I
am
speaking of can appear to work for months and then all of a sudden,
every
system you run it on will crash; something to do with the distance
between
the Earth and Mars and that distance is about to reach it closest it
has
been in almost 60,000,000 years. So, hold on to your hat and please
answer
our questions.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, July 28, 2003 8:24 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Joze -

The problem I was querying about has really nothing to do with what I
am
attaching to – that part of the puzzle is correct. The problem is
what
DeviceObject is in the FileObject being passed down from above.

Please note: This anomoly showed up on an unusual configuration of one
particular NT4.0 system. I have no other problem (in this area) with
any
other NT4/Win200/XP/WS03 systems.

/ted

-----Original Message-----
From: Joze Fabcic [mailto:xxxxx@hermes.si]
Sent: Monday, July 28, 2003 9:34 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Can you explain your way of attaching? Do you use IoDetachDevice, too?
Do
you attach to FS or storage stack?

I’ve seen a crash dump where my driver received IRP from other driver
that
attached to my device. My workaround was to check device found in IRPs
against a list of known devices and maintain usage counts for these
devices.

Joze

-----Original Message-----
From: Ted Hess [mailto:xxxxx@livevault.com]
Sent: Friday, July 25, 2003 11:26 PM
To: File Systems Developers
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink”
installed
on
it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
system I have ever seen this problem on. All of our other NT4.0
systems
are
fine. OK, here’s the meat of the matter. After our filter is loaded
and
we
have attached to all the appropriate devices (usually the media object
owned
by disk/ftdisk), we build a table with some extended info on these
devices.
Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
FileObject and, up until today, it has always been one that is in our
table.
On this one system, the DeviceObject field points to an NTFS device
instead.

My question to this group is: Has anyone seen this problem and… a)
Knows
why this is happening and what component is the cuprit or b) Has a
workaround. There are no other filters that I can see involved here.
What am
I missing?
We plan on rebuilding this system one component at a time to try and
isolate
the problem. I will post the results here sometime next week.
/ted

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


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


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


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


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


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


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

Message Then IoGetBaseFileSystemDeviceObject is a solution.

----- Original Message -----
From: Ted Hess
To: File Systems Developers
Sent: Monday, July 28, 2003 7:12 PM
Subject: [ntfsd] Re: Problem with NT4.0 FileObject.DeviceObject

IoGetRelatedDeviceObject() will return my filter driver (or someone above me) – not what I’m looking for.

Good suggestion though…

/ted

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, July 25, 2003 8:06 PM
To: File Systems Developers
Subject: [ntfsd] Re: Problem with NT4.0 FileObject.DeviceObject

Why not use IoGetRelatedDeviceObject instead?
----- Original Message -----
From: Ted Hess
To: File Systems Developers
Sent: Saturday, July 26, 2003 1:25 AM
Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed on it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only system I have ever seen this problem on. All of our other NT4.0 systems are fine.

OK, here’s the meat of the matter. After our filter is loaded and we have attached to all the appropriate devices (usually the media object owned by disk/ftdisk), we build a table with some extended info on these devices. Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the FileObject and, up until today, it has always been one that is in our table. On this one system, the DeviceObject field points to an NTFS device instead.

My question to this group is: Has anyone seen this problem and… a) Knows why this is happening and what component is the cuprit or b) Has a workaround.

There are no other filters that I can see involved here. What am I missing?

We plan on rebuilding this system one component at a time to try and isolate the problem. I will post the results here sometime next week.

/ted


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

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

Now Max, that would be too simple :slight_smile:

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, July 28, 2003 2:44 PM
To: File Systems Developers
Subject: [ntfsd] Re: Problem with NT4.0 FileObject.DeviceObject

Then IoGetBaseFileSystemDeviceObject is a solution.

----- Original Message -----

From: Ted Hess mailto:xxxxx

To: File Systems mailto:xxxxx Developers

Sent: Monday, July 28, 2003 7:12 PM

Subject: [ntfsd] Re: Problem with NT4.0 FileObject.DeviceObject

IoGetRelatedDeviceObject() will return my filter driver (or someone
above me) – not what I’m looking for.

Good suggestion though…

/ted

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, July 25, 2003 8:06 PM
To: File Systems Developers
Subject: [ntfsd] Re: Problem with NT4.0 FileObject.DeviceObject

Why not use IoGetRelatedDeviceObject instead?

----- Original Message -----

From: Ted Hess mailto:xxxxx

To: File Systems mailto:xxxxx Developers

Sent: Saturday, July 26, 2003 1:25 AM

Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject

We have an NT4.0 system in our lab that has the “kitchen sink” installed
on it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the
only system I have ever seen this problem on. All of our other NT4.0
systems are fine.

OK, here’s the meat of the matter. After our filter is loaded and we
have attached to all the appropriate devices (usually the media object
owned by disk/ftdisk), we build a table with some extended info on these
devices. Whenever, we receive a CREATE IRP, we lookup the DeviceObject
in the FileObject and, up until today, it has always been one that is in
our table. On this one system, the DeviceObject field points to an NTFS
device instead.

My question to this group is: Has anyone seen this problem and… a)
Knows why this is happening and what component is the cuprit or b) Has a
workaround.

There are no other filters that I can see involved here. What am I
missing?

We plan on rebuilding this system one component at a time to try and
isolate the problem. I will post the results here sometime next week.

/ted


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


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

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


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

Problem with NT4.0 FileObject.DeviceObjectIRP_MJ_CREATE is generated if somebody calls ZwCreateFile, ObOpenObjectByPointer or IoGetDeviceObjectPointer.
ZwCreateFile and IoGetDeviceObjectPointer must be ruled out - device in question doesn’t have any name.
Apparently some other component uses ObOpenObjectByPointer specifing device object that was created by file system.

Alexei.
“Ted Hess” wrote in message news:xxxxx@ntfsd…
We have an NT4.0 system in our lab that has the “kitchen sink” installed on it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only system I have ever seen this problem on. All of our other NT4.0 systems are fine.

OK, here’s the meat of the matter. After our filter is loaded and we have attached to all the appropriate devices (usually the media object owned by disk/ftdisk), we build a table with some extended info on these devices. Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the FileObject and, up until today, it has always been one that is in our table. On this one system, the DeviceObject field points to an NTFS device instead.

My question to this group is: Has anyone seen this problem and… a) Knows why this is happening and what component is the cuprit or b) Has a workaround.

There are no other filters that I can see involved here. What am I missing?

We plan on rebuilding this system one component at a time to try and isolate the problem. I will post the results here sometime next week.

/ted

Let’s try to approach this from another angle…

Why depend on FileObject->DeviceObject at all? Where is Microsoft
guaranteeing that this field is always going to be the storage stack?
From your original message, I gather you were using
FileObject->DeviceObject as a key into a table. Instead, why not just
hang any state associated with a filtered volume off of a device
extension you attach to your filter device object? For file I/O requests
to a filtered volume, the DeviceObject parameter of your dispatch entry
point is guaranteed to be your filter device object (and this is
documented behavior). If you need to get at the storage device stack,
remember what Vpb->RealDevice was when you intercepted the mount
request, and store this away in the device extension.

If you need to fix bugs in legacy code that can’t be heavily altered,
then it’s another issue.

Ted Hess wrote:

I’m beginning to regret ever mentioning the fact that I remember the DO of
the media device when I attach a filter device.

The question could have been quite simply put:

“On NT 4.0 – Other than when something directly opens the ntfs device, when
would one see that device (ntfs) in a FileObject.DeviceObject field in a
CREATE to a normal file on that volume?”

Normally, this field points to the media device object - usually a disk or
ftdisk device. And, if the VPB is valid: (FileObject->DeviceObject ==
FileObject->Vpb->RealDevice) Doesn’t it?

I’ll have this figured out in a bit (as soon as we re-build the system) and
then I’ll let you all know what we find out. Actually, I think Jamey is
right and it has more to do with the fact that Mars is way too close…

/ted

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Monday, July 28, 2003 5:15 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

I have seen something like this happen with drivers that were based on the
sfilter.c sample that came with the Windows 2000 IFS kit. Specifically the
problem was in SfFsControl while processing a mount request in that it would
look for a device object to use (from the recognizer). All of this was to
handle detaching from the volume (as nt4.0 had a bug in that it would free
the device object and then call your dispatch routine). By removing this
code (and always creating a new one) I solved the issue. However I don’t
support NT 4.0 so I cant say what the solution for it would be. Later
versions of the IFS kit don’t even bother with this logic as it has been
removed.

This case would only happen if the system FS was FAT, otherwise the file
system recognizer stuff would not be called for NTFS (as it is implicitly
loaded by the boot loader).

I am not sure why removing the code worked or what the actual problem was,
and this was several years ago, so I may be wrong.

Thanks,
Rob

>-----Original Message-----
>From: xxxxx@lists.osr.com [mailto:bounce-ntfsd-
>xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
>Sent: Monday, July 28, 2003 3:04 PM
>To: File Systems Developers
>Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject
>
>Maybe we should take this off-line.
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
>Sent: Monday, July 28, 2003 11:07 AM
>To: File Systems Developers
>Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject
>
>Yes, I may have been a little too concise in my original post. I will
>elaborate…
>
>Our filter is built on top of OSR’s FDDK. It is through their

recognizer

>and
>filter that we do our actual work. We are both an open file manager

and

>a
>replication change filter.
>
>To answer your specific question: We are a file system filter

attaching

>to
>the media device at mount / driver load time - no problem here.
>
>What we see in a CREATE IRPs FileObject->DeviceObject is (usually -

for

>the
>last 6-yrs) the media device object mounted. On rare occasions we see
>the NTFS device - we ignore it. In this instance, we are always seeing
>the NTFS
>device. So… you can see my puzzlement.
>
>No crash, no burn, no hiccups - in fact, on this system, we aren’t

even

>filtering.
>
>My question to the group was really one of curiosity - I was just
>looking for an explanation of the phenomenon. And, I have a moderately
>half-backed
>plan for a workaround. I would however, dearly like to know how it
>happened.
>(And yes, I can accept: "Your poorly written old filter is screwing

with

>the
>system…")
>
> /ted
>
>-----Original Message-----
>From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
>Sent: Monday, July 28, 2003 1:21 PM
>To: File Systems Developers
>Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject
>
>
>You must properly state your question. You have not done this. The
>experts on this list are asking for more specific information and you
>feel

that

>it
>is not required. It is!
>
>Given that you are with LiveVault, it may be that you are trying to
>develop some sort of “open file”/snapshot software; I am not 100%
>sure, but I have
>my suspicions.
>
>We need to know how you are attaching to the device stack… Are you
>loading a disk filter driver that attaches to partitions when the
>AddDevice routine
>is called or are you writing a file system filter driver that is
>attaching
>to the disk device objects at mount time?
>
>If it is the latter, there are several problems that I know of in

doing

>this
>under NT 4.0. In my opinion, it is a bug in NT 4.0. The problems that

I

>am
>speaking of can appear to work for months and then all of a sudden,
>every system you run it on will crash; something to do with the
>distance between
>the Earth and Mars and that distance is about to reach it closest it

has

>been in almost 60,000,000 years. So, hold on to your hat and please
>answer our questions.
>
>Jamey
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
>Sent: Monday, July 28, 2003 8:24 AM
>To: File Systems Developers
>Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject
>
>Joze -
>
>The problem I was querying about has really nothing to do with what I

am

>attaching to – that part of the puzzle is correct. The problem is

what

>DeviceObject is in the FileObject being passed down from above.
>
>Please note: This anomoly showed up on an unusual configuration of one
>particular NT4.0 system. I have no other problem (in this area) with

any

>other NT4/Win200/XP/WS03 systems.
>
> /ted
>
>-----Original Message-----
>From: Joze Fabcic [mailto:xxxxx@hermes.si]
>Sent: Monday, July 28, 2003 9:34 AM
>To: File Systems Developers
>Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject
>
>
>Can you explain your way of attaching? Do you use IoDetachDevice, too?
>Do you attach to FS or storage stack?
>
>I’ve seen a crash dump where my driver received IRP from other driver
>that attached to my device. My workaround was to check device found in
>IRPs against a list of known devices and maintain usage counts for
>these devices.
>
>Joze
>
>
>-----Original Message-----
>From: Ted Hess [mailto:xxxxx@livevault.com]
>Sent: Friday, July 25, 2003 11:26 PM
>To: File Systems Developers
>Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject
>
>
>We have an NT4.0 system in our lab that has the “kitchen sink”

installed

>on
>it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
>system I have ever seen this problem on. All of our other NT4.0

systems

>are
>fine. OK, here’s the meat of the matter. After our filter is loaded

and

>we
>have attached to all the appropriate devices (usually the media object
>owned by disk/ftdisk), we build a table with some extended info on
>these devices.
>Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
>FileObject and, up until today, it has always been one that is in our
>table.
>On this one system, the DeviceObject field points to an NTFS device
>instead.
>
>My question to this group is: Has anyone seen this problem and… a)
>Knows why this is happening and what component is the cuprit or b) Has
>a workaround. There are no other filters that I can see involved here.
>What am
>I missing?
>We plan on rebuilding this system one component at a time to try and
>isolate
>the problem. I will post the results here sometime next week.
> /ted
>—
>You are currently subscribed to ntfsd as: xxxxx@hermes.si
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@livevault.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@livevault.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@cdp.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com


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


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

  • Nick Ryan (MVP for DDK)

Yes! This is an excellent suggestion. I would also get rid of a global table
and resource lock if I did this.

Thanks Nick!

/ted

-----Original Message-----
From: Nick Ryan [mailto:xxxxx@nryan.com]
Sent: Tuesday, July 29, 2003 12:42 AM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

Let’s try to approach this from another angle…

Why depend on FileObject->DeviceObject at all? Where is Microsoft
guaranteeing that this field is always going to be the storage stack?
From your original message, I gather you were using
FileObject->DeviceObject as a key into a table. Instead, why not just
hang any state associated with a filtered volume off of a device
extension you attach to your filter device object? For file I/O requests
to a filtered volume, the DeviceObject parameter of your dispatch entry
point is guaranteed to be your filter device object (and this is
documented behavior). If you need to get at the storage device stack,
remember what Vpb->RealDevice was when you intercepted the mount
request, and store this away in the device extension.

If you need to fix bugs in legacy code that can’t be heavily altered,
then it’s another issue.

Ted Hess wrote:

I’m beginning to regret ever mentioning the fact that I remember the
DO of the media device when I attach a filter device.

The question could have been quite simply put:

“On NT 4.0 – Other than when something directly opens the ntfs
device, when would one see that device (ntfs) in a
FileObject.DeviceObject field in a CREATE to a normal file on that
volume?”

Normally, this field points to the media device object - usually a
disk or ftdisk device. And, if the VPB is valid:
(FileObject->DeviceObject ==
FileObject->Vpb->RealDevice) Doesn’t it?

I’ll have this figured out in a bit (as soon as we re-build the
system) and then I’ll let you all know what we find out. Actually, I
think Jamey is right and it has more to do with the fact that Mars is
way too close…

/ted

-----Original Message-----
From: Rob Green [mailto:xxxxx@cdp.com]
Sent: Monday, July 28, 2003 5:15 PM
To: File Systems Developers
Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject

I have seen something like this happen with drivers that were based on
the sfilter.c sample that came with the Windows 2000 IFS kit.
Specifically the problem was in SfFsControl while processing a mount
request in that it would look for a device object to use (from the
recognizer). All of this was to handle detaching from the volume (as
nt4.0 had a bug in that it would free the device object and then call
your dispatch routine). By removing this code (and always creating a
new one) I solved the issue. However I don’t support NT 4.0 so I cant
say what the solution for it would be. Later versions of the IFS kit
don’t even bother with this logic as it has been removed.

This case would only happen if the system FS was FAT, otherwise the
file system recognizer stuff would not be called for NTFS (as it is
implicitly loaded by the boot loader).

I am not sure why removing the code worked or what the actual problem
was, and this was several years ago, so I may be wrong.

Thanks,
Rob

>-----Original Message-----
>From: xxxxx@lists.osr.com [mailto:bounce-ntfsd-
>xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
>Sent: Monday, July 28, 2003 3:04 PM
>To: File Systems Developers
>Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject
>
>Maybe we should take this off-line.
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
>Sent: Monday, July 28, 2003 11:07 AM
>To: File Systems Developers
>Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject
>
>Yes, I may have been a little too concise in my original post. I will
>elaborate…
>
>Our filter is built on top of OSR’s FDDK. It is through their

recognizer

>and
>filter that we do our actual work. We are both an open file manager

and

>a
>replication change filter.
>
>To answer your specific question: We are a file system filter

attaching

>to
>the media device at mount / driver load time - no problem here.
>
>What we see in a CREATE IRPs FileObject->DeviceObject is (usually -

for

>the
>last 6-yrs) the media device object mounted. On rare occasions we see
>the NTFS device - we ignore it. In this instance, we are always seeing
>the NTFS
>device. So… you can see my puzzlement.
>
>No crash, no burn, no hiccups - in fact, on this system, we aren’t

even

>filtering.
>
>My question to the group was really one of curiosity - I was just
>looking for an explanation of the phenomenon. And, I have a moderately
>half-backed
>plan for a workaround. I would however, dearly like to know how it
>happened.
>(And yes, I can accept: "Your poorly written old filter is screwing

with

>the
>system…")
>
> /ted
>
>-----Original Message-----
>From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
>Sent: Monday, July 28, 2003 1:21 PM
>To: File Systems Developers
>Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject
>
>
>You must properly state your question. You have not done this. The
>experts on this list are asking for more specific information and you
>feel

that

>it
>is not required. It is!
>
>Given that you are with LiveVault, it may be that you are trying to
>develop some sort of “open file”/snapshot software; I am not 100%
>sure, but I have
>my suspicions.
>
>We need to know how you are attaching to the device stack… Are you
>loading a disk filter driver that attaches to partitions when the
>AddDevice routine
>is called or are you writing a file system filter driver that is
>attaching
>to the disk device objects at mount time?
>
>If it is the latter, there are several problems that I know of in

doing

>this
>under NT 4.0. In my opinion, it is a bug in NT 4.0. The problems that

I

>am
>speaking of can appear to work for months and then all of a sudden,
>every system you run it on will crash; something to do with the
>distance between
>the Earth and Mars and that distance is about to reach it closest it

has

>been in almost 60,000,000 years. So, hold on to your hat and please
>answer our questions.
>
>Jamey
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
>Sent: Monday, July 28, 2003 8:24 AM
>To: File Systems Developers
>Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject
>
>Joze -
>
>The problem I was querying about has really nothing to do with what I

am

>attaching to – that part of the puzzle is correct. The problem is

what

>DeviceObject is in the FileObject being passed down from above.
>
>Please note: This anomoly showed up on an unusual configuration of one
>particular NT4.0 system. I have no other problem (in this area) with

any

>other NT4/Win200/XP/WS03 systems.
>
> /ted
>
>-----Original Message-----
>From: Joze Fabcic [mailto:xxxxx@hermes.si]
>Sent: Monday, July 28, 2003 9:34 AM
>To: File Systems Developers
>Subject: [ntfsd] RE: Problem with NT4.0 FileObject.DeviceObject
>
>
>Can you explain your way of attaching? Do you use IoDetachDevice, too?
>Do you attach to FS or storage stack?
>
>I’ve seen a crash dump where my driver received IRP from other driver
>that attached to my device. My workaround was to check device found in
>IRPs against a list of known devices and maintain usage counts for
>these devices.
>
>Joze
>
>
>-----Original Message-----
>From: Ted Hess [mailto:xxxxx@livevault.com]
>Sent: Friday, July 25, 2003 11:26 PM
>To: File Systems Developers
>Subject: [ntfsd] Problem with NT4.0 FileObject.DeviceObject
>
>
>We have an NT4.0 system in our lab that has the “kitchen sink”

installed

>on
>it (Exchange, SQL, BackOffice, Site Server, IIS, etc.). It is the only
>system I have ever seen this problem on. All of our other NT4.0

systems

>are
>fine. OK, here’s the meat of the matter. After our filter is loaded

and

>we
>have attached to all the appropriate devices (usually the media object
>owned by disk/ftdisk), we build a table with some extended info on
>these devices.
>Whenever, we receive a CREATE IRP, we lookup the DeviceObject in the
>FileObject and, up until today, it has always been one that is in our
>table.
>On this one system, the DeviceObject field points to an NTFS device
>instead.
>
>My question to this group is: Has anyone seen this problem and… a)
>Knows why this is happening and what component is the cuprit or b) Has
>a workaround. There are no other filters that I can see involved here.
>What am
>I missing?
>We plan on rebuilding this system one component at a time to try and
>isolate
>the problem. I will post the results here sometime next week.
> /ted
>—
>You are currently subscribed to ntfsd as: xxxxx@hermes.si
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@livevault.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@livevault.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@cdp.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com


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


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

  • Nick Ryan (MVP for DDK)

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