What is the deal with IRP_MJ_CREATE?

NTFSD
1

I have been developing a bit of a file system driver here, and
this IRP is giving me a hard time. My filter is more of a
monitoring project (similar to filemon). All I would like it
to do DbgPrint out data from the IRP’s passing by.
Unfortunately something I am doing in my code is blocking
normal function of the Filesystem. I am attaching to my G:
partition and can tell when I am, since all of a sudden, the
G: drive appears, but has no functionality. I think it may be
broken in my IRP_MJ_CREATE function because i get repeated
IRP_MJ_CREATE IRPS when it tries to use the G: device. As of
now I have a minimal function:

NTSTATUS FileIOMicCreate(PDEVICE_OBJECT DeviceObject,
PIRP Irp){
PDEVICE_EXTENSION deviceExtension;

deviceExtension = (PDEVICE_EXTENSION)
DeviceObject->DeviceExtension;
printdbgs((“IRP_MJ_CREATE\n”));
PrintIrpInfo(Irp);
if(deviceExtension->started == DEVICE_STARTED) {
printdbg((“skipping…\n”));
IoSkipCurrentIrpStackLocation(Irp);
return IoCallDriver(deviceExtension->nextInStack, Irp);
} else {
printdbg((“completeing…\n”));
Irp->IoStatus.Status = STATUS_SUCCESS;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}
}

If someone could explain to me the proper use of IRP_MJ_CREATE
I would be very grateful.

Thanks,
J.J.

2

While you’ve decided to spam both NTDEV and NTFSD in contravention of
the forum rules, it’s probably indicative of your coding style as well
(“break the rules, nobody cares…”)

Were I to guess, I’d bet that the if clause is never triggered and
you’re always hitting the second (“always return success”) case. No
doubt that creates some interesting problems.

Have you considered writing a mini-filter?

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 xxxxx@uiuc.edu
Sent: Friday, June 09, 2006 3:27 PM
To: ntfsd redirect
Subject: [ntfsd] What is the deal with IRP_MJ_CREATE?

I have been developing a bit of a file system driver here, and
this IRP is giving me a hard time. My filter is more of a
monitoring project (similar to filemon). All I would like it
to do DbgPrint out data from the IRP’s passing by.
Unfortunately something I am doing in my code is blocking
normal function of the Filesystem. I am attaching to my G:
partition and can tell when I am, since all of a sudden, the
G: drive appears, but has no functionality. I think it may be
broken in my IRP_MJ_CREATE function because i get repeated
IRP_MJ_CREATE IRPS when it tries to use the G: device. As of
now I have a minimal function:

NTSTATUS FileIOMicCreate(PDEVICE_OBJECT DeviceObject,
PIRP Irp){
PDEVICE_EXTENSION deviceExtension;

deviceExtension = (PDEVICE_EXTENSION)
DeviceObject->DeviceExtension;
printdbgs((“IRP_MJ_CREATE\n”));
PrintIrpInfo(Irp);
if(deviceExtension->started == DEVICE_STARTED) {
printdbg((“skipping…\n”));
IoSkipCurrentIrpStackLocation(Irp);
return IoCallDriver(deviceExtension->nextInStack, Irp);
} else {
printdbg((“completeing…\n”));
Irp->IoStatus.Status = STATUS_SUCCESS;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}
}

If someone could explain to me the proper use of IRP_MJ_CREATE
I would be very grateful.

Thanks,
J.J.

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

3

If you are actually completing the Irp’s in your filter, without passing
them down, then this is the problem.

If you are simply monitoring the information, then always pass the Irp down
to the underlying filesystem. You would only want to complete it in your
filter if 1) You own the file instance and can handle all subsequent
requests to it, 2) You are failing it due to some metric being met within
your architecture.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-253670-
xxxxx@lists.osr.com] On Behalf Of xxxxx@uiuc.edu
Sent: Friday, June 09, 2006 1:27 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] What is the deal with IRP_MJ_CREATE?

