Driver Verifier error message

OSR_Community_User · May 11, 2000, 1:14pm

I’m getting the following DriverVerifier error message in the debugger:

“An IRP dispatch handler has returned without passing down or completing
this Irp or someone forgot to return STATUS_PENDING.”

It appears that it’s mad a me returning STATUS_MORE_PROCESSING_REQUIRED
after I call PoRequestPowerIrp(…). However, I’m following the exact steps
specified in the DDK, below.

FROM DDK:

Set an IoCompletion routine in the system set-power IRP.
Set up the IRP stack location for the next lower driver by
calling IoCopyCurrentIrpStackLocationToNext.
Call PoCallDriver to pass the IRP to the next-lower driver.
Propagate the status returned by PoCallDriver as the return value
of its DispatchPower routine.
In the IoCompletion routine, the driver sends a device set-power IRP as
follows:
Inspect the IRP to get the requested system power state. Choose
an appropriate device power state for that system state.
Call PoRequestPowerIrp to send an IRP_MN_SET_POWER for the device
power state determined in Step 1. The power policy owner must send the
device set-power request even if the device is already in that state.
Specify a callback routine (CompletionFunction) in the call to
PoRequestPowerIrp and pass the system IRP in the Context area.
Return STATUS_MORE_PROCESSING_REQUIRED from the IoCompletion
routine, so that the driver can finish processing the system set-power IRP
in the callback routine.

Any ideas?

Daniel

OSR_Community_User · May 11, 2000, 1:19pm

Are you calling IoCompleteRequest()? You must do this yourself if you return
STATUS_MORE_PROCESSING_REQUIRED.

Jamey

OSR_Community_User · May 11, 2000, 1:36pm

As I call IoCompleteRequest in the callback routine I set in
PoRequestPowerIrp(…). DriverVerifier signals an error before it sends the
DevicePower Irp I requested with PoRequestPowerIrp.

The DDK states what to do in the callback routine set in PoRequestPowerIrp.
I follow it to the letter:

***From the DDK***

The callback routine must do the following:

Call PoStartNextPowerIrp to start the next power IRP.
Complete the system set-power IRP (IoCompleteRequest) with the status
returned for the device set-power IRP.
Return the status with which the set-power IRPs completed.

***
-Daniel
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Thursday, May 11, 2000 10:13 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Are you calling IoCompleteRequest()? You must do this yourself if you return
STATUS_MORE_PROCESSING_REQUIRED.

Jamey

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

Eliyas_Yakub · May 11, 2000, 2:13pm

This stuff is pretty complex and DDK documentation is not very clear. The
doc has not described several little steps that one needs to perform to
avoid violating IRP rules. It just tells you what you need to conceptually.
Not going into lot of details what you are doing wrong, I would suggest you
to follow the function driver’s power handling logic of toaster package. It
shows in terms of real code what the doc is trying to explain in words. It
will save your lot of time and energy.

-Eliyas

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 10:33 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

As I call IoCompleteRequest in the callback routine I set in
PoRequestPowerIrp(…). DriverVerifier signals an error before it sends the
DevicePower Irp I requested with PoRequestPowerIrp.

The DDK states what to do in the callback routine set in PoRequestPowerIrp.
I follow it to the letter:

***From the DDK***

The callback routine must do the following:

Call PoStartNextPowerIrp to start the next power IRP.
Complete the system set-power IRP (IoCompleteRequest) with the status
returned for the device set-power IRP.
Return the status with which the set-power IRPs completed.

***
-Daniel
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Thursday, May 11, 2000 10:13 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Are you calling IoCompleteRequest()? You must do this yourself if you return
STATUS_MORE_PROCESSING_REQUIRED.

Jamey

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

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

OSR_Community_User · May 11, 2000, 2:28pm

Eliyas:

Just looked at the Toaster/func sample and it’s pretty strait forward.

However, I’ve always been told that we have to handle PowerUp and PowerDown
conditions differently.

Is this true?

Thanks,

Daniel

-----Original Message-----
From: Eliyas Yakub [mailto:xxxxx@microsoft.com]
Sent: Thursday, May 11, 2000 11:09 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

