Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » WDM   (RSS)

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 Read More...
Posted Sunday, June 29, 2008 11:16 PM by doronh | 1 Comments
Filed under: ,

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 Read More...
Posted Tuesday, March 18, 2008 4:55 PM by doronh | 0 Comments
Filed under:

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 Read More...
Posted Tuesday, March 18, 2008 8:21 AM by doronh | 0 Comments
Filed under:

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 Read More...
Posted Friday, November 09, 2007 11:12 AM by doronh | 5 Comments
Filed under:

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 Read More...
Posted Wednesday, October 24, 2007 3:56 PM by doronh | 1 Comments
Filed under: , ,

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 Read More...
Posted Tuesday, October 16, 2007 4:45 PM by doronh | 1 Comments
Filed under: ,

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 Read More...
Posted Monday, October 15, 2007 10:33 AM by doronh | 1 Comments
Filed under:

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 Read More...
Posted Friday, October 05, 2007 8:00 AM by doronh | 1 Comments
Filed under:

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 Read More...
Posted Thursday, October 04, 2007 9:00 AM by doronh | 1 Comments
Filed under: ,

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 Read More...
Posted Wednesday, October 03, 2007 11:55 AM by doronh | 4 Comments
Filed under:

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 Read More...
Posted Thursday, May 03, 2007 10:21 AM by doronh | 0 Comments
Filed under:

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 Read More...
Posted Wednesday, April 18, 2007 1:20 PM by doronh | 3 Comments
Filed under:

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 Read More...
Posted Monday, April 09, 2007 9:04 AM by doronh | 2 Comments
Filed under: ,

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 Read More...
Posted Friday, April 06, 2007 2:25 PM by doronh | 0 Comments
Filed under: ,

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 Read More...
Posted Monday, March 26, 2007 5:19 PM by doronh | 0 Comments
Filed under: ,
More Posts Next page »
 
Page view tracker