Blue screen

NTDEV
1

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.

2

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.

3

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:xxxxx@netlab.hcltech.com]
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: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

4

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:xxxxx@netlab.hcltech.com]
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: xxxxx@stratus.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

5

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: xxxxx@techie.com
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

6

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:xxxxx@netlab.hcltech.com]
> 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: xxxxx@stratus.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>

You are currently subscribed to ntdev as: xxxxx@sigmatel.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

7

>

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.”

8

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: xxxxx@techie.com
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

9

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: xxxxx@techie.com
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

10

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: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]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: xxxxx@techie.com
> 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: xxxxx@clariion.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)