This stuff is pretty complex and DDK documentation is not very clear. The
doc has not described several little steps that one needs to perform to
avoid violating IRP rules. It just tells you what you need to conceptually.
Not going into lot of details what you are doing wrong, I would suggest you
to follow the function driver’s power handling logic of toaster package. It
shows in terms of real code what the doc is trying to explain in words. It
will save your lot of time and energy.

-Eliyas

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 10:33 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

As I call IoCompleteRequest in the callback routine I set in
PoRequestPowerIrp(…). DriverVerifier signals an error before it sends the
DevicePower Irp I requested with PoRequestPowerIrp.

The DDK states what to do in the callback routine set in PoRequestPowerIrp.
I follow it to the letter:

***From the DDK***

The callback routine must do the following:

Call PoStartNextPowerIrp to start the next power IRP.
Complete the system set-power IRP (IoCompleteRequest) with the status
returned for the device set-power IRP.
Return the status with which the set-power IRPs completed.

***
-Daniel
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Thursday, May 11, 2000 10:13 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Are you calling IoCompleteRequest()? You must do this yourself if you return
STATUS_MORE_PROCESSING_REQUIRED.

Jamey

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

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

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

Eliyas_Yakub · May 11, 2000, 2:42pm

Yep. You should also Walter Oney’s book to get another perspective on how
this thing works.

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 11:24 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Eliyas:

Just looked at the Toaster/func sample and it’s pretty strait forward.

However, I’ve always been told that we have to handle PowerUp and PowerDown
conditions differently.

Is this true?

Thanks,

Daniel

-----Original Message-----
From: Eliyas Yakub [mailto:xxxxx@microsoft.com]
Sent: Thursday, May 11, 2000 11:09 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

This stuff is pretty complex and DDK documentation is not very clear. The
doc has not described several little steps that one needs to perform to
avoid violating IRP rules. It just tells you what you need to conceptually.
Not going into lot of details what you are doing wrong, I would suggest you
to follow the function driver’s power handling logic of toaster package. It
shows in terms of real code what the doc is trying to explain in words. It
will save your lot of time and energy.

-Eliyas

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 10:33 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

As I call IoCompleteRequest in the callback routine I set in
PoRequestPowerIrp(…). DriverVerifier signals an error before it sends the
DevicePower Irp I requested with PoRequestPowerIrp.

The DDK states what to do in the callback routine set in PoRequestPowerIrp.
I follow it to the letter:

***From the DDK***

The callback routine must do the following:

Call PoStartNextPowerIrp to start the next power IRP.
Complete the system set-power IRP (IoCompleteRequest) with the status
returned for the device set-power IRP.
Return the status with which the set-power IRPs completed.

***
-Daniel
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Thursday, May 11, 2000 10:13 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Are you calling IoCompleteRequest()? You must do this yourself if you return
STATUS_MORE_PROCESSING_REQUIRED.

Jamey

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

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

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

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

OSR_Community_User · May 11, 2000, 4:30pm

DriverVerifier complains during the power-up sequence.

I compared the toaster example with my power-up code path and it’s
functionally identical.

Right after I return STATUS_MORE_PROCESSING_REQUIRED Verifier complains.
Any ideas?

Daniel

-----Original Message-----
From: Eliyas Yakub [mailto:xxxxx@microsoft.com]
Sent: Thursday, May 11, 2000 11:37 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Yep. You should also Walter Oney’s book to get another perspective on how
this thing works.

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 11:24 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Eliyas:

Just looked at the Toaster/func sample and it’s pretty strait forward.

However, I’ve always been told that we have to handle PowerUp and PowerDown
conditions differently.

Is this true?

Thanks,

Daniel

-----Original Message-----
From: Eliyas Yakub [mailto:xxxxx@microsoft.com]
Sent: Thursday, May 11, 2000 11:09 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

This stuff is pretty complex and DDK documentation is not very clear. The
doc has not described several little steps that one needs to perform to
avoid violating IRP rules. It just tells you what you need to conceptually.
Not going into lot of details what you are doing wrong, I would suggest you
to follow the function driver’s power handling logic of toaster package. It
shows in terms of real code what the doc is trying to explain in words. It
will save your lot of time and energy.

-Eliyas

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 10:33 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

As I call IoCompleteRequest in the callback routine I set in
PoRequestPowerIrp(…). DriverVerifier signals an error before it sends the
DevicePower Irp I requested with PoRequestPowerIrp.

