Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

IRP_MJ_CREATE - IRQL of Pre and Post Handlers?

Jesse_Conn-2Jesse_Conn-2 Member - All Emails Posts: 42
Struggling to find consistent documentation on what IRQL the pre and post IRP_MJ_CREATE handlers are called at. What I need to do is call some PASSIVE_LEVEL only routines on the create path, and I'm trying to determine if I need to defer the work to a passive level worker, or if I can call the routines directly in the handlers.

Is the following true?
"If a minifilter driver has registered preoperation and postoperation callback routines for IRP_MJ_CREATE operations, the post-create callback routine is called at IRQL = PASSIVE_LEVEL, in the same thread context as the pre-create callback routine."

The MSDN documentation led me to believe that pre-routines can be called at both PASSIVE_LEVEL and APC_LEVEL. Is this true though for the Create pre routine, or will the create pre only be called at PASSIVE_LEVEL? If the create pre can be called at APC_LEVEL, I don't understand how the previous statement could be true. If it's running in the same thread context as the pre-create, which may be at APC_LEVEL, then the post routine would also be running at APC_LEVEL....

Comments

  • Jesse_Conn-2Jesse_Conn-2 Member - All Emails Posts: 42
    I did find the following necro thread which somewhat discusses this, but does not clarify the IRQL of the Pre-Create routine: http://www.osronline.com/showthread.cfm?link=136072
    Rather large discussion for something that should be pretty clear, I still can't decipher an answer.
  • Slava_ImameevSlava_Imameev Member Posts: 480
    IRP_MJ_CREATE is always sent at PASSIVE_LEVEL by IO manager. You can consider this as a design feature. If you observe IRP_MJ_CREATE at APC_LEVEL you can bet there is a faulty driver in the system.

    FilterManager guaranties that post callback is also called at PASSIVE_LEVEL.
  • Jesse_Conn-2Jesse_Conn-2 Member - All Emails Posts: 42
    Okay! That being said, a misbehaving higher level filter driver could pend and raise the IRQL.... I suppose defensively I could detect that condition, and lower the IRQL myself. This may cause issues in the faulty filter, but at least I get to operate as planned?
  • Slava_ImameevSlava_Imameev Member Posts: 480
    There is no code flow at APC_LEVEL that results in issuing IRP_MJ_CREATE . This provides a guarantee of PASSIVE_LEVEL for IRP_MJ_CREATE.
  • Slava_ImameevSlava_Imameev Member Posts: 480
    <QUOTE>
    I suppose defensively I could detect that condition, and lower the IRQL myself
    </QUOTE>

    You must not lower IRQL if you have not raised it. If you detected a wrong condition complete request with an error.
  • anatoly_mikhailovanatoly_mikhailov Member Posts: 217
    Some requests are synchronous and other are asynchronous. IRP_MJ_CREATE
    request is synchronous one. That means a thread sent this request will
    block until this request is completed. IRP_MJ_CREATE request is sent always
    at PASSIVE_LEVEL. For this reason all filters forward request down the
    stack and wait for event to be signaled on request completion by all lower
    drivers of the stack. Thus before forwarding you are at PASSIVE_LEVEL and
    after request completion by lower drivers you are at PASSIVE_LEVEL again.
    No one forward this request at IRQL above PASSIVE_LEVEL because this leads
    to faulty behavior of FSD first of all. You can queue work to some thread
    to continue request processing. But it'll be at PASSIVE_LEVEL again. This
    is what filters usually do including filter manager. So you can be sure
    your pre and post routines would be called at PASSIVE_LEVEL.

    2016-10-31 21:42 GMT+03:00 :

    > Struggling to find consistent documentation on what IRQL the pre and post
    > IRP_MJ_CREATE handlers are called at. What I need to do is call some
    > PASSIVE_LEVEL only routines on the create path, and I'm trying to determine
    > if I need to defer the work to a passive level worker, or if I can call the
    > routines directly in the handlers.
    >
    > Is the following true?
    > "If a minifilter driver has registered preoperation and postoperation
    > callback routines for IRP_MJ_CREATE operations, the post-create callback
    > routine is called at IRQL = PASSIVE_LEVEL, in the same thread context as
    > the pre-create callback routine."
    >
    > The MSDN documentation led me to believe that pre-routines can be called
    > at both PASSIVE_LEVEL and APC_LEVEL. Is this true though for the Create pre
    > routine, or will the create pre only be called at PASSIVE_LEVEL? If the
    > create pre can be called at APC_LEVEL, I don't understand how the previous
    > statement could be true. If it's running in the same thread context as the
    > pre-create, which may be at APC_LEVEL, then the post routine would also be
    > running at APC_LEVEL....
    >
    >
    >
    > ---
    > NTFSD is sponsored by OSR
    >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer&gt;
    >
  • anatoly_mikhailovanatoly_mikhailov Member Posts: 217

    That being said, a misbehaving higher level filter driver could pend and
    raise the IRQL.... I suppose defensively I could detect that condition, and
    lower the IRQL myself.


    You will queue work to a thread if you want to be protected from such
    drivers. But in my practice i never saw this. As it was told by slavaim you
    can't lower IRQL if you didn't raise it.
  • Slava_ImameevSlava_Imameev Member Posts: 480
    <QUOTE>
    You will queue work to a thread if you want to be protected from such drivers.
    </QUOTE>

    This might not work with some FSDs. Network redirectors( e.g. RDPDR and Citrix ) might associate session information with a user process. If they are called in SYSTEM thread context for create request then PATH_NOT_FOUND is returned. KeStackAttachProcess might help but it is beyond this discussion.
  • Jesse_Conn-2Jesse_Conn-2 Member - All Emails Posts: 42
    Trying not to get wrapped up in this worst case scenario, so please add some clarification to this.

    Could a faulty driver that would raise the IRQL in the create path seemingly operate on a system with no obvious side effects, and only cause an error in my filter, thus making my driver appear to be at fault... or will it be obvious the other driver is at fault?

    As for the "thou shall not lower IRQL if you did not raise it", the same goes for "thou shall not raise the irql in the create path, and not lower it to the previous before passing it along the stack". The fatal design flaw was in the faulty driver.

    https://msdn.microsoft.com/en-us/library/windows/hardware/ff537942(v=vs.85).aspx
    This shows what I believe to be a valid example of safely lowering the IRQL? Would it really be so terrible to correct the fault of a driver up the stack, as opposed to just erroring out?
  • anatoly_mikhailovanatoly_mikhailov Member Posts: 217
    Floating-point is a special case. You should study IRQL role first. If you
    lower IRQL you can for example cause deadlock.

    2016-10-31 22:59 GMT+03:00 :

    > Trying not to get wrapped up in this worst case scenario, so please add
    > some clarification to this.
    >
    > Could a faulty driver that would raise the IRQL in the create path
    > seemingly operate on a system with no obvious side effects, and only cause
    > an error in my filter, thus making my driver appear to be at fault... or
    > will it be obvious the other driver is at fault?
    >
    > As for the "thou shall not lower IRQL if you did not raise it", the same
    > goes for "thou shall not raise the irql in the create path, and not lower
    > it to the previous before passing it along the stack". The fatal design
    > flaw was in the faulty driver.
    >
    > https://msdn.microsoft.com/en-us/library/windows/hardware/
    > ff537942%28v=vs.85%29.aspx
    > This shows what I believe to be a valid example of safely lowering the
    > IRQL? Would it really be so terrible to correct the fault of a driver up
    > the stack, as opposed to just erroring out?
    >
    >
    > ---
    > NTFSD is sponsored by OSR
    >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer&gt;
    >
  • Jesse_Conn-2Jesse_Conn-2 Member - All Emails Posts: 42
    So you don't support or condone this code in a PreCreate handler? I agree this should largely not even need to be present, but I have seen several posts by people who have allegedly seen the PreCreate handler called at IRQL > PASSIVE_LEVEL. This seems to be completely insane to have to consider this case. The implications of defensively coding everything because you can't trust what's running the kernel seems ludicrous.

    FLT_ASSERT(PASSIVE_LEVEL == KeGetCurrentIrql());
    if (PASSIVE_LEVEL != KeGetCurrentIrql()) {
    //
    // By design the IO manager should call this at PASSIVE_LEVEL; however, a faulty driver in the
    // stack could elevate the IRQ level which would cause us to fault in our below routines.
    // Allegedly the only sane thing to do is to add the complexity of deferring this processing
    // to a passive level worker thread... but this condition would cause a general instability of
    // the file system.
    //

    // TODO: Log this error condition!!!
    // TODO: if we ever see the condition, defer processing to a PASSIVE_LEVEL worker

    //
    // Hack here, though this is just cleaning up the faulty state set by a previous faulty driver.
    //
    KeLowerIrql(PASSIVE_LEVEL);
    }
  • anatoly_mikhailovanatoly_mikhailov Member Posts: 217
    There must not be such implementations of preCreate you just showed.

    > but I have seen several posts by people who have allegedly seen the
    PreCreate handler called at IRQL > PASSIVE_LEVEL
    >
    Could they make mistake? I think yes.
  • Jesse_Conn-2Jesse_Conn-2 Member - All Emails Posts: 42
    Thanks again for the added clarity!
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    <quote>
    So you don't support or condone this code in a PreCreate handler? I agree this should largely not even need to be present, but I have seen several posts by people who have allegedly seen the PreCreate handler called at IRQL > PASSIVE_LEVEL. This seems to be completely insane to have to consider this case. The implications of defensively coding everything because you can't trust what's running the kernel seems ludicrous.

    FLT_ASSERT(PASSIVE_LEVEL == KeGetCurrentIrql());
    if (PASSIVE_LEVEL != KeGetCurrentIrql()) {
    //
    // By design the IO manager should call this at PASSIVE_LEVEL; however, a faulty driver in the
    // stack could elevate the IRQ level which would cause us to fault in our below routines.
    // Allegedly the only sane thing to do is to add the complexity of deferring this processing
    // to a passive level worker thread... but this condition would cause a general instability of
    // the file system.
    //

    // TODO: Log this error condition!!!
    // TODO: if we ever see the condition, defer processing to a PASSIVE_LEVEL worker

    //
    // Hack here, though this is just cleaning up the faulty state set by a previous faulty driver.
    //
    KeLowerIrql(PASSIVE_LEVEL);
    }
    </quote>

    Don't conflate filter manager behavior with I/O Manager behavior. Filter Manager guarantees that post create is called at passive level. The I/O manager makes no such guarantee - though the reality is that it is *almost always* called at passive level.

    This is documented here: http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/filterdriverdeveloperguide.doc

    This is also discussed here - https://www.osronline.com/showthread.cfm?link=237151

    Tony
    OSR
  • Jesse_Conn-2Jesse_Conn-2 Member - All Emails Posts: 42
    Tony,

    After reading the guide, and the thread, I suppose I'm reverting back to my previous conclusion.

    In my PRE create handler:
    1. If IRQL == PASSIVE_LEVEL, do my processing.
    2. Else If IRQL > PASSIVE_LEVEL, push onto a callback data queue for deferred processing, and return FLT_PREOP_PENDING.

    I had implemented this but it seemed to be an over design, now I'm led to believe this was the appropriate solution?

    As for the differences between the IO manager, and the Filter manager... are you suggesting that the Pre Create handler is in the domain of the IO manager, and the Post Create is within the Filter manager? That was not clear. You stated the filter manager will enforce the post create it called as passive, what of the pre create?
  • anatoly_mikhailovanatoly_mikhailov Member Posts: 217
    > The I/O manager makes no such guarantee - though the reality is that it
    is *almost always* called at passive level.
    >
    But ZwCreateFile, for example, must be called at PASSIVE_LEVEL as
    documented on MSDN.

    > As for the differences between the IO manager, and the Filter manager...
    >
    I/O manager is windows subsystem which give you interface to send I/O
    requests. Filter Manager is filter driver which gives you framework for
    file system filtering.
  • Slava_ImameevSlava_Imameev Member Posts: 480
    <QUOTE>
    I had implemented this but it seemed to be an over design,
    </QUOTE>

    This was redundant. If a filter receives create at APC_LEVEL the system is already crippling and you make a bad situation worse by deferring IRP_MJ_CREATE in a worker thread.
  • Slava_ImameevSlava_Imameev Member Posts: 480
    <QUOTE>
    But ZwCreateFile, for example, must be called at PASSIVE_LEVEL as documented on MSDN.
    </QUOTE>

    I believe Tony talked about IRP completion which can happen at IRQL <= DISPATCH_LEVEL.
  • Slava_ImameevSlava_Imameev Member Posts: 480
    <QUOTE>
    Pre Create handler is in the domain of the IO manager, and the Post Create is within the Filter manager
    </QUOTE>

    Pre and Post are both the responsibility of the Filter Manager, IO Manager knows nothing about these callbacks.
  • anatoly_mikhailovanatoly_mikhailov Member Posts: 217
    > I believe Tony talked about IRP completion which can happen at IRQL <=
    DISPATCH_LEVEL.
    >
    Now i believe too.
  • Jesse_Conn-2Jesse_Conn-2 Member - All Emails Posts: 42
    Let's refocus this:
    I need to call a few passive level only routines in PRE create. As such, if
    this can ever be called at anything other than passive, I absolutely must
    defer in the case where this happens only very rarely as reliability trumps
    performance for my use case. I hate to put code in here that will never
    execute, but it appears there is a conflict in the community knowledge base
    where one says only passive level and another says it can be greater than
    in the rare case. Is my reading comprehension so lacking? The MSDN
    documentation is explicit about the Post Create, but is ambiguous on the
    Pre, perhaps that is the ultimate source of the confusion.

    On Monday, October 31, 2016, Anatoly Mikhailov wrote:

    > > I believe Tony talked about IRP completion which can happen at IRQL <=
    > DISPATCH_LEVEL.
    > >
    > Now i believe too.
    >
    >
    > --- NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis,
    > WDF, Windows internals and software drivers! Details at To unsubscribe,
    > visit the List Server section of OSR Online at
  • anatoly_mikhailovanatoly_mikhailov Member Posts: 217
    Tony was talking about postcreate. Hypothetically it can be called above
    PASSIVE_LEVEL. But in practice this is rather rare. As for precreate, it is
    always called at PASSIVE_LEVEL.

    1 нояб. 2016 г. 7:06 AM пользователь "Jesse Conn"
    написал:

    > Let's refocus this:
    > I need to call a few passive level only routines in PRE create. As such,
    > if this can ever be called at anything other than passive, I absolutely
    > must defer in the case where this happens only very rarely as reliability
    > trumps performance for my use case. I hate to put code in here that will
    > never execute, but it appears there is a conflict in the community
    > knowledge base where one says only passive level and another says it can be
    > greater than in the rare case. Is my reading comprehension so lacking? The
    > MSDN documentation is explicit about the Post Create, but is ambiguous on
    > the Pre, perhaps that is the ultimate source of the confusion.
    >
    > On Monday, October 31, 2016, Anatoly Mikhailov
    > wrote:
    >
    >> > I believe Tony talked about IRP completion which can happen at IRQL <=
    >> DISPATCH_LEVEL.
    >> >
    >> Now i believe too.
    >>
    >>
    >> --- NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis,
    >> WDF, Windows internals and software drivers! Details at To unsubscribe,
    >> visit the List Server section of OSR Online at
    >
    > --- NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis,
    > WDF, Windows internals and software drivers! Details at To unsubscribe,
    > visit the List Server section of OSR Online at
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,477
    Let's talk purely in terms of the I/O Manager and leave Filter Manager our
    of it for the moment.

    The *only* way to generate an IRP_MJ_CREATE request in Windows is to call
    ZwCreateFile*. ZwCreateFile will build an IRP and send it to the dispatch
    entry point of the target driver. ZwCreateFile does not change the IRQL as
    part of the call. According to the ZwCreateFile documentation:

    "Callers of ZwCreateFile must be running at IRQL = PASSIVE_LEVEL and
    with special kernel APCs enabled."

    Therefore, by design Windows sends IRP_MJ_CREATE requests at PASSIVE_LEVEL.

    Filter Manager abstracts out the dispatching of the IRP and calls you at
    your PreCreate callback when it receives the IRP. FltMgr does not change the
    IRQL, thus your PreCreate callback is called at PASSIVE_LEVEL.

    If a driver raises the IRQL and calls ZwCreateFile, they're hosed. If a
    higher altitude minifilter changes the IRQL in PreCreate and doesn't restore
    it, they're hosed. Trying to defend against this sort of thing leads to
    madness. A driver could send me invalid arguments, or call me at a bad IRQL,
    or corrupt my data structures, or do any other sorts of horrid things. Yes,
    my customers will come to ME with the problems that arise, but that's life
    in the fast lane (and a scan for other third party drivers is usually my
    first step in analysis). Note that Verifier should catch these types of
    problems and blame the offending driver, so you have that at least.

    Going back to IRP talk, if I want to post-process the create IRP I need to
    set a completion routine and send it along. When the target driver is done
    with the IRP, I get called back at my completion routine at IRQL <=
    DISPATCH_LEVEL.

    FltMgr *always* synchronizes the call between PreCreate and PostCreate. What
    this means is that if the lower driver pends the request, FltMgr will block
    in thread context and then call your PostCreate routine when the lower
    filter is done. FltMgr does not change the IRQL, thus you are called in
    PostCreate at IRQL PASSIVE_LEVEL.

    *Building your own create IRP with IoAllocateIrp was never supported and is
    a tremendously bad idea these days

    -scott
    OSR
    @OSRDrivers

    "Anatoly Mikhailov" <[email protected]> wrote in message
    news:[email protected]

    Tony was talking about postcreate. Hypothetically it can be called above
    PASSIVE_LEVEL. But in practice this is rather rare. As for precreate, it is
    always called at PASSIVE_LEVEL.


    1 нояб. 2016 г. 7:06 AM пользователь "Jesse Conn" <[email protected]>
    написал:
    Let's refocus this:
    I need to call a few passive level only routines in PRE create. As such, if
    this can ever be called at anything other than passive, I absolutely must
    defer in the case where this happens only very rarely as reliability trumps
    performance for my use case. I hate to put code in here that will never
    execute, but it appears there is a conflict in the community knowledge base
    where one says only passive level and another says it can be greater than in
    the rare case. Is my reading comprehension so lacking? The MSDN
    documentation is explicit about the Post Create, but is ambiguous on the
    Pre, perhaps that is the ultimate source of the confusion.

    On Monday, October 31, 2016, Anatoly Mikhailov <[email protected]> wrote:


    > I believe Tony talked about IRP completion which can happen at IRQL <=
    > DISPATCH_LEVEL.
    >
    Now i believe too.



    --- NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis, WDF,
    Windows internals and software drivers! Details at To unsubscribe, visit the
    List Server section of OSR Online at
    --- NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis, WDF,
    Windows internals and software drivers! Details at To unsubscribe, visit the
    List Server section of OSR Online at

    -scott
    OSR

  • Jesse_Conn-2Jesse_Conn-2 Member - All Emails Posts: 42
    A+! Many thanks for putting it all in context start to finish.

    I appreciate all the feedback. I inherited a mess of an undocumented mini
    filter driver, which was obviously a copy paste recompile til it compiled
    design that was littered with huge architectural problems and "random blue
    screens we don't understand".... I've been doing a careful redesign, one
    that is hopefully much more maintainable. Thanks for filling in the
    knowledge gaps :)

    On Tuesday, November 1, 2016, Scott Noone wrote:

    > Let's talk purely in terms of the I/O Manager and leave Filter Manager our
    > of it for the moment.
    >
    > The *only* way to generate an IRP_MJ_CREATE request in Windows is to call
    > ZwCreateFile*. ZwCreateFile will build an IRP and send it to the dispatch
    > entry point of the target driver. ZwCreateFile does not change the IRQL as
    > part of the call. According to the ZwCreateFile documentation:
    >
    > "Callers of ZwCreateFile must be running at IRQL = PASSIVE_LEVEL and
    > with special kernel APCs enabled."
    >
    > Therefore, by design Windows sends IRP_MJ_CREATE requests at PASSIVE_LEVEL.
    >
    > Filter Manager abstracts out the dispatching of the IRP and calls you at
    > your PreCreate callback when it receives the IRP. FltMgr does not change
    > the IRQL, thus your PreCreate callback is called at PASSIVE_LEVEL.
    >
    > If a driver raises the IRQL and calls ZwCreateFile, they're hosed. If a
    > higher altitude minifilter changes the IRQL in PreCreate and doesn't
    > restore it, they're hosed. Trying to defend against this sort of thing
    > leads to madness. A driver could send me invalid arguments, or call me at a
    > bad IRQL, or corrupt my data structures, or do any other sorts of horrid
    > things. Yes, my customers will come to ME with the problems that arise, but
    > that's life in the fast lane (and a scan for other third party drivers is
    > usually my first step in analysis). Note that Verifier should catch these
    > types of problems and blame the offending driver, so you have that at least.
    >
    > Going back to IRP talk, if I want to post-process the create IRP I need to
    > set a completion routine and send it along. When the target driver is done
    > with the IRP, I get called back at my completion routine at IRQL <=
    > DISPATCH_LEVEL.
    >
    > FltMgr *always* synchronizes the call between PreCreate and PostCreate.
    > What this means is that if the lower driver pends the request, FltMgr will
    > block in thread context and then call your PostCreate routine when the
    > lower filter is done. FltMgr does not change the IRQL, thus you are called
    > in PostCreate at IRQL PASSIVE_LEVEL.
    >
    > *Building your own create IRP with IoAllocateIrp was never supported and
    > is a tremendously bad idea these days
    >
    > -scott
    > OSR
    > @OSRDrivers
    >
    > "Anatoly Mikhailov" wrote in message
    > news:[email protected]
    >
    > Tony was talking about postcreate. Hypothetically it can be called above
    > PASSIVE_LEVEL. But in practice this is rather rare. As for precreate, it is
    > always called at PASSIVE_LEVEL.
    >
    >
    > 1 нояб. 2016 г. 7:06 AM пользователь "Jesse Conn"
    > написал:
    > Let's refocus this:
    > I need to call a few passive level only routines in PRE create. As such,
    > if this can ever be called at anything other than passive, I absolutely
    > must defer in the case where this happens only very rarely as reliability
    > trumps performance for my use case. I hate to put code in here that will
    > never execute, but it appears there is a conflict in the community
    > knowledge base where one says only passive level and another says it can be
    > greater than in the rare case. Is my reading comprehension so lacking? The
    > MSDN documentation is explicit about the Post Create, but is ambiguous on
    > the Pre, perhaps that is the ultimate source of the confusion.
    >
    > On Monday, October 31, 2016, Anatoly Mikhailov
    > wrote:
    >
    >
    > I believe Tony talked about IRP completion which can happen at IRQL <=
    >> DISPATCH_LEVEL.
    >>
    >> Now i believe too.
    >
    >
    >
    > --- NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis,
    > WDF, Windows internals and software drivers! Details at To unsubscribe,
    > visit the List Server section of OSR Online at
    > --- NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis,
    > WDF, Windows internals and software drivers! Details at To unsubscribe,
    > visit the List Server section of OSR Online at
    >
    > ---
    > NTFSD is sponsored by OSR
    >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer&gt;
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    <quote>
    As for the differences between the IO manager, and the Filter manager... are you suggesting that the Pre Create handler is in the domain of the IO manager, and the Post Create is within the Filter manager?
    </quote>

    Pre-Create is called in the context of the I/O Manager operation (so IopParseDevice or IopParseFile calls filter manager, which calls your mini-filter.)

    Thus, it is at IRQL == PASSIVE_LEVEL with special kernel APCs enabled (filter manager doesn't change this). The I/O Manager does not ensure that completion routines ("post create") are called at passive level - this is a specific feature of Filter Manager.

    It's possible other drivers could violate these restrictions, but then they're broken as they have not "played by the rules". If you try to write code to defend against this level of malfunction, you will drive yourself insane.

    Tony
    OSR
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    <quote>
    > The I/O manager makes no such guarantee - though the reality is that it is *almost always* called at passive level.
    >
    But ZwCreateFile, for example, must be called at PASSIVE_LEVEL as documented on MSDN.
    </quote>

    The fact that ZwCreateFile must be called at passive level (*and* with special kernel APCs enabled) is not germane to the IRQL of the completion routine, though. Thus, as I said, it is almost always called at passive level but it is not safe to assume that is the case.

    Mini-filters, however, have the added functionality provided by Filter Manager - it handles this case and ensures that the post create function is invoked at passive level, with special kernel APCs enabled. In addition, it also guarantees that it is in the original thread context.

    Tony
    OSR
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 24 January 2022 Live, Online
Internals & Software Drivers 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online
Developing Minifilters 23 May 2022 Live, Online