I have been developing a bit of a file system driver here, and
this IRP is giving me a hard time. My filter is more of a
monitoring project (similar to filemon). All I would like it
to do DbgPrint out data from the IRP’s passing by.
Unfortunately something I am doing in my code is blocking
normal function of the Filesystem. I am attaching to my G:
partition and can tell when I am, since all of a sudden, the
G: drive appears, but has no functionality. I think it may be
broken in my IRP_MJ_CREATE function because i get repeated
IRP_MJ_CREATE IRPS when it tries to use the G: device. As of
now I have a minimal function:

NTSTATUS FileIOMicCreate(PDEVICE_OBJECT DeviceObject,
PIRP Irp){
PDEVICE_EXTENSION deviceExtension;

deviceExtension = (PDEVICE_EXTENSION)
DeviceObject->DeviceExtension;
printdbgs((“IRP_MJ_CREATE\n”));
PrintIrpInfo(Irp);
if(deviceExtension->started == DEVICE_STARTED) {
printdbg((“skipping…\n”));
IoSkipCurrentIrpStackLocation(Irp);
return IoCallDriver(deviceExtension->nextInStack, Irp);
} else {
printdbg((“completeing…\n”));
Irp->IoStatus.Status = STATUS_SUCCESS;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}
}

If someone could explain to me the proper use of IRP_MJ_CREATE
I would be very grateful.

Thanks,
J.J.

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

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

4

Alright, I’m glad I at least did understand most of what I was
doing. If my driver was doing what you said, I would
understand why I have problems, however, it is always taking
the first path in the IF statement. Which, to my understanding
correctly passes down the IRP to the next device.
(deviceExtension->nextInStack is set to the return value of
IoAttachDeviceToStack)

I have no functions except this one that even attempt to
complete an IRP. Is that wrong? How would I tell if an IRP was
meant for me to complete rather than should be passed down?
Which IRP_MJ_'s are the IRP’s in which I might be given an IRP
meant for my filter?

Thanks,
J.J.

P.S. I am sorry about the spamming, I accidently allowed my
email client to auto-complete to the wrong address.

5

Sorry for not responding to your question Tony,

I have not considered writing a mini-filter…What would be
the benefit to that?

J.J.

6

Please study the IFS Kit / WDK and the samples for these very basic
questions; it isnt rocket science after all.

wrote in message news:xxxxx@ntfsd…
> Alright, I’m glad I at least did understand most of what I was
> doing. If my driver was doing what you said, I would
> understand why I have problems, however, it is always taking
> the first path in the IF statement. Which, to my understanding
> correctly passes down the IRP to the next device.
> (deviceExtension->nextInStack is set to the return value of
> IoAttachDeviceToStack)
>
> I have no functions except this one that even attempt to
> complete an IRP. Is that wrong? How would I tell if an IRP was
> meant for me to complete rather than should be passed down?
> Which IRP_MJ_'s are the IRP’s in which I might be given an IRP
> meant for my filter?
>
> Thanks,
> J.J.
>
> P.S. I am sorry about the spamming, I accidently allowed my
> email client to auto-complete to the wrong address.
>

7

Please compare the amount of code in the filespy and minispy samples in the
IFS KIT / WDK for example. The minifilter model is the Microsoft recommended
model for file system filter drivers.

In addition there was an NT INSIDER article on the very subject not so long
ago.

wrote in message news:xxxxx@ntfsd…
> Sorry for not responding to your question Tony,
>
> I have not considered writing a mini-filter…What would be
> the benefit to that?
>
> J.J.
>

8

xxxxx@uiuc.edu wrote:

I have not considered writing a mini-filter…What would be
the benefit to that?