The DDK states what to do in the callback routine set in PoRequestPowerIrp.
I follow it to the letter:

***From the DDK***

The callback routine must do the following:

Call PoStartNextPowerIrp to start the next power IRP.
Complete the system set-power IRP (IoCompleteRequest) with the status
returned for the device set-power IRP.
Return the status with which the set-power IRPs completed.

***
-Daniel
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Thursday, May 11, 2000 10:13 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Are you calling IoCompleteRequest()? You must do this yourself if you return
STATUS_MORE_PROCESSING_REQUIRED.

Jamey

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

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

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

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

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

OSR_Community_User-35 · May 11, 2000, 5:02pm

The instructions you cited say your dispatch should propagate the
status returned from the lower driver; but if the lower driver does
not return STATUS_PENDING, but you are going to defer completion
processing, maybe your dispatch must return STATUS_PENDING?

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

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 1:27 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

DriverVerifier complains during the power-up sequence.

I compared the toaster example with my power-up code path and it’s
functionally identical.

Right after I return STATUS_MORE_PROCESSING_REQUIRED Verifier complains.
Any ideas?

Daniel

-----Original Message-----
From: Eliyas Yakub [mailto:xxxxx@microsoft.com]
Sent: Thursday, May 11, 2000 11:37 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Yep. You should also Walter Oney’s book to get another perspective on how
this thing works.

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 11:24 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Eliyas:

Just looked at the Toaster/func sample and it’s pretty strait forward.

However, I’ve always been told that we have to handle PowerUp and PowerDown
conditions differently.

Is this true?

Thanks,

Daniel

-----Original Message-----
From: Eliyas Yakub [mailto:xxxxx@microsoft.com]
Sent: Thursday, May 11, 2000 11:09 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

This stuff is pretty complex and DDK documentation is not very clear. The
doc has not described several little steps that one needs to perform to
avoid violating IRP rules. It just tells you what you need to conceptually.
Not going into lot of details what you are doing wrong, I would suggest you
to follow the function driver’s power handling logic of toaster package. It
shows in terms of real code what the doc is trying to explain in words. It
will save your lot of time and energy.

-Eliyas

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 10:33 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

As I call IoCompleteRequest in the callback routine I set in
PoRequestPowerIrp(…). DriverVerifier signals an error before it sends the
DevicePower Irp I requested with PoRequestPowerIrp.

The DDK states what to do in the callback routine set in PoRequestPowerIrp.
I follow it to the letter:

***From the DDK***

The callback routine must do the following:

Call PoStartNextPowerIrp to start the next power IRP.
Complete the system set-power IRP (IoCompleteRequest) with the status
returned for the device set-power IRP.
Return the status with which the set-power IRPs completed.

***
-Daniel
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Thursday, May 11, 2000 10:13 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Are you calling IoCompleteRequest()? You must do this yourself if you return
STATUS_MORE_PROCESSING_REQUIRED.

Jamey

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

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

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

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

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

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

OSR_Community_User · May 11, 2000, 5:11pm

You hit it on the head.

In my initial System PowerIrp handler.

Bad Code;
return PoCallDriver(FdoDx->DeviceToSendIrpsTo, Irp);

Good code;
PoCallDriver(FdoDx->DeviceToSendIrpsTo, Irp);
return STATUS_PENDING;

daniel

-----Original Message-----
From: COX,DAVID (HP-Roseville,ex1) [mailto:david_cox2@hp.com]
Sent: Thursday, May 11, 2000 1:59 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

The instructions you cited say your dispatch should propagate the
status returned from the lower driver; but if the lower driver does
not return STATUS_PENDING, but you are going to defer completion
processing, maybe your dispatch must return STATUS_PENDING?

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

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 1:27 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

DriverVerifier complains during the power-up sequence.

I compared the toaster example with my power-up code path and it’s
functionally identical.

Right after I return STATUS_MORE_PROCESSING_REQUIRED Verifier complains.
Any ideas?

Daniel

-----Original Message-----
From: Eliyas Yakub [mailto:xxxxx@microsoft.com]
Sent: Thursday, May 11, 2000 11:37 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Yep. You should also Walter Oney’s book to get another perspective on how
this thing works.

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 11:24 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Eliyas:

