Windows Kernel Plug and Play and Power Management

Posted October 26, 2004

Chat Date: October 20, 2004

Please note: Portions of this transcript have been edited for clarity

Introduction

EricSa_MS (Moderator):
Welcome to today’s chat. Our topic today is Windows Kernel Plug and Play and Power Management.

EricSa_MS (Moderator):
We are pleased to welcome our Experts for today’s chat. I will have them introduce themselves now.

Tony (Expert):
I am a Technical Evangelist covering power management, ACPI, I/O interconnects, etc...

Allen (Expert):
Good morning. I'm the Program Manager responsible for kernel PnP, power management, ACPI, etc.

Santosh (Expert):
I am the PNP developer. Hello and welcome!

Matt (Expert):
I am a developer in the Windows core team and work on power management.

EricSa_MS (Moderator):
Let’s begin the chat. We welcome you to begin submitting your questions for our Experts. If you have attended previous chats, you may be accustomed to prefacing your question with a Q:, there is no need to do that any longer. Our new chat system will automatically preface your question with a Q:.

EricSa_MS (Moderator):
Welcome everyone, let’s get started!

Start of Chat

Allen (Expert):
Q: In Longhorn, will PnP and Power Management be more closely integrated?
A: Yes; we're cleaning up the WDM model some, simplifying how power IRPs are handled, etc.

Allen (Expert):
Q: In Longhorn, will drivers still see Power S-IRPs?
A: Yes.

Matt (Expert):
Q: I've would like to know how can I do a custom panel like the VS.net menu Panel
A: I don't know quite how this question relates to power management? Can you elaborate?

EricSa_MS (Moderator):
Hello. For those just joining the chat - Our topic is Windows Kernel Plug and Play and Power Management. Questions, comments and suggestions are welcome.

Allen (Expert):
Q: Is WDM model going to be replaced completely by architecture(WDF ?) ? I wanted to know specifically about WDM drivers under streaming architecture. The AVStream Model and BDA architecture is relatively new. What about that ?
A: WDM will co-exist with WDF. Sorry, this is not the right group of folks to answer questions about AV streaming.

Santosh (Expert):
Q: Reporting PNP_DEVICE_FAILED on an IRP_MN_QUERY_DEVICE_STATE in a filter for a child device of a composite devices does not trigger removal of a device by PnP Manager in Win2K on all service packs. Is this a bug or a feature in Win2K ?
A: This should result in IRP_MN_SURPRISE_REMOVAL being sent and final IRP_MN_REMOVE_DEVICE when the last open handle closes. If you are not seeing this, then it’s a bug.

Santosh (Expert):
Q: (on WinXP the device is removed which no exceptions)
A: This was answered by the answer for Q8.

Allen (Expert):
Q: So, how are things going to be simplified?
A: Due to ongoing development planning, I'd rather not go into specifics at this time. We'll have updated LDK docs and white papers that will cover this when we're ready to disclose details.

Matt (Expert):
Q: Why is some windows kernel content scattered across WWW but other doc scattered across MSDN...can we have ONE place to go for kernel developer docs? In one place?
A: We try to keep https://msdn.microsoft.com/ as the starting point for kernel developer help and docs.

Santosh (Expert):
Q: First, thanks to the experts for taking the time to answer our questions! Is there any possible way for a driver to know when PnP has completed its processing of a device discovery and configuration process?
A: Can you elaborate on what exactly you want to know? Generally, a driver is loaded on the device once the install is complete.

Allen (Expert):
Q: How much of the changes made in Longhorn will be back-ported to XP and 2K?
A: We have no plans to backport the WDM simplification for power that this team owns to downlevel OS versions.

Matt (Expert):
Q: What is this then https://www.microsoft.com/whdc/driver/kernel/default.mspx
A: This is content from Microsoft’s annual WinHec conferences. This may be relevant to driver writers, but may also be relevant to platform and device OEMs as well. I agree there's overlap here, but much of this content doesn't make sense for MSDN audiences. https://www.microsoft.com/whdc was created to provide consolidated technical resources for hardware engineers and driver developers. WHDC is where you will find information about Windows kernel-mode development, driver development and testing techniques, and device and driver installation. The information provided on MSDN for kernel-mode developers is contained in the DDK documentation.

Tony (Expert):
Q: Will Lx states in PCI Express be visible to drivers? Does driver manage Lxstates based on Dx states, or the bus driver does this?
A: Short answer no, the Lx registers will be owned by a Express aware operating system. The states are enabled in many ways, firmware during post, power on defaults (like in Expresscard devices), or by the OS bus driver. The Lx states are basically controlled by hw negotiation once setup and are related to Dx states during power events, but this is all hw state machines, not driver control

Santosh (Expert):
Q: Thank you Santosh. Will IRP_MN_SURPRISE_REMOVAL not be sent if someone is still holding an open handle for the device ? Is there a reason an open handle will remain open specifically in win2k on child devices of a composite device ?
A: Surprise removal is sent right away. Only the subsequent remove is delayed until the last open handle closes. You should work with PSS to get this resolved as the behavior should be similar on W2K if the driver is doing the same thing.

Allen (Expert):
Q: Will drivers written to the 'new simplification' run on older versions of the OS - without being recompiled?
A: No.

Matt (Expert):
Q: Where the new docum will appear first: MSDL content online, or LDK /WDF releases?
A: It's going to be difficult to answer non-technical questions like this. I'm not sure if there's anyone on this chat that can answer documentation and publication questions like this.

Matt (Expert):
Q: Is there any document or a place where we can see the overall changes in the Longhorn driver model with respect to various technologies like Pnp, streaming, Graphics etc. Right now, I cannot find a single place which describes change affecting technologies
A: Again, I'm not sure if there's anyone on this chat that can answer documentation and publication questions like this. I think your best bet here is to periodically check whdc.

Matt (Expert):
You're welcome

Santosh (Expert):
Q: Is there a method for attaching a filter to all devices that registered with a certain device interface class (using IoSetDeviceInterfaceState) ? (Assuming the devices are in different setup classes and using a class filter will not help)
A: You can install yourself as a device filter on all devices once you have compiled the list of devices of interest using SetupDiGetClassDevsEx(DIGCF_DEVICEINTERFACE).

Santosh (Expert):
Q: Sure! Let’s say you scan for any hardware changes and discover some new devices. PnP does its thing (notifying the correct drivers, etc) and then finishes. Is there a way to figure out when PnP has finished this? I'd rather not have some polling process
A: What do you want to do? PNP is dynamic and it gets kicked into action based on applications (like device manager scan for new hardware) or drivers reporting changes. So basically, even if there was such a mechanism, by the time you got it, PNP might be busy again. So I am trying to understand whets the application for this.

Matt (Expert):
Q: During some testings I've done with filter drivers I discovered that failing IRP_MN_START_DEVICE with a lower filter causes bug checks in more than 25% of the drivers that are shipped with Windows (2k, XP and 2003). Isn't there a WHQL for testing that a
A: I'd need to know more specifics here. What's the bugcheck code?

EricSa_MS (Moderator):
Hello. For those just joining the chat - Our topic is Windows Kernel Plug and Play and Power Management. Questions, comments and suggestions are welcome.

Santosh (Expert):
Q: Thank you Santosh, but I meant to ask about a method to attach to those devices as they register the interface during handling of IRP_MN_START_DEVICE and not only in the next time the device is added by PnP.
A: WDM drivers should not attach to PNP stacks outside of documented PNP actions (like AddDevice). This is a recipe for disaster as it may cause bugchecks since the rest of the system does not expect the stack to change outside of its own control. You may not see a problem every time but its a bad idea.

Matt (Expert):
Q: Anybody knows why for NDIS miniport are defined only D0 and D3 (or am I wrong?) Is this just to simplify NDIS, or something specific to PCI pwr mgmt? In NDIS6, can miniports have D1, D2?
A: NDIS isn't bus-specific, so I don't think this anything to do with PCI. I suspect this was a design decision made in the NDIS team. I can't answer why though.

Santosh (Expert):
Q: The usual pattern for bus drivers is one "bus FDO" to which child PDOs are associated through the QUERY_BUS_RELATION request. How would I do in the following situation:
A: PNP does not support graphs - it still deals with device trees. So basically, there is no built-in support for child devices with multiple parents. What is the HW scenario?

Santosh (Expert):
Q: Many FDOs joined together have to generate one child PDO; and that PDO should remain as long as there is at least one of the parent FDOs. It this a possible scenario?
A: this was answered for Q29

Santosh (Expert):
Q: Santosh, would you say that writing a filter that attaches the child device that a FDO reports in its BusRelation is also a bad idea ?
A: That’s a special case of bus filter and again its done in the context of the PNP IRP when the PDO is first reported.

Matt (Expert):
Q: Matt, the bugcheck that is generated is different with each FDO I've tested, mostly I encountered access violation of irql problems.
A: This bugcheck means that we've hit a pagefault while at DISPATCH. I've never heard of this being caused by failing the START_DEVICE irp. I can follow up with our test group about testing for this.

Santosh (Expert):
Q: I have an issue where some "thrashing" occurs during boot time between two controllers in a RAID device as luns are discovered and was looking for some way to only allow I/O requests once PnP was finished handling the discovery process.
A: I cannot guess what is causing the thrashing - it will help if you tell me who you have found to be initiating this I/O. PNP itself should not be causing thrashing. Once your LUN is installed and started, it should be ready to handle I/O.

Allen (Expert):
Q: Can bus powered devices dynamically change it's power requirements - example: USB device registered as low power but later needs to consume a lot. Possible?
A: I don't think so, but this would be better addressed by the USB folks.

Matt (Expert):
Q: Matt, these bugchecks occur in many drivers when you fail the IRP_MN_START_DEVICE from a *lower filter*. A bugcheck even occurs in usbprint.sys on win2k.
A: Noted. I have a thread with our test guys about this.

Santosh (Expert):
Q: storagedude: Hi Santosh. No, PnP is not doing this. It would take to long to explain over a chat session (and I'm quite tried right now).
A: perhaps this is best for the newsgroup

Santosh (Expert):
Q: In WinXP (don't know about other versions, didn't check) usbccgp.sys always put 0 in PNP_DEVICE_STATE bit mask for IRP_MN_QUERY_DEVICE_STATE when a PDO it created receives it (and by doing that turns off bits that were turned on by upper devices in the
A: yes, this is illegal and the correct way is documented in the DDK.

Santosh (Expert):
Q: device stack. Isn't this an illegal behavior for a PnP Driver ?
A: already answered by Q36

Matt (Expert):
Q: Have there been any discussions with the storage group about reducing the size of the PnP tree for storage configurations where large numbers of luns and many paths exist (this would only be relevant if the miniport driver is not hiding the multipath devs)
A: There have been no discussions from this end. That doesn't mean the storage guys aren't persuing this on their own though.

Santosh (Expert):
Q: Have there been any discussions with the storage group about reducing the size of the PnP tree for storage configurations where large numbers of luns and many paths exist (this would only be relevant if the miniport driver is not hiding the multipath devs)
A: we are working with the storage team to refine their requirements to simplify the MPIO solution.

Santosh (Expert):
Q: Thanks!
A: you are welcome

Allen (Expert):
Q: Allen: there are other bus powered devices besides USB. It's too late for LH, or could you add driver/usermode interface to query/change power caps?
A: Yes, it's late for LH changes. Seems like this would require a stop and/or bus reset - not good. I don't think this is viable.

Matt (Expert):
Q: Matt, in my tests I also encountered cases in which FDOs complete IRP_MN_START_DEVICE with STATUS_SUCCESS even if it was failed by a lower device in the device stack. I guess that there is not WHQL test for this also (and also not in Driver Verfier)
A: I thought the verifier checked for this. Taking the discussion offline...

Santosh (Expert):
Q: Will there be an attempt to allow all PnP stacks to be rebuilt dynamically? I mean a totally no reboot design except when the kernel needs to be replaced or updated.
A: PNP already supports unloading of drivers. There are no reboot requests originating from within the system itself (unless you are trying to remove things like the paging device). Almost all the reboot requests come due to unruly applications\drivers vetoing removal. Having said that, we are working on minimizing the cases that need reboots as much as we can.

Matt (Expert):
Q: Matt, please try again, my IE got stuck when you tried.
A: Did you get that?

Santosh (Expert):
Q: How will the PnP act if a driver fails IRP_MN_QUERY_DEVICE_CAPABILITIES after it completes IRP_MN_START_DEVICE ?
A: PNP already sends this IRP after start so I don’t understand the question.

Santosh (Expert):
Q: The removal question is about all stacks, including storage and file systems. I want to be able to add a filter and keep the system running, even in the paging stack. It might require the user to wait until the system become idle.
A: We have discussed this in depth and right now, it does not appear to be a high priority requirement and is not in the current plans. However, this is something we will keep on investigating.

Matt (Expert):
Q: Is there any special power management processing that a volume filter driver has to do besides the one presented in the Toaster sample? The attachment is not done by AddDevice "toaster-like" way.
A: No, I don't think so. I don't have the toaster sample in front of me, but the power-related code in this driver is very well done. I'd also refer you to the new NDIS sample driver in upcoming releases. It's even better with respect to power management and I believe there may be a WDF version too.

Santosh (Expert):
Q: Santosh, after a device completes IRP_MN_START_DEVICE successfully the nP Manager sends and IRP to query for the device capabilities. My question is what happens if the device then failed this IRP.
A: The capabilities wont get updated but this failure is not fatal.

Santosh (Expert):
Q: In future versions of PnP, will it be possible to attach filters to device stacks that are already started without restarting them ?
A: Not in the near future.

Matt (Expert):
Q: In my filter, when attaching I set the DO_POWER_PAGABLE on my filter device object and I also propagate the DO_POWER_INRUSH in case the target device has it set. Is this OK?
A: Yes, but this can cause perf bottlenecks in some cases. The INRUSH bit has some odd effects when I'm spraying D0 irps across the device tree when we're coming out of standby. Functionally, you should be okay though.

Matt (Expert):
Q: When machine returns from suspend, are all kernel components notified before all win32 (usermode)? is this guaranteed?
A: If you mean driver, then the answer is yes.

EricSa_MS (Moderator):
Thanks for joining us today and thanks for the questions. It's time for us to go now. If we couldn't get to your question, please ask in the Driver Development newsgroup:

news://msnews.microsoft.com/microsoft.public.development.device.drivers

EricSa_MS (Moderator):
You'll be able to find the transcript of this chat soon on the MSDN Web site at Please see the chats schedule for upcoming topics at https://msdn.microsoft.com/chats/.

Allen (Expert):
Thanks for you questions everybody. We hope this has been helpful to you.

Santosh (Expert):
Thanks for participating. Hope to do this again soon.

Top of page