lots of reasons, some that immediately come to mind are:

  1. Minifilters can be unloaded - during development this is awesome, it
    saves you reboot time. In a commercial environment, you can update a
    product without making the user reboot.

  2. Stream and StreamHandle tracking is made easy. These two features let
    you know when a fileobject or FCB is being torn-down. That is useful in
    many ways. Furthermore, file names are only guaranteed in pre-create, with
    this easy to use stream tracking model, you can add the filename to the
    stream context and retrieve it in all IRP operations.

  3. Your filter has a guaranteed altitude against other filter drivers.

  4. You can open and read/write to a file with out re-entry problems.
    (all IO is sent below and not to the top of the stack)

  5. Less code, less opertunities to make a fatal coding error - you only
    register for call-backs that your interested in.

  6. Supported in W2k and Up.

  7. Kernel/Userland communication made easy with FltSendMessage/
    FltGetMessage and FilterSendMessage / FilterGetMessage.
    No hassling with IOCTL’s or other kernel/user communication methods.

  8. it’s easy to do so many other things, like setting reparse points on
    files or directories. Filename and drive letter stuff is super easy.

  9. attaching to volumes, drives, net shares are pretty much automatic.

There are a lot of reasons to use a minifilter over a legacy model.
MiniFilters are now the supported and correct way to write FSF’s.

There are some caveat’s to the points above, but your going to have to
study and figure out what those caveats are yourself. The advantages
are clear, and you should pursue this model.

Good Luck
m

9

From what i have heard though with minifilters you will not be able to
detect execution of for example .exe files, i have tried to use the examples
in the ifs kit and was not possible to see the execution of them. I am not
an expert though, but i trust my sources of information.

On 6/10/06, MM wrote:
>
>
>
> xxxxx@uiuc.edu wrote:
>
> >
> >I have not considered writing a mini-filter…What would be
> >the benefit to that?
> >
> >
> lots of reasons, some that immediately come to mind are:
>
>
> 1. Minifilters can be unloaded - during development this is awesome, it
> saves you reboot time. In a commercial environment, you can update a
> product without making the user reboot.
>
> 2. Stream and StreamHandle tracking is made easy. These two features let
> you know when a fileobject or FCB is being torn-down. That is useful in
> many ways. Furthermore, file names are only guaranteed in pre-create, with
> this easy to use stream tracking model, you can add the filename to the
> stream context and retrieve it in all IRP operations.
>
> 3. Your filter has a guaranteed altitude against other filter drivers.
>
> 4. You can open and read/write to a file with out re-entry problems.
> (all IO is sent below and not to the top of the stack)
>
> 5. Less code, less opertunities to make a fatal coding error - you only
> register for call-backs that your interested in.
>
> 6. Supported in W2k and Up.
>
> 7. Kernel/Userland communication made easy with FltSendMessage/
> FltGetMessage and FilterSendMessage / FilterGetMessage.
> No hassling with IOCTL’s or other kernel/user communication methods.
>
> 8. it’s easy to do so many other things, like setting reparse points on
> files or directories. Filename and drive letter stuff is super easy.
>
> 9. attaching to volumes, drives, net shares are pretty much automatic.
>
> There are a lot of reasons to use a minifilter over a legacy model.
> MiniFilters are now the supported and correct way to write FSF’s.
>
> There are some caveat’s to the points above, but your going to have to
> study and figure out what those caveats are yourself. The advantages
> are clear, and you should pursue this model.
>
> Good Luck
> m
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

10

Well, your trusted sources of information are full of shit. What a
stupid idea to purvey.

Faik Riza wrote:

>From what i have heard though with minifilters you will not be able
to detect execution of for example .exe files, i have tried to use the
examples in the ifs kit and was not possible to see the execution of
them. I am not an expert though, but i trust my sources of information.