Just looked at the Toaster/func sample and it’s pretty strait forward.

However, I’ve always been told that we have to handle PowerUp and PowerDown
conditions differently.

Is this true?

Thanks,

Daniel

-----Original Message-----
From: Eliyas Yakub [mailto:xxxxx@microsoft.com]
Sent: Thursday, May 11, 2000 11:09 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

This stuff is pretty complex and DDK documentation is not very clear. The
doc has not described several little steps that one needs to perform to
avoid violating IRP rules. It just tells you what you need to conceptually.
Not going into lot of details what you are doing wrong, I would suggest you
to follow the function driver’s power handling logic of toaster package. It
shows in terms of real code what the doc is trying to explain in words. It
will save your lot of time and energy.

-Eliyas

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 10:33 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

As I call IoCompleteRequest in the callback routine I set in
PoRequestPowerIrp(…). DriverVerifier signals an error before it sends the
DevicePower Irp I requested with PoRequestPowerIrp.

The DDK states what to do in the callback routine set in PoRequestPowerIrp.
I follow it to the letter:

***From the DDK***

The callback routine must do the following:

Call PoStartNextPowerIrp to start the next power IRP.
Complete the system set-power IRP (IoCompleteRequest) with the status
returned for the device set-power IRP.
Return the status with which the set-power IRPs completed.

***
-Daniel
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Thursday, May 11, 2000 10:13 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Are you calling IoCompleteRequest()? You must do this yourself if you return
STATUS_MORE_PROCESSING_REQUIRED.

Jamey

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

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

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

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

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

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

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

Mark_Roddy · May 12, 2000, 12:03am

Perhaps you should run verifier against the toaster and then:

if it passes go back and re-examine your claim that is functionally
identical;

if it fails ask Eliyas to provide a toaster sample that passes verify

Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nemiroff, Daniel
Sent: Thursday, May 11, 2000 4:27 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

DriverVerifier complains during the power-up sequence.

I compared the toaster example with my power-up code path and it’s
functionally identical.

Right after I return STATUS_MORE_PROCESSING_REQUIRED Verifier complains.
Any ideas?

Daniel

-----Original Message-----
From: Eliyas Yakub [mailto:xxxxx@microsoft.com]
Sent: Thursday, May 11, 2000 11:37 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Yep. You should also Walter Oney’s book to get another perspective on how
this thing works.

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 11:24 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Eliyas:

Just looked at the Toaster/func sample and it’s pretty strait forward.

However, I’ve always been told that we have to handle PowerUp and PowerDown
conditions differently.

Is this true?

Thanks,

Daniel

-----Original Message-----
From: Eliyas Yakub [mailto:xxxxx@microsoft.com]
Sent: Thursday, May 11, 2000 11:09 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

This stuff is pretty complex and DDK documentation is not very clear. The
doc has not described several little steps that one needs to perform to
avoid violating IRP rules. It just tells you what you need to conceptually.
Not going into lot of details what you are doing wrong, I would suggest you
to follow the function driver’s power handling logic of toaster package. It
shows in terms of real code what the doc is trying to explain in words. It
will save your lot of time and energy.

-Eliyas

-----Original Message-----
From: Nemiroff, Daniel [mailto:xxxxx@intel.com]
Sent: Thursday, May 11, 2000 10:33 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

As I call IoCompleteRequest in the callback routine I set in
PoRequestPowerIrp(…). DriverVerifier signals an error before it sends the
DevicePower Irp I requested with PoRequestPowerIrp.

The DDK states what to do in the callback routine set in PoRequestPowerIrp.
I follow it to the letter:

***From the DDK***

The callback routine must do the following:

Call PoStartNextPowerIrp to start the next power IRP.
Complete the system set-power IRP (IoCompleteRequest) with the status
returned for the device set-power IRP.
Return the status with which the set-power IRPs completed.

***
-Daniel
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Thursday, May 11, 2000 10:13 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Driver Verifier error message

Are you calling IoCompleteRequest()? You must do this yourself if you return
STATUS_MORE_PROCESSING_REQUIRED.

Jamey

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

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

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

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

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

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

OSR_Community_User · May 14, 2000, 10:26am

> The instructions you cited say your dispatch should propagate the

As far as I remember the well-known rules:

if you call IoCallDriver in dispatch routine, you a) must not touch the
IRP
after this - it can be already deallocated after all and b) you must return
the
status returned by IoCallDriver (which is the status the lower one’s
dispatch
routine returned) to ensure correct propagation of STATUS_PENDING.
if you do not do this, but queue the request to some queues in your
driver
for further processing (thus giving things others than the current thread a
chance to touch the IRP) - you must call IoMarkIrpPending before queuing the
IRP (before the thread will give the IRP to other code like DPCs) and you
must return STATUS_PENDING.
Forgetting to call IoMarkIrpPending will result in a fact that
IoCompleteRequest will not queue the IopCompleteRequest APC (it will rely
on IopSynchronousServiceTail to call IopCompleteRequest directly without
any APCs, and IopSynchronousServiceTail will not do this because
STATUS_PENDING was returned) - this will result in hung IRP and hung
umode caller thread.
Returning status other than STATUS_PENDING will force
IopSynchronousServiceTail to call IopCompleteRequest directly as a function

and in BSOD of deallocating the same IRP twice (IopCompleteRequest will
be called twice - both as a function and as an APC).
Violating the both rules in this case will result in IopCompleteRequest
being called once (as a function, synchronously, from
IopSynchronousServiceTail), but too early - maybe before
IoCompleteRequest was called by the DPC or other asynchronous thing - a
crash also.
“Use IoMarkIrpPending if you return STATUS_PENDING, and vice versa” -
this is the rule.
“Do not return status other than STATUS_PENDING if you have not called
IoCompleteRequest in the dispatch routine and have not handled the IRP to
the lower driver” - this is another one.

if you complete the IRP immediately in dispatch routine, than you can
return status other than STATUS_PENDING. But AFAIK it is safe to write:
IoMarkIrpPending(Irp);
IoCompleteRequest(Irp, …);
return STATUS_PENDING:
This seems to result only in slight performance penalty -
IopCompleteRequest will fire correctly, but as an APC, not as a direct
function call possible in this case.
if your completion routine returns STATUS_SUCCESS (not
STATUS_MORE_PROCESSING_REQUIRED - these are the only 2
permitted returns from the completion routine), then it must contain the:
if( Irp->PendingReturned )
IoMarkIrpPending(Irp);
Forgetting to do so is the same as forgetting the initial IoMarkIrpPending -
this result in IopCompleteRequest never sent - a hung.

Power IRPs have some special rules. This is the working code for the
function driver (running fine on Win98 at least):

NTSTATUS MyDriverDispatchPower(…)
{
if( irpStack->MinorFunction == IRP_MN_SET_POWER )
return MyDriverSetPowerState(Irp);
PoStartNextPowerIrp(Irp);
IoCopyCurrentIrpStackLocationToNext(Irp);
return PoCallDriver(LowerDeviceObject, Irp);
}

NTSTATUS MyDriverSetPowerState(…)
{
// For Device power state change, all paths must finish with
// PoStartNextPowerIrp/IoCompleteRequest or
// PoStartNextPowerIrp/return PoCallDriver
// PoSetPowerState must be called before this.
// For Device shutdown, the hardware shutdown must be executed before
// this.
// For Device awaken, a completion routine (ordinary) must be registered
// by IoSetCompletionRoutine and then the IRP will be passed down by
// PoStartNextPowerIrp/return PoCallDriver
// The completion routine will awaken the hardware and return
// STATUS_SUCCESS.
// For System power state change - if the state change is shutdown, then
// shut down the hardware and do
// PoStartNextPowerIrp/IoCompleteRequest sequence.
// If the System state change is awaken, then do PoRequestPowerIrp
// to the stack immediately and specify a completion routine
// (power completion routine, not ordinary one).
// The power completion routine will call
// PoStartNextPowerIrp/IoCompleteRequest sequence for the original
// power IRP passed to it in Context parameter.
}

The working sequence for the bus driver (for PDOs):

PoSetPowerState
PoStartNextPowerIrp
IoCompleteRequest

AFAIK the problem is that IO/PnP manager maintains a special queue of
power IRPs per each stack (or maybe even per each device object). This is
done (maybe?) to support inrush power IRPs. And thus PoCallDriver and
PoStartNextPowerIrp - to maintain the busy/free state of this queue.

Max