Hi Everyone,
We have finally found a case where it would be the most
efficient to roll our own IRPs to send to the filesystem.
Basically, our driver needs to open a file (IRP_MJ_CREATE),
get some basic information (IRP_MJ_GET_INFORMATION),
then close (IRP_MJ_CLOSE).
Is there any sample code out there that I can look at?
I have everything working except the IRP_MJ_CREATE’s
as they work about 95% of the time and BSOD the other 5%.
Thanks,
Duane
Duane Souder wrote:
Hi Everyone,
We have finally found a case where it would be the most
efficient to roll our own IRPs to send to the filesystem. Basically,
…
I have everything working except the IRP_MJ_CREATE’s
as they work about 95% of the time and BSOD the other 5%.
>
Rolling your own general-purpose IRPs and rolling your own CREATES
(making them out of whole cloth) are two very different animals.
Rolling your own IRP_MJ_CREATE is *very* difficult. I’ve done it in a
previous version of Windows (was it back in NT V4 or was it Win2K?? I
can’t remember), and I would never like to either repeat the experience
or depend on that code for general purpose use. As soon as I was able
(because of some added support in Windows) I replaced the code and
shredded my development notes.
I honestly don’t think that it’s practical to roll your own creates.
Seriously. There are just sooooo many screw cases, and sooo much that’s
undocumented. The security-related issues alone are daunting.
So… Sorry, I’m sure that’s not the answer you wanted to hear. But I
don’t think we’d ever roll our own creates again. Well, not unless
there was absolutely no alternative at all, and the payoff was tremendous.
Peter
OSR
> Rolling your own IRP_MJ_CREATE is *very* difficult. I’ve done it in a
previous version of Windows (was it back in NT V4 or was it Win2K?? I
can’t remember), and I would never like to either repeat the experience
or depend on that code for general purpose use. As soon as I was able
(because of some added support in Windows) I replaced the code and
shredded my development notes.
I would like to add the the “added support” probably means
the IoCreateFileSpecifyDeviceObjectHint API, which is
the function you want. Although thi API is now available
on WinXP only, wait a month or two, Microsoft prepares a patch
which will make this API available on Win2000 too.
In the middletime, you can read an article at osronline.com
about this API (from last year’s NT Insider), it may
give you more hints about this API ana eventual
replace.
L.
Thanks…I saw this API mentioned a month or so ago…but I need this
to work on
NT 4.0 SP6a, and all flavors of 2K-XP also. Further, we can’t be sure
that any
given customer will have this Windows fix installed on their machines
either.
So, has anyone been successful using existing fields of an IRP_MJ_CREATE
that just
arrived in your driver, such as the FileObject, in rolling your own
IRP_MJ_CREATE?
Thanks again !
Duane
Ladislav Zezula wrote:
> Rolling your own IRP_MJ_CREATE is *very* difficult. I’ve done it in
> a previous version of Windows (was it back in NT V4 or was it
> Win2K?? I can’t remember), and I would never like to either repeat
> the experience or depend on that code for general purpose use. As
> soon as I was able (because of some added support in Windows) I
> replaced the code and shredded my development notes.I would like to add the the “added support” probably means the
IoCreateFileSpecifyDeviceObjectHint API, which is
the function you want. Although thi API is now available
on WinXP only, wait a month or two, Microsoft prepares a patch
which will make this API available on Win2000 too.In the middletime, you can read an article at osronline.com
about this API (from last year’s NT Insider), it may
give you more hints about this API ana eventual
replace.L.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17You are currently subscribed to ntfsd as: xxxxx@cisco.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Duane,
Yes, people have successfully rolled their own nested Create IRPs, and
maintained that capability for extended periods of time in shipping code.
No, you don’t want to go there. You’ll end up doing a fair amount of
reverse-engineering, to find the right undocumented routines to call, some
of which are version dependent.
You seem to imply that you’re willing to re-use the original file object,
and don’t need a separate one (e.g., via IoCreateStreamFileObject). If that
is the case, then what is the requirement for the nested Create?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Duane Souder
Sent: Thursday, September 16, 2004 9:10 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Rolling your own IRPs
Thanks…I saw this API mentioned a month or so ago…but I need this
to work on
NT 4.0 SP6a, and all flavors of 2K-XP also. Further, we can’t be sure
that any
given customer will have this Windows fix installed on their machines
either.
So, has anyone been successful using existing fields of an IRP_MJ_CREATE
that just
arrived in your driver, such as the FileObject, in rolling your own
IRP_MJ_CREATE?
Thanks again !
Duane
Ladislav Zezula wrote:
> Rolling your own IRP_MJ_CREATE is *very* difficult. I’ve done it in
> a previous version of Windows (was it back in NT V4 or was it
> Win2K?? I can’t remember), and I would never like to either repeat
> the experience or depend on that code for general purpose use. As
> soon as I was able (because of some added support in Windows) I
> replaced the code and shredded my development notes.I would like to add the the “added support” probably means the
IoCreateFileSpecifyDeviceObjectHint API, which is
the function you want. Although thi API is now available
on WinXP only, wait a month or two, Microsoft prepares a patch
which will make this API available on Win2000 too.In the middletime, you can read an article at osronline.com
about this API (from last year’s NT Insider), it may
give you more hints about this API ana eventual
replace.L.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17You are currently subscribed to ntfsd as: xxxxx@cisco.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@cox.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
The article we wrote in The NT Insider on building this for Windows 2000
and the technique described there can be made to work on NT 4.0.
http://www.osronline.com/article.cfm?id=258
This is preferable to trying to build your own create IRPs because
long-term you will be able to phase out this code…
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Duane Souder
Sent: Thursday, September 16, 2004 12:10 PM
To: ntfsd redirect
Subject: Re: [ntfsd] Rolling your own IRPs
Thanks…I saw this API mentioned a month or so ago…but I need this
to work on
NT 4.0 SP6a, and all flavors of 2K-XP also. Further, we can’t be sure
that any
given customer will have this Windows fix installed on their machines
either.
So, has anyone been successful using existing fields of an IRP_MJ_CREATE
that just
arrived in your driver, such as the FileObject, in rolling your own
IRP_MJ_CREATE?
Thanks again !
Duane
Ladislav Zezula wrote:
> Rolling your own IRP_MJ_CREATE is *very* difficult. I’ve done it in
> a previous version of Windows (was it back in NT V4 or was it
> Win2K?? I can’t remember), and I would never like to either repeat
> the experience or depend on that code for general purpose use. As
> soon as I was able (because of some added support in Windows) I
> replaced the code and shredded my development notes.I would like to add the the “added support” probably means the
IoCreateFileSpecifyDeviceObjectHint API, which is
the function you want. Although thi API is now available
on WinXP only, wait a month or two, Microsoft prepares a patch
which will make this API available on Win2000 too.In the middletime, you can read an article at osronline.com
about this API (from last year’s NT Insider), it may
give you more hints about this API ana eventual
replace.L.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17You are currently subscribed to ntfsd as: xxxxx@cisco.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Tony,
The article we wrote in The NT Insider on building this for Windows 2000
and the technique described there can be made to work on NT 4.0.
Right. But I remember, that you once wrote here that the ZwCreateFile
(sugested in the article) should not be used within IRP_MJ_CREATE
handler. Is that true in the case of the above-mentioned technique too ?
I remember that I experimented with it and it worked, but I observed
a significant system performance downgrade.
L.
I generally suggest avoiding ZwCreateFile calls within an IRP_MJ_CREATE
handler because of the very reentrancy issues Neal pointed out in his
e-mails. However, if the purpose of calling ZwCreateFile is to avoid
re-entrancy this should not be a problem.
As to system degradation, that does not match our observations (well, no
more than ANY file system filter driver). Perhaps it was something
specific to your implementation?
Regards,
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Friday, September 17, 2004 1:05 AM
To: ntfsd redirect
Subject: Re: [ntfsd] Rolling your own IRPs
Tony,
The article we wrote in The NT Insider on building this for Windows
2000
and the technique described there can be made to work on NT 4.0.
Right. But I remember, that you once wrote here that the ZwCreateFile
(sugested in the article) should not be used within IRP_MJ_CREATE
handler. Is that true in the case of the above-mentioned technique too ?
I remember that I experimented with it and it worked, but I observed
a significant system performance downgrade.
L.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> As to system degradation, that does not match our observations (well, no
more than ANY file system filter driver). Perhaps it was something
specific to your implementation?
Nothing specific - imagine an antivirus, which will
intercept every file create/open, calls one additional
ZwCreateFile, reads (noncached) the first 0x200
bytes and then closes the file and sends the original request
down. The greatest difference which I observed
was in the moment of “Rebuild all” in MS Visual C++,
which as I know is quite good testing point for file
system filters.
But maybe it was because of missing optimization
Because it was not a serious project
(it was more like a playing after the OSR article
has been released), maybe my conclusion was premature.
L.