On 6/10/06, *MM* > mailto:xxxxx> wrote:
>
>
>
> xxxxx@uiuc.edu mailto:xxxxx wrote:
>
> >
> >I have not considered writing a mini-filter…What would be
> >the benefit to that?
> >
> >
> lots of reasons, some that immediately come to mind are:
>
>
> 1. Minifilters can be unloaded - during development this is
> awesome, it
> saves you reboot time. In a commercial environment, you can update a
> product without making the user reboot.
>
> 2. Stream and StreamHandle tracking is made easy. These two
> features let
> you know when a fileobject or FCB is being torn-down. That is
> useful in
> many ways. Furthermore, file names are only guaranteed in
> pre-create, with
> this easy to use stream tracking model, you can add the filename
> to the
> stream context and retrieve it in all IRP operations.
>
> 3. Your filter has a guaranteed altitude against other filter drivers.
>
> 4. You can open and read/write to a file with out re-entry problems.
> (all IO is sent below and not to the top of the stack)
>
> 5. Less code, less opertunities to make a fatal coding error - you
> only
> register for call-backs that your interested in.
>
> 6. Supported in W2k and Up.
>
> 7. Kernel/Userland communication made easy with FltSendMessage/
> FltGetMessage and FilterSendMessage / FilterGetMessage.
> No hassling with IOCTL’s or other kernel/user communication methods.
>
> 8. it’s easy to do so many other things, like setting reparse
> points on
> files or directories. Filename and drive letter stuff is super easy.
>
> 9. attaching to volumes, drives, net shares are pretty much automatic.
>
> There are a lot of reasons to use a minifilter over a legacy model.
> MiniFilters are now the supported and correct way to write FSF’s.
>
> There are some caveat’s to the points above, but your going to have to
> study and figure out what those caveats are yourself. The advantages
> are clear, and you should pursue this model.
>
> Good Luck
> m
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> mailto:xxxxx
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> mailto:xxxxx
>
>
> — Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17 You are currently
> subscribed to ntfsd as: xxxxx@comcast.net To unsubscribe send a
> blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

11

It is just as ‘easy’ to detect file execution in a mini-filter vs. a legacy
style filter. The functionality required to do this is outside of the scope
of functionality which the mini-filter provides.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Faik Riza
Sent: Saturday, June 10, 2006 6:51 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] What is the deal with IRP_MJ_CREATE?

From what i have heard though with minifilters you will not be able to
detect execution of for example .exe files, i have tried to use the examples
in the ifs kit and was not possible to see the execution of them. I am not
an expert though, but i trust my sources of information.

On 6/10/06, MM wrote:

xxxxx@uiuc.edu wrote:

>
>I have not considered writing a mini-filter…What would be
>the benefit to that?
>
>
lots of reasons, some that immediately come to mind are:

1. Minifilters can be unloaded - during development this is awesome, it
saves you reboot time. In a commercial environment, you can update a
product without making the user reboot.

2. Stream and StreamHandle tracking is made easy. These two features let
you know when a fileobject or FCB is being torn-down. That is useful in
many ways. Furthermore, file names are only guaranteed in pre-create, with
this easy to use stream tracking model, you can add the filename to the
stream context and retrieve it in all IRP operations.

3. Your filter has a guaranteed altitude against other filter drivers.

4. You can open and read/write to a file with out re-entry problems.
(all IO is sent below and not to the top of the stack)

5. Less code, less opertunities to make a fatal coding error - you only
register for call-backs that your interested in.

6. Supported in W2k and Up.

7. Kernel/Userland communication made easy with FltSendMessage/
FltGetMessage and FilterSendMessage / FilterGetMessage.
No hassling with IOCTL’s or other kernel/user communication methods.

8. it’s easy to do so many other things, like setting reparse points on
files or directories. Filename and drive letter stuff is super easy.

9. attaching to volumes, drives, net shares are pretty much automatic.

There are a lot of reasons to use a minifilter over a legacy model.
MiniFilters are now the supported and correct way to write FSF’s.

There are some caveat’s to the points above, but your going to have to
study and figure out what those caveats are yourself. The advantages
are clear, and you should pursue this model.

Good Luck
m

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

You are currently subscribed to ntfsd as: xxxxx@gmail.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@kerneldrivers.com To unsubscribe send a blank email to
xxxxx@lists.osr.com