OSRLogo
OSRLogoOSRLogoOSRLogo x Subscribe to The NT Insider
OSRLogo
x

Everything Windows Driver Development

x
x
x
GoToHomePage xLoginx
 
 

    Tue, 21 Oct 2014     104945 members

   Login
   Join


 
 
Contents
  About This Site
What's New?
OSR Dev Blog
The NT Insider
The Basics
File Systems
Downloads
ListServer / Forum
Driver Jobs
Store
  Express Links
  · The NT Insider Digital Edition - Sept-Oct 2014 Now Available!
  · Sept-Oct Issue of The NT Insider Released!
  · Writing WDF Drivers: Advanced Implementation Techniques
  · OSR Seminar Schedule
  · Windows 8.1 Update: VS Express Now Supported

Beyond IRPs: Driver to Driver Communications

It’s not like we keep track, but one of the most frequent questions we receive, year in and year out, is: “I have two drivers running in the same system. What’s the “best” way for them to communicate?”

Naturally, when you think of two kernel mode drivers communicating, the first thing that comes to mind is sending IRPs from one driver to the other using IoCallDriver(…). This works pretty well (after all, it is the typical method of communication used in the operating system!), especially if the communication is infrequent. When thinking about using IRPs for communicating events or information between two kernel mode drivers, the most important thing to keep in mind is that one driver can always build an IRP and send it to another driver using IoCallDriver(…). There’s no need to use any Zw system services, or for the first driver to “open” the second.

For cases where driver-to-driver communication is more frequent, or a shared context area (containing, perhaps a shared queue or two and even shared locks) is required, there is another simple, yet highly flexible, method. This method relies on the fact that all drivers reside in the same area of the system address space, regardless of the (user) process context. Thus, every (kernel mode) driver in the operating system is within the address space of every other (kernel mode) driver.

If Driver A wants to communicate with Driver B, one simple way to do this is to have the two drivers share a “context block”, the format of which is known to both of these drivers. This context block will be located in non-paged pool (See Figure 1). During initialization, Driver A allocates the context block and fills it in with some data. This data may include initialized queue list heads, initialized queue spin locks, or even pointers to functions that reside within Driver A. Once the block has been allocated and initialized, Driver A builds an IRP with a function code IRP_MJ_INTERNAL_ DEVICE_CONTROL. One easy way to do this is by calling IoBuildDeviceIoControlRequest(…). Driver A puts a pointer to the context block (the kernel virtual address of the context block, to be specific) in Irp->UserBuffer in the IRP. And then Driver A sends the IRP to Driver B using IoCallDriver(…).

(Insert Figure 1 from online content, drawing, entitled:  Two Drivers, Sharing a Context Block)

Figure 1 – Two Drivers, Sharing a Context Block

Driver B receives the IRP from Driver A at its DispatchDeviceControl(…) entry point. Driver B saves away the pointer to the context block that it finds in Irp->UserBuffer, and fills in any information it wants to pass to Driver A into the context block. Driver B then completes the IRP, by calling IoCompleteRequest(…). This completion is detected by Driver A any way it pleases (using a completion routine, synchronously waiting for the request to complete, or whatever).

At this point, both Driver A and Driver B have a pointer to this shared context block in non-paged pool. Each driver can access and manipulate the data in the shared context block (perhaps acquiring a shared spin lock and adding things to a shared queue), and can even call functions in the other driver, via pointers that have been pre-filled into the context block.

We’ve used this simple communication method, using a shared context block, with direct functions calls from driver to driver, in several projects and can attest that this is a very effective and efficient mechanism for driver-driver communication.

Of course, this is just one mechanism for communicating between drivers. Need to only communicate the state of an event? How about sharing a named event between two drivers? The possibilities are endless.

Once you realize that both drivers share the system portion of the kernel mode address space, and that this address space doesn’t change with the user process that’s mapped, the possibilities are endless. So, don’t be constrained by just using IRPs. Get creative!

Related Articles
Properly Pending IRPs - IRP Handling for the Rest of Us
The Truth About Cancel - IRP Cancel Operations (Part II)
That's Just the Way It Is - How NT Describes I/O Requests
The Truth About Cancel - IRP Cancel Operations (Part I)
Secrets of the Universe Revealed! - How NT Handles I/O Completion
What's in a Name? - Cracking Rename Operations
Rolling Your Own - Building IRPs to Perform I/O
Rules for Irp Dispatching and Completion Routines

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

"useful"
I found it very useful, Thanks very much !

14-Jan-09, Lirong Shi


Post Your Comments.
Print this article.
Email this article.

Windows Internals and SW Drivers
LAB

Dulles/Sterling, VA
20-24 Oct 2014

Developing File Systems for Windows
Seattle, WA
4-7 Nov 2014

Kernel Debugging and Crash Analysis
LAB

Boston/Waltham, MA
10-14 Nov 2014

Writing WDF Drivers: Core Concepts
LAB

Palo Alto, CA
12-16 Jan 2015

 
 

Windows Debugger

Checked Build Downloads
29-Apr-10

Debugging Symbols

WDK Documentation

Windows WDK

 
 
x
LetUsHelp
 

Need to develop a Windows file system solution?

We've got a kit for that.

Need Windows internals or kernel driver expertise?

Bring us your most challenging project - we can help!

System hangs/crashes?

We've got a special diagnostic team that's standing by.

Visit the OSR Corporate Web site for more information about how OSR can help!

 
bottom nav links