A Hole In My Head

Doron Holan's musings on drivers and other nibbles and bits

Browse by Tags

Tagged Content List
  • Blog Post: Arbitration and Translation, Part 1

    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...
  • Blog Post: What is IRQL?

    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...
  • Blog Post: How do I cancel an IRP that another thread may be completing at the same time?

    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...
  • Blog Post: Inconceivableable

    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,...
  • Blog Post: Once not disableable, forever not disableable

    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...
  • Blog Post: Why I should not be writing applications ;)

    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...
  • Blog Post: How to share HW resources with another driver not in the same PnP hierarchy

    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...
  • Blog Post: Setting a security descriptor on a legacy device object

    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...
  • Blog Post: Fast Resume and how if affects your driver

    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...
  • Blog Post: Vista IO manager changes in handling FILE_DEVICE_SECURE_OPEN

    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...
  • Blog Post: Making sure the IO manager evaluates the security of your 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...
  • Blog Post: Devices and namespaces (or how the IO manager handles file creation)

    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...
  • Blog Post: Creating symbolic links for an anonymous FDO or filter

    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...
  • Blog Post: Having two names is not necessarily better than one

    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...
  • Blog Post: Problems with not having a current IRP stack location, part 2

    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)...
  • Blog Post: Your completion routine context can be anything you want

    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...
  • Blog Post: Filtering HID collections and setting I/O flags

    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...
  • Blog Post: More Vista remove lock (remlock) changes

    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...
  • Blog Post: INTERFACEs can contain both input and output parameters…and not just function pointers

    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...
  • Blog Post: Power relationships in a bus 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...
  • Blog Post: Problems associated with arming yourself for wake

    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...
  • Blog Post: How many Power IRPs can I have pended in my stack at one time?

    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...
  • Blog Post: Which PnP and power IRPs are synchronized against each other?

    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...
  • Blog Post: Which PnP IRPs are state changing?

    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...
  • Blog Post: How does WdfDeviceSetFailed work? (AKA the case of the missing WDK documentation for REENUMERATE_SELF_INTERFACE_STANDARD)

    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...
Page 1 of 4 (86 items) 1234