Browse by Tags

A while back Jake Oshins answered a question on NTDEV about bus arbitration and afterwards I asked him if he could write a couple of posts about it for the blog. Here is part 1.
History Lesson
In the history of computing, most machines weren’t PCs. PCs, and the related “industry standard...

Jake Oshins wanted to write about IRQLs and I am gladly letting him use my blog as a platform. Here it is…
I’ve found myself explaining IRQL a lot lately, sometimes to people who want to know because they’re trying to write Windows drivers and sometimes to people who are accustomed to Linux or some...

Let's say that you allocated a PIRP and sent it down your device stack. You free the PIRP in the completion routine and then return STATUS_MORE_PROCESSING_REQUIRED. To make life more fun, you decide that you want to be able to cancel the sent IRP after you have sent it so you try to do it simple like...

I have no idea who created the name for PNP_DEVICE_NOT_DISABLEABLE, but I probably have the same reaction as you ... "seriously? that is what they named?" I mean come on, I think it could have at least been named PNP_DEVICE_CANNOT_BE_DISABLED. I am sure you can think of some better names too. If so,...

One interesting quirk about the PNP_DEVICE_NOT_DISABLEABLE state is that once it has been set and the PnP manager has processed it, the state is sticky. By sticky I mean that even if you attempt to clear this bit on a subsequent IRP_MN_QUERY_PNP_DEVICE_STATE IRP, the PnP manager ignores your changes...

The first driver I owned when I started at Microsoft in 1997 was i8042prt.sys, the driver that controls your PS2 mouse and keyboard. I had the job of upgrading it from an NT4 legacy style driver to a PnP enabled Windows 2000 driver. Of course my dad asked "didn't keyboards and mice work before you got...

First, I have to say that I don't agree with this design pattern at all . I think it leads to too many problems and complications that are not worth the pain. The only reason I am writing this entry is that I have seen so many people get this wrong or not account for some details and I want to make sure...

Setting the security descriptor allows you to control who can open a handle to the device object. Typically you can call IoCreateDeviceSecure to create the device object and have the correct DACL from the start. One issue with IoCreateDeviceSecure is that the SDDL string is limited to what it can describe...

Fast resume, which was introduced in Windows XP, is often mentioned when implementing power support in your WDM driver. But what does "fast resume" mean and when implementing fast resume, what side effects occur in your driver? I'll to answer both of these questions as well as the reasoning behind this...

After having the IO manager developer review my last 2 posts, he pointed out to me that the IO manager handling of FILE_DEVICE_SECURE_OPEN (FDSO) has changed slightly in Vista. News to me and probably news to all of you as well. The change involves the case where there is a file system mounted on a device...

Last time I wrote about how the IO manager handles the creation of file handles and pointed out a potential security hole. If there is a namespace (or path) after your device's name in the path passed to CreateFile, the IO managed does not evaluate the security settings set on your device and relies...

Ever wonder how the creation of a handle works? It doesn't matter type of resource the handle you are opening is backed by (a COM port, a file, a network share, a custom piece of hardware, etc), it all goes through CreateFile (which should be a little obvious since the only way to open an type of handle...

As I wrote about previously, naming your FDO has some side effects that you may not want to incur. But what if you want to give your device a fixed symbolic link name (by calling IoCreateSymbolicLink ), such as \DosDevices\Foo1, in addition to your device interface GUID? Does an unnamed FDO (or filter...

Every physical device object (PDO) must have a name . Furthermore, if you read the entire MSDN page, you see that any device attached to the PDO must not have a name. Why does such a rule exist? To answer this question, let's explore what happens if more than one device in the stack has a name. Furthermore...

This problem falls into the category being hidden by a macro that does not indicate in its name what it touches. If you call IoMarkIrpPending on an IRP that you allocated in your driver, chances are that you are corrupting memory. First, let's look at the implementation of this function (from wdm.h)...

It sounds obvious, but sometimes it needs to be stated. For instance, let's say that you are allocating your own IRP, your context contains I/O related data (like a URB ) and you encounter the issue where the DeviceObject passed to your I/O completion routine is NULL. Adding another stack location is...

Over the past 3 years or so, I have been casually referring to KMDF as the ultimate driver compat layer. Just like Windows has an application compatibility layer which shields applications from OS changes, KMDF provides the same type of compatibility across device stacks. For the most part each stack...

First, a correction to my previous remlock post , where I said that you must still compile your driver as chk before you can see the benefits of the driver verifier's new remlock checking functionality. You don't need a chk version of your driver! The owner of DV informed me that a fre version of the...

When you look at the documentation for an INTERFACE and IRP_MN_QUERY_INTERFACE , it mentions that the INTERFACE structure is the input provided to the interface provider (set the by the driver querying for the interface) and the remainder of the interface structure is considered output (set by the driver...

A small but important rule in WDM is that while a PDO is in D0, the parent must be in D0 as well. A very simple statement that can cause a lot of trouble ;). What I have seen is that very few WDM drivers enforce this rule (while KMDF does implement this rule, so all KMDF drivers inherit this for free...

Hindsite in this case is 20/20, but arming your device for wake can open yourself up to multitude of race conditions and hard problems. Some of them you can solve in your driver, some of them you must accept that they are there and leave them be. Arming yourself for wake can be broken down into 2 scenarios...

First, we have to list all of the different power IRPs a driver can receive. The minor function is not the only value that determines the type of power irp, you also have to look at if the power irp reflects the system or device power state. Dx means any device power state lower the D0, Sx means any...

In my previous post , I talked about how state changing PnP IRPs (refered to from now own as just PnP IRPs) are serialized against each other and briefly mentioned which power IRPs they were synchronized against. This merits its own entry. In short, PnP IRPs are only synchronized against system power...

While not clear in the WDK documentation, there are two types of PnP IRPs: state changing and non-state changing. Does this distinction matter? Absolutely. State changing PnP IRPs have a contract associated with them while non-state changing IRPs have no contract whatsoever. Before I get into the gory...

KMDF is built on top of public interfaces. This means that it uses only APIs found in the WDK (or what was the DDK). This creates a dilemma. On the one hand we want to add features to the framework that are compelling and add value, but on the other we cannot rely on the OS to provide this functionality...