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

Home NTDEV

Before Posting...

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

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/


Blue screen

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Hi All.,

I am getting a blue screen with the following message:

A wait operation, attach process, or yield was attempted from a DPC
routine. with bugcheck code as 0x000000b8 and all four parameters as 0.
Any idea about it? I do have a DPC routine and I am calling
KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
KeReleaseSpinLock() functions in that routine.

Please help!
Thanks in advance.
-Fareed.

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Hi,
    The problem is that you can call the KeAcquireSpinLock() and
    KeReleaseSpinLock() only at IRQLs less than dispatch level since in the
    process of acquiring the lock first the IRQL is raised to dispatch level
    from the old IRQL and then the lock is acquired. Since in your DPC routine
    you'll already be runing at dispatch level IRQL you should use the routines
    KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
    respectively acquire and release spin locks from your DPC routines. Hope
    this is of some help.

    Thanks,
    -Neelay

    "Fareeduddin A. Mohammed" wrote:

    > Hi All.,
    >
    > I am getting a blue screen with the following message:
    >
    > A wait operation, attach process, or yield was attempted from a DPC
    > routine. with bugcheck code as 0x000000b8 and all four parameters as 0.
    > Any idea about it? I do have a DPC routine and I am calling
    > KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
    > KeReleaseSpinLock() functions in that routine.
    >
    > Please help!
    > Thanks in advance.
    > -Fareed.
  • OSR_Community_User-35OSR_Community_User-35 Member Posts: 154
    KeAcquireSpinLock() MAY be called at DISPATCH_LEVEL, it is not necessary
    to be below. It may NOT be called from above DISPATCH_LEVEL.

    Assuming you've done things right up until that point, if you are
    holding a spin lock, you are at DISPATCH_LEVEL, so KeReleaseSpinLock()
    can be called only at DISPATCH_LEVEL, and not below.

    If you are at DISPATCH_LEVEL prior to acquiring a spin lock, then
    KeAcquire/ReleaseSpinLock() are doing additional unnecessary work. The
    routines KeAcquire/ReleaseSpinLockAt/FromDpcLevel() are offered for
    optimization -- they cut out the unnecessary steps of changing the IRQL.

    -----------------------------------------------------------------------
    Dave Cox
    Hewlett-Packard Co.
    HPSO/SSMO (Santa Barbara)
    https://ecardfile.com/id/Dave+Cox


    -----Original Message-----
    From: Neelay Das [mailto:[email protected]]
    Sent: Thursday, April 20, 2000 5:46 AM
    To: NT Developers Interest List
    Subject: [ntdev] Re: Blue screen


    Hi,
    The problem is that you can call the KeAcquireSpinLock() and
    KeReleaseSpinLock() only at IRQLs less than dispatch level since in the
    process of acquiring the lock first the IRQL is raised to dispatch level
    from the old IRQL and then the lock is acquired. Since in your DPC routine
    you'll already be runing at dispatch level IRQL you should use the routines
    KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
    respectively acquire and release spin locks from your DPC routines. Hope
    this is of some help.

    Thanks,
    -Neelay

    "Fareeduddin A. Mohammed" wrote:

    > Hi All.,
    >
    > I am getting a blue screen with the following message:
    >
    > A wait operation, attach process, or yield was attempted from a DPC
    > routine. with bugcheck code as 0x000000b8 and all four parameters as 0.
    > Any idea about it? I do have a DPC routine and I am calling
    > KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
    > KeReleaseSpinLock() functions in that routine.
    >
    > Please help!
    > Thanks in advance.
    > -Fareed.


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    No, it is not a problem to call KeAcquireSpinLock at DISPATCH_LEVEL, it is
    simply a performance optimization to use KeAcquireSpinLockAtDpcLevel
    instead. There is some other problem in his dpc routine.

    > -----Original Message-----
    > From: Neelay Das [mailto:[email protected]]
    > Sent: Thursday, April 20, 2000 8:46 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Re: Blue screen
    >
    >
    > Hi,
    > The problem is that you can call the KeAcquireSpinLock() and
    > KeReleaseSpinLock() only at IRQLs less than dispatch level
    > since in the
    > process of acquiring the lock first the IRQL is raised to
    > dispatch level
    > from the old IRQL and then the lock is acquired. Since in
    > your DPC routine
    > you'll already be runing at dispatch level IRQL you should
    > use the routines
    > KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
    > respectively acquire and release spin locks from your DPC
    > routines. Hope
    > this is of some help.
    >
    > Thanks,
    > -Neelay
    >
    > "Fareeduddin A. Mohammed" wrote:
    >
    > > Hi All.,
    > >
    > > I am getting a blue screen with the following message:
    > >
    > > A wait operation, attach process, or yield was attempted from a DPC
    > > routine. with bugcheck code as 0x000000b8 and all four
    > parameters as 0.
    > > Any idea about it? I do have a DPC routine and I am calling
    > > KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
    > > KeReleaseSpinLock() functions in that routine.
    > >
    > > Please help!
    > > Thanks in advance.
    > > -Fareed.
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    The problem is that you CANNOT wait on an event/object for a non-zero
    interval of time at a raised IRQL. Any IRQL >= DISPATCH_LEVEL is considered
    raised IRQL. Calling KeAcquireSpinLock() in code running already at
    DISPATCH_LEVEL is *OK*. It's just that if you call
    KeAcquireSpinLockAtDispatchLevel(), the IRQL will not have to be raised, and
    hence is more efficient. But you have to be very sure that you indeed will
    be running at DISPATCH_LEVEL in such cases. In codes that "might be" running
    at < DISPATCH_LEVEL in some cases, you should always use
    KeAcquireSpinLock().

    NB: DPCs are always running at DISPATCH LEVEL. So you can safely call
    KeAcquireSpinLockAtDispatchLevel, but that won't solve the problem.

    If possible, remove the Stall() function, OR, queue the request to a worker
    thread, and call stall there. (These threads *always* run at PASSIVE_LEVEL)

    That should help.
    Shweta.

    Hi,
    The problem is that you can call the KeAcquireSpinLock() and
    KeReleaseSpinLock() only at IRQLs less than dispatch level since in the
    process of acquiring the lock first the IRQL is raised to dispatch level
    from the old IRQL and then the lock is acquired. Since in your DPC routine
    you'll already be runing at dispatch level IRQL you should use the routines
    KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
    respectively acquire and release spin locks from your DPC routines. Hope
    this is of some help.

    Thanks,
    -Neelay

    "Fareeduddin A. Mohammed" wrote:

    > Hi All.,
    >
    > I am getting a blue screen with the following message:
    >
    > A wait operation, attach process, or yield was attempted from a DPC
    > routine. with bugcheck code as 0x000000b8 and all four parameters as 0.
    > Any idea about it? I do have a DPC routine and I am calling
    > KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
    > KeReleaseSpinLock() functions in that routine.
    >
    > Please help!
    > Thanks in advance.
    > -Fareed.


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ______________________________________________
    FREE Personalized Email at Mail.com
    Sign up at http://www.mail.com/?sr=signup
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Thank you very much to all of those who answered to my query.
    The problem was that I was calling another function from within my dpc routine
    and that function was waiting using a KeWaitforsingleobject() function. In the
    DDK documentation it is given that KeWaitXXX shouldn't be call from DPC
    routine. When I removed this wait it is not crashing.

    Thanks
    -Fareed

    "Roddy, Mark" wrote:

    > No, it is not a problem to call KeAcquireSpinLock at DISPATCH_LEVEL, it is
    > simply a performance optimization to use KeAcquireSpinLockAtDpcLevel
    > instead. There is some other problem in his dpc routine.
    >
    > > -----Original Message-----
    > > From: Neelay Das [mailto:[email protected]]
    > > Sent: Thursday, April 20, 2000 8:46 AM
    > > To: NT Developers Interest List
    > > Subject: [ntdev] Re: Blue screen
    > >
    > >
    > > Hi,
    > > The problem is that you can call the KeAcquireSpinLock() and
    > > KeReleaseSpinLock() only at IRQLs less than dispatch level
    > > since in the
    > > process of acquiring the lock first the IRQL is raised to
    > > dispatch level
    > > from the old IRQL and then the lock is acquired. Since in
    > > your DPC routine
    > > you'll already be runing at dispatch level IRQL you should
    > > use the routines
    > > KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
    > > respectively acquire and release spin locks from your DPC
    > > routines. Hope
    > > this is of some help.
    > >
    > > Thanks,
    > > -Neelay
    > >
    > > "Fareeduddin A. Mohammed" wrote:
    > >
    > > > Hi All.,
    > > >
    > > > I am getting a blue screen with the following message:
    > > >
    > > > A wait operation, attach process, or yield was attempted from a DPC
    > > > routine. with bugcheck code as 0x000000b8 and all four
    > > parameters as 0.
    > > > Any idea about it? I do have a DPC routine and I am calling
    > > > KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
    > > > KeReleaseSpinLock() functions in that routine.
    > > >
    > > > Please help!
    > > > Thanks in advance.
    > > > -Fareed.
    > >
    > >
    > > ---
    > > You are currently subscribed to ntdev as: [email protected]
    > > To unsubscribe send a blank email to $subst('Email.Unsub')
    > >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    >
    > If possible, remove the Stall() function, OR, queue the
    > request to a worker
    > thread, and call stall there. (These threads *always* run at
    > PASSIVE_LEVEL)
    >
    > That should help.

    Why?

    My ddk says: "Callers of KeStallExecutionProcessor can be running at any
    IRQL."
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I am sorry, I messed up KeWait() and Stall() functions. As it turned out, he
    was eventually calling KeWait() function. Stall() does not "wait" for any
    object/event, but freezes the processor, and can be running at any irql.

    You are right, sorry for mix-up.

    Shweta.

    >
    > If possible, remove the Stall() function, OR, queue the
    > request to a worker
    > thread, and call stall there. (These threads *always* run at
    > PASSIVE_LEVEL)
    >
    > That should help.

    Why?

    My ddk says: "Callers of KeStallExecutionProcessor can be running at any
    IRQL."



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ______________________________________________
    FREE Personalized Email at Mail.com
    Sign up at http://www.mail.com/?sr=signup
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Hi,
    Thanks for correcting me out here. Actually, from the information Fareed had
    given it appeared surely to be an IRQL problem. Before replying, I checked up
    the DDK documentation for KeStallExecutionProcessor(), KeAcquireSpinLock() and
    KeReleaseSpinLock() and since KeStallExecutionProcessor() can be called at any
    IRQL, KeAcquireSpinLock() seemed to be the only culprit. But I was not too sure
    on that, as the DDK docs clearly say that KeAcquireSpinLock() can be called at
    IRQL <= DISPATCH_LEVEL.
    Anyway, sorry for any mix-up, it might have caused.

    Thanks,
    Neelay

    Shweta Dubey wrote:

    > The problem is that you CANNOT wait on an event/object for a non-zero
    > interval of time at a raised IRQL. Any IRQL >= DISPATCH_LEVEL is considered
    > raised IRQL. Calling KeAcquireSpinLock() in code running already at
    > DISPATCH_LEVEL is *OK*. It's just that if you call
    > KeAcquireSpinLockAtDispatchLevel(), the IRQL will not have to be raised, and
    > hence is more efficient. But you have to be very sure that you indeed will
    > be running at DISPATCH_LEVEL in such cases. In codes that "might be" running
    > at < DISPATCH_LEVEL in some cases, you should always use
    > KeAcquireSpinLock().
    >
    > NB: DPCs are always running at DISPATCH LEVEL. So you can safely call
    > KeAcquireSpinLockAtDispatchLevel, but that won't solve the problem.
    >
    > If possible, remove the Stall() function, OR, queue the request to a worker
    > thread, and call stall there. (These threads *always* run at PASSIVE_LEVEL)
    >
    > That should help.
    > Shweta.
    >
    > Hi,
    > The problem is that you can call the KeAcquireSpinLock() and
    > KeReleaseSpinLock() only at IRQLs less than dispatch level since in the
    > process of acquiring the lock first the IRQL is raised to dispatch level
    > from the old IRQL and then the lock is acquired. Since in your DPC routine
    > you'll already be runing at dispatch level IRQL you should use the routines
    > KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
    > respectively acquire and release spin locks from your DPC routines. Hope
    > this is of some help.
    >
    > Thanks,
    > -Neelay
    >
    > "Fareeduddin A. Mohammed" wrote:
    >
    > > Hi All.,
    > >
    > > I am getting a blue screen with the following message:
    > >
    > > A wait operation, attach process, or yield was attempted from a DPC
    > > routine. with bugcheck code as 0x000000b8 and all four parameters as 0.
    > > Any idea about it? I do have a DPC routine and I am calling
    > > KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
    > > KeReleaseSpinLock() functions in that routine.
    > >
    > > Please help!
    > > Thanks in advance.
    > > -Fareed.
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    > ______________________________________________
    > FREE Personalized Email at Mail.com
    > Sign up at http://www.mail.com/?sr=signup
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Has anyone ever done performance analysis as to what the gains are for using KeAcquireSpinLockAtDispatchLevel() vs.
    KeAcquireSpinLock() when you know that you are at DISPATCH_LEVEL?

    Are the gains large enough to warrant using this? Does anyone have any timings for the two scenarios?

    Thanks,
    Alan

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of Neelay Das
    > Sent: Thursday, April 20, 2000 11:45 PM
    > To: NT Developers Interest List
    > Subject: [ntdev] Re: Blue screen
    >
    >
    > Hi,
    > Thanks for correcting me out here. Actually, from the information Fareed had
    > given it appeared surely to be an IRQL problem. Before replying, I checked up
    > the DDK documentation for KeStallExecutionProcessor(), KeAcquireSpinLock() and
    > KeReleaseSpinLock() and since KeStallExecutionProcessor() can be called at any
    > IRQL, KeAcquireSpinLock() seemed to be the only culprit. But I was not too sure
    > on that, as the DDK docs clearly say that KeAcquireSpinLock() can be called at
    > IRQL <= DISPATCH_LEVEL.
    > Anyway, sorry for any mix-up, it might have caused.
    >
    > Thanks,
    > Neelay
    >
    > Shweta Dubey wrote:
    >
    > > The problem is that you CANNOT wait on an event/object for a non-zero
    > > interval of time at a raised IRQL. Any IRQL >= DISPATCH_LEVEL is considered
    > > raised IRQL. Calling KeAcquireSpinLock() in code running already at
    > > DISPATCH_LEVEL is *OK*. It's just that if you call
    > > KeAcquireSpinLockAtDispatchLevel(), the IRQL will not have to be raised, and
    > > hence is more efficient. But you have to be very sure that you indeed will
    > > be running at DISPATCH_LEVEL in such cases. In codes that "might be" running
    > > at < DISPATCH_LEVEL in some cases, you should always use
    > > KeAcquireSpinLock().
    > >
    > > NB: DPCs are always running at DISPATCH LEVEL. So you can safely call
    > > KeAcquireSpinLockAtDispatchLevel, but that won't solve the problem.
    > >
    > > If possible, remove the Stall() function, OR, queue the request to a worker
    > > thread, and call stall there. (These threads *always* run at PASSIVE_LEVEL)
    > >
    > > That should help.
    > > Shweta.
    > >
    > > Hi,
    > > The problem is that you can call the KeAcquireSpinLock() and
    > > KeReleaseSpinLock() only at IRQLs less than dispatch level since in the
    > > process of acquiring the lock first the IRQL is raised to dispatch level
    > > from the old IRQL and then the lock is acquired. Since in your DPC routine
    > > you'll already be runing at dispatch level IRQL you should use the routines
    > > KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
    > > respectively acquire and release spin locks from your DPC routines. Hope
    > > this is of some help.
    > >
    > > Thanks,
    > > -Neelay
    > >
    > > "Fareeduddin A. Mohammed" wrote:
    > >
    > > > Hi All.,
    > > >
    > > > I am getting a blue screen with the following message:
    > > >
    > > > A wait operation, attach process, or yield was attempted from a DPC
    > > > routine. with bugcheck code as 0x000000b8 and all four parameters as 0.
    > > > Any idea about it? I do have a DPC routine and I am calling
    > > > KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
    > > > KeReleaseSpinLock() functions in that routine.
    > > >
    > > > Please help!
    > > > Thanks in advance.
    > > > -Fareed.
    > >
    > > ---
    > > You are currently subscribed to ntdev as: [email protected]
    > > To unsubscribe send a blank email to $subst('Email.Unsub')
    > >
    > > ______________________________________________
    > > FREE Personalized Email at Mail.com
    > > Sign up at http://www.mail.com/?sr=signup
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
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 12 September 2022 Live, Online
Internals & Software Drivers 23 October 2022 Live, Online
Kernel Debugging 14 November 2022 Live, Online
Developing Minifilters 5 December 2022 Live, Online