My travels with WDF : UMDF

And here you thought I had a cloaking device

patman — Tue, 01 Dec 2009 23:48:00 GMT

Got a good one to share with the group;

Q: Can I make a kernel mode driver that opens a handle and talks to a UMDF based driver in another device stack?

A: Why yes you can! Quite simply done provide you follow all the rules. This is a variant of the UMDF initiated cross stack communication we talked about a while ago, but KMDF, being a DF (driver framework) supports essentially the same IoTarget model that UMDF does.

Now Playing – Rush Far Cry

I/O Queues and You

patman — Mon, 24 Aug 2009 21:48:00 GMT

I got an interesting question via mail recently, “Do I really need to create a queue object in my UMDF driver?” Well, this is another one of those, “only if” type questions.

For instance - Only if your driver is not handling any I/O from a top edge method which results in the I/O manager being involved in talking to the UMDF driver for those operations. At that point you don’t need to create a queue object.

Example -

The UMDF driver wants to send I/O to a KM driver in another stack based on some form of simple event being raised and consumed by the UMDF device. Provided you have a handle open to that KM stack and have created the I/O target object (all shown here) you can simply create and format a request, and then send that request to the target.

Should you want to send requests asynchronously and need a completion callback, you can still do so with out requiring a queue. The driver will have to implement a IRequestCallbackRequestCompletion::OnCompletion method. And during the packing of the request to submit, invoke the request’s SetCompletionCallback prior to invoking the FormatRequestxxx method.

Once the lower driver has completed the request, the OnCompletion method will be invoked. Voilà.

There’s one little caveat around UMDF completion routines that I talked about a while ago and I should bring it up here; you can only define one OnCompetion method per device object.

Cross stack communications

patman — Sun, 16 Aug 2009 23:57:00 GMT

The subject of how to talk to another device stack has come up again, and since I only briefly touched on it a year ago, I thought it would be good provide some code snippets and a little more background on how to accomplish such a feat. The gist of what we are trying to do here is load a UMDF based driver for one device, open a handle to a different device stack and submit I/O to that stack. To do that in UMDF we need to establish a UMDF I/O target and the foundation of that I/O target object is a file handle.

So the basic building blocks are as follows;

    //
    // Add these to your base class
    //
    IWDFIoTarget m_ExternalTarget;
    HANDLE m_ExternalHandle;

You can add these to any of your existing classes, but it probably serves best to house these elements in your Device or Queue classes. They are tied to the lifetime of the I/O you are sending to the external target, so where you house them is really down to your design and implementation.

Based on your needs and how you design your driver, you will need to determine when you proceed with the following sections. For simplicity, I’ll establish the connection to the remote stack in the Device Initialization routine, but the same can be done at just about any other point of initialization or even during a later phase of driver operations.

    IWDFFileHandleTargetFactory * pFileHandleTargetFactory = NULL;

   // .......
   // abstracted device init code for brevity
   // ........

    if (SUCCEEDED (hr)) 
    {
        m_FxDevice = fxDevice;

        //
        // We can release the reference as the lifespan is tied to the 
        // framework object.
        //
        fxDevice->Release();
    }

    // Open the device and get the handle.

    m_ExternalHandle = CreateFile (
        DeviceStack,  // path device stack to open
        GENERIC_READ | GENERIC_WRITE, // these flags are driven more by the target stack.
        FILE_SHARE_READ | FILE_SHARE_WRITE, 
        NULL,         
        OPEN_EXISTING,
        FILE_FLAG_OVERLAPPED, // You must open the handle with this flag
        NULL);        



    if (INVALID_HANDLE_VALUE == m_ExternalHandle) 
    {
        DWORD err = GetLastError();

        TraceEvents(
            TRACE_LEVEL_ERROR, 
            TEST_TRACE_DEVICE, 
            "%!FUNC! Cannot open handle to device %!winerr!",
            err);

        hr = HRESULT_FROM_WIN32(err);
    }

    if (SUCCEEDED(hr)) 
    {
        hr = m_FxDevice->QueryInterface(IID_PPV_ARGS(&pFileHandleTargetFactory));

        if (FAILED(hr))
        {
            TraceEvents(
                TRACE_LEVEL_ERROR, 
                TEST_TRACE_DEVICE, 
                L"ERROR: Unable to obtain target factory for creating FileHandle based I/O target %!hresult!",
                hr);
        }
    }

    if (SUCCEEDED(hr)) 
    {
        hr = pFileHandleTargetFactory->CreateFileHandleTarget(m_ExternalHandle, &m_ExternalTarget);
    }

You’ll need to release the reference to the pFileHandleTargetFactory object, either by a SAFE_RELEASE macro, direct call to the Release(); method, or by using a CComPtr /CComQIPtr class wrapper on the object on declaration. You’ll also need to clean up the Windows file handle when it is no longer needed. And IF the IWDFIoTarget object's lifetime scope is narrower than the device object's lifetime, you will need to call DeleteWdfObject method on m_ExternalTarget.

At this point, you have your remote target object to use in sending I/O to that secondary device stack.

What I’ll cover next is going to be some hefty theory on when you should and don’t need to use queue objects and how to send I/O to an external stack based on whether you have a queue or not. Fun! ;)

The feline, it has escaped the fabric based containment pouch!

patman — Tue, 04 Aug 2009 23:09:00 GMT

One of the things I’ve been wanting to do for a while is put Isochronous transfer support back in to the 1394 Hybrid sample. Now that Windows 7 has shipped and we’re picking up projects we want to do during this period of product transitions, I felt the time was right to start this up. All happened to dove tail nicely with the implementation of Direct I/O support which was added to UMDF 1.9 in the end, allowing me to essentially kill two birds with one stone. What we’ll end up with is a demonstration for various methods of I/O flow through this hybrid driver stack as well as having another demonstration of Isochronous transfers for 1394 devices again. Hooray us!

So, I’m happy to report that work has begun on said project, and as a result I’ll have some tidbits, details and follies to present to you along this path of coding fun in the coming weeks.

Now Playing – Geddy Lee My Favorite Headache

UMDF Debugging talks online

patman — Wed, 06 May 2009 23:01:38 GMT

Our wondrous Abhishek did a series of Debugging UMDF driver talks and I’m happy to say we now have the first three live on line!

In these he covers some of the basics; where to find and how to use WDFVerifier, how to use some of the UMDF Debugger extensions and some basic debugging UMDF scenarios.

http://www.microsoft.com/whdc/devtools/debugging/umdftraining.mspx

As always, any feedback or questions you guys may have, feel free to ping me!

Double filtered for added UMDF flavor.

patman — Mon, 27 Apr 2009 23:54:00 GMT

In my previous post about Filter Drivers, I mentioned that this time I would focus on a more UMDF centric stack. This one is pretty simple.

For UMDF only based driver stacks, the single most important directive is the UmdfServiceOrder INF directvie. As I mentioned last post, that directive is a left to right list determining load order for the drivers contained in the device stack. With the right most element in that list being the the lowest driver loaded.

Here are two examples – First a UMDF two driver stack with an upper filter;

[<mydriver>_Install.NT.Wdf]
UmdfService=UMDFFunction,WUDFFuncDriver_Install
UmdfService=UMDFFilter,UMDFFilter_Install
UmdfServiceOrder=UMDFFilter, UMDFFunction

Now to install a lower filter, simply flip the order in that directive;

[<mydriver>_Install.NT.Wdf]
UmdfService=UMDFFunction,WUDFFuncDriver_Install
UmdfService=UMDFFilter,UMDFFilter_Install
UmdfServiceOrder=UMDFFunction, UMDFFilter

The last tidbits here are; for a device stack that only contains UMDF drivers, there is no need to add any of these settings in the INF;

[<mydriver>_Device_AddReg]
; Load the redirector as an upperfilter on this specific device.
; 0x00010008 - FLG_ADDREG_TYPE_MULTI_SZ | FLG_ADDREG_APPEND
HKR,,"UpperFilters",0x00010008,"WUDFRd"

And also as before, the filter driver needs to be a good citizen on the stack, pass on requests it does not own to the next driver and don’t touch anything unless you must. The previous code samples I’ve posted all still apply, but the basics are; GetDefaultIoTarget, FormatUsingCurrentType and Send.

There’s no need to change any code for a basic filter driver based on its load order (upper or lower filter). As you get in to more advanced driver functionality you may find a need to change default behaviors. For those cases, you can always send us mail. :)

There was also some questions about why would you want or need to be an upper or lower filter driver. That one gets in to a bit more of a “it’s up to you” but the core logic that applies to WDM / KMDF drivers applies to UMDF drivers (save the parts about bus drivers *g*).

Genuine UMDF filtered drivers

patman — Thu, 16 Apr 2009 03:30:00 GMT

Filter drivers have come up in conversations recently (both internal and external), so I wanted to take some time here to address some of the issues that were brought up with regards to UMDF filter drivers and how to make them. Note: I’m not going to cover all the configuration dynamics available for UMDF filter drivers in this one post simply to avoid the risk information overload and clutter, so expect a couple of posts on this subject.

Let’s start with some basics, we’ll simply demonstrate how to configure and load a UMDF Filter as an upper filter driver to a kernel mode driver (KMDF or WDM) in the same INF-

As some of you may remember from my earlier posts, a UMDF filter driver should use the SetFilter(); property in the DeviceInitialization routine. This tells the Framework to do a couple of things for us automatically:

Send I/O for which the Filter has not registered a callback for to the next logical driver in the stack. Example: Your filter driver registers a DeviceIoctl callback method, but not read or write. As a result your filter driver will only see IOCTLs
Automatically forward file create cleanup and close so there is no need to invoke the AutoForwardCreateCleanupClose method.

That covers the really basic code required at driver / device initialization time. Now we need to add the pertinent sections to the INF file. As we’re going to focus on being an upper filter for this example, you need to make the following modifications to your INF (in addition to the normal UMDF specific sections);

[<mydriver>.NT.Wdf]
UmdfService = "<mydriver>", <mydriver>_Install
UmdfServiceOrder = <mydriver>

[<mydriver>_Device_AddReg]
; Load the redirector as an upperfilter on this specific device.
; 0x00010008 - FLG_ADDREG_TYPE_MULTI_SZ | FLG_ADDREG_APPEND
HKR,,"UpperFilters",0x00010008,"WUDFRd"

So a couple of things to note here -

One is the UmdfServiceOrder directive, this is load order specific. I’ll address a more UMDF centric stack in the next post, but for those of you who like to work ahead, this is a left to right reading list to determine stack order.

Second thing is the registry key addition section. As WUDFRd is the kernel mode transport service for UMDF drivers, WUDFRd is the upper level filter driver to a kernel mode driver.

Now that your driver is loaded as an upper filter, what should your driver do in order to be a good citizen in the stack? Short answer is, as little as possible. You perform the same steps for handling PnP and Power as you would for any basic UMDF driver (one that lets the framework handle the heavy lifting for those two). You register your I/O callback routines and build your queues just like any normal UMDF driver, the only additional requirement here is to forward I/O requests as required.

For this example, let’s just demonstrate using a fairly simple pass through driver. How you actually implement this is up to you, but the basic requirements here are - as your driver receives the request on the queue, it needs to pas pass it on to the next driver in the stack. So first you need to get the default I/O target (next driver in the stack). Next, format the request using the same type and then finally, send the request. A condensed version would be something along these lines;

    IWDFIoTarget * kmdfIoTarget = NULL;
    
    this->GetFxDevice()->GetDefaultIoTarget (&kmdfIoTarget);

    Request->FormatUsingCurrentType();

    hr = Request->Send (
        kmdfIoTarget, 
        0,  // 0 Submits Asynchronous else use WDF_REQUEST_SEND_OPTION_SYNCHRONOUS
        0);

I also have some more basic code here for you to peruse.

So now we have a basic UMDF upper filter driver on top of a kernel mode driver.

Now Playing Capitals v. Rangers

Think globally, lock at the smallest scope possible.

patman — Sat, 24 Jan 2009 02:26:00 GMT

Yes, I know that's a rip off of a ThinkGeek shirt (which I own).

Well, this is going to be my second post on this topic (okay, third), but as it managed to rear its head again recently, what better time to blog. And I'm going to also blog it simply to prove to Doron that I can provide something other than comic relief.

You'll notice a few of the existing UMDF samples have their locking constraint set to WdfDeviceLevel in their Device Initialization routines and some others don't set it at all, which defaults to WdfDeviceLevel.

So, what is the problem with doing it the way some of those samples are? Well, it does put the widest locking scope on all your objects that the device holds, meaning the device framework acquires a device presentation lock before passing some I/O to their driver callbacks. This results in serialized calls to that callback for your file and queue operations which is really unnecessary. There's a really good table in the Windows Driver Foundation book (pg 390) that shows what callbacks are serialized when using the Device Scope level. And to save some of you looking it up, I'll tell you now that yes, OnDeviceIoControl, OnRead, and OnWrite will get serialized if you set the locking constraint to Device Level.

So unless your driver really requires a synchronization scope that wide, initialize that constraint to None;

HRESULT
CVDevDevice::Initialize ( 
                         __in IWDFDriver           * FxDriver,
                         __in IWDFDeviceInitialize * FxDeviceInit)
{
    IWDFDevice * fxDevice = NULL;

    HRESULT hr = S_OK;

    FxDeviceInit->SetLockingConstraint (None);

    {
        IUnknown * unknown = this->QueryIUnknown ();

        hr = FxDriver->CreateDevice (FxDeviceInit, unknown, &fxDevice);

        unknown->Release ();
    }

    if (SUCCEEDED (hr)) 
    {
        m_FxDevice = fxDevice;
        fxDevice->Release();
    }

    return hr;
}

The primary differences here between KMDF and UMDF are UMDF doesn't set an execution level, so the likely hood of you bug checking by screwing this up is greatly reduced. :)

Edit: For those on RSS, sorry about the embedded style sheet nonsense, I keep forgetting to clear that tick box

*Currently playing - King's X Silent Wind

When it leaks, it pours

patman — Sat, 17 Jan 2009 00:09:00 GMT

Greetings from the Pacific Northwet. After our recent Snow-pocalypse, we also suffered a run of flooding. Amazingly enough, it wasn't directly due to the 13+ inches of snow I had at my house, it was a combination of the snow and the monumental amounts of rain that followed. Quite a few people were literally cutoff from the rest of Washington State as their egress roads were under rivers. The only hassle I had to suffer was one of FedEx being a day late with a new laptop. Oh bother.

The leaking I did have to suffer was of my own doing. It was my usage of IWDFIoRequest::GetCompletionParams in a test driver. In trying to be a good boy and clean up my I/O requests, and especially since I was going to be using asynchronous I/O, I wanted to get the completion parameters with out having to mess around with a completion routine. Funny thing is, that call takes a reference on the pointer returned. All was fine and dandy until I turned on Object leak detection (using WdfVerifier) and reference tracking. Debugger breaks prevent things from running smoothly I've found. :)

Now those of you much smarter than me would have told me I could have avoided that by using the CComPtr class on the CompletionParams interface as shown in the sample, but if you're like me and still think you know better and didn't use the CComPtr class, you had best make a subsequent Release() call.

pWdfRequest->GetCompletionParams (&CompletionParams);

hr = CompletionParams->GetCompletionStatus ();
CompletionParams->Release();

Now to answer a question nobody asked, yes my dog LOVES snow.

I'll spare you all part two of my FiOS TV installation rant because the guy who came out and installed the CableCard in my TiVO made up for the previous incident, ten fold. All I can say is wow. I really enjoyed watching Rush R30 in un-bitstuffed HD via the Palladia channel. Thank you FiOS.

*Currently playing - Porcupine Tree Blackest Eyes

How to find the droids you might be looking for

patman — Tue, 30 Sep 2008 01:36:00 GMT

Most of you at the DDC will notice that I'm not at the DDC. I'm guessing that makes me one of the "juniors" that Bob was referring to. ;)

4.) How do you build debugging techniques into your driver? Ie, DbgBreakPoint, ASSERT, etc - which is best in various situations?

This is one of those personal preference type questions. For the sake of lineal chatter, I'll just use ASSERT in my commentary. But when I say "ASSERT" you can make the determination on which one to use given your own working methods.

So that preamble aside, it's on with the show. I like to have staged text output via a debug trace level as a first tier technique. Something along these lines;

#define FILTERNAME        TEXT("mydriver")
#define DRIVERNAME        FILTERNAME TEXT(".sys")
#define DRIVERNAME_DBGOUT FILTERNAME TEXT(": ")

#if DBG
#define DBG_TRACE_VERBOSE      0
#define DBG_TRACE_MINIMAL      1
#define DBG_WARNING            2
#define DBG_ERROR              3
#define DBG_FATAL              4 

extern unsigned char DebugLevel;

#define DBG_PRINT( l, _x_ )                   \
    if( (l) >= DebugLevel )      \
    {                                         \
      KdPrint((DRIVERNAME_DBGOUT));         \
      KdPrint( _x_ );                       \
    }
#else  // DBG

#define DBG_PRINT( l,_x_ )

That allows me to compartmentalize failures and thusly allows me to build handlers for each. The question of what to do in each of those situations is another personal preference. As you can see from the error levels above, I follow patterns of building in handlers that fall in to - terminal, really annoying, nuisance, does it work and assuage.

I'll ASSERT more frequently for the nuisance issues, but also for the terminal, and some of the really annoying issues. Nuisance issues such as that HANDLE disappeared while I was using it, better ASSERT. This is usually when I find that the other thread using that handle wasn't synch'd properly...laugh all you want, you've done it too. :)

Using those levels as a guide, I craft an appropriate follow up action. But here I let the driver tell me what to do and it does that based on its end usage. For example;

  Status = IoCreateDevice (
      DriverObject, 
      sizeof (DEVICE_EXTENSION), 
      &DriverName,
      FILE_DEVICE_UNKNOWN, 
      DeviceType, 
      FALSE, 
      &DeviceObject);
  if (!NT_SUCCESS (Status)) 
  {
    DBG_PRINT (DBG_FATAL, TEXT(("Failed IoCreateDevice: 0x%x\n", Status)));
    ASSERT (DeviceObject);
    return Status;
  }

Would I use that ASSERT in a test driver? Not likely, all too often our test cases attempt to invoke failures in just those sort of areas and we run chk (debug, no_opt, etc.) builds in our labs frequently. So that ASSERT would be triggered constantly. You could also argue that in a shipping driver you would hit it in a lab under low resource simulation testing, but unless you plan on running low resource simulation 24/7, the nuisance factor is diminished greatly. But having the debug print there is a means for you to see if something happened in a retail / fre build of the driver. You can also wrap Windows logging methods with the same mentality such as WPP and ETW.

All of the above starts with the driver though. The more complex the driver, the more robust the debugging logic, so some of my internal test drivers have one or two ASSERT calls and maybe a couple of lines of debug print statements. So if you peek at the 1394vdev hybrid sample you can get a better idea of my patterning. The lack of ASSERT calls was a design choice based on the pattern established by the previous versions of that sample driver.

So for those of you at the DDC, enjoy the DDC! If you feel like making Peter laugh, ask him why I'm such a dork.

*Currently playing - Gravity Eyelids Porcupine Tree

It's flick, then swish

patman — Thu, 11 Sep 2008 23:17:00 GMT

So the next part of the little Q&A series on...well, QA;

3.) What security considerations do you take into account when designing and developing a kernel mode driver?

Validate user mode pointers and check the buffers to and from user mode. ;)

That was a little inside joke for the person who asked the question. Seriously security and kernel mode are almost at odds with one another when you really think about it. Kernel mode is implied to be a trustworthy environment so anybody that's down there with you is expected to behave like a good citizen. And anybody that can talk to you from the nether region (user mode) should be treated as an enemy. As security for kernel mode drivers is something of a loaded question in the end, the best advice I can offer here is; Anything that can be accessed by anybody outside your driver should have some form of defense built in to it. I.e. if you have an external callback, think about how that that could be used as an attack entry point. Could somebody float recursive calls to that callback and cause a stack over flow?

That's about the only weird tip I can give other than using what's published here and here as a base.

And finally, my apologize to Bob, I guess I stole some of his thunder. :)

*Currently playing - Rush Faithless

It's all in the wrists

patman — Wed, 03 Sep 2008 20:46:00 GMT

I got a few interesting questions recently, which was helpful because I was having a tough time finding good material for you guys and gals of late. That's the problem with working on the next Operating System, I can't tell you about all the cool stuff yet. *g*

So here's today's question (in two parts);

1.) Do you use a single system to code, compile, verify and test a kernel driver?

Nope, pretty much, kinda sorta and nope. We're actually pretty wide open as far as coding environments around here. Across this team alone you'll find Visual Studio, gVIM, Slick Edit and probably 2 or 3 other IDEs in use (I've actually even seen notepad used once). The only coding requirements are really based around formatting, naming convention(s) and the like. Which is really fun when you get somebody who crafts a build script that goes out and checks for tabs rather than spaces in source code. ;)

Our compiler is a different story, pretty much everything we build is done so in very much the same environment shipped in the WDK. Yes there are some caveats, but that's only because I can't speak for every team and some of our internal process isn't really meant for general consumption. But our compiler is linked to our source control environment which makes wrapping a full one stop shopping coding / compiling / source control environment more of a challenge. There are a lot of great tools internally to get most of it done depending on your IDE of choice. Personally (if you haven't figured it out yet), I use Visual Studio as my source editor, a couple of internal tools to manage source control from within Visual Studio and then build in that external razzle environment. Like I said before, I'm still not prone to giving up some of my past. :)

Verification is another tricky question (somewhat open ended really). If we're talking about compile time code verification, then yes we do have a somewhat unified system in place. We use the same tools we ship in the WDK, PREfast and Static Driver Verifier. Our internal build system actually runs PREfast for us as a post build process.

Finally our testing is a real Pandora's Box type question. We do use the same tools we ship externally, Application Verifier, Driver Verifier and WDF Verifier, but we also develop other tools internally to cover scenarios we just can't reach using those tools. Here again, it's not a one stop shopping system across the Windows teams, but for those of you going to the DDC, Bob, Shyamal and Wei will be giving a shared secrets talk which will cover some more of what we do internally.

2.) How do you use virtualization software in the test and dev process?

This is my favorite one, I've been on a big push around here to get more people using virtual environments. Personally I've been using Virtual PC since 2005, I did some test work for them on that release, so I got in on the ground floor somewhat. Anyway, I use VMs to extend test coverage primarily on down level OSes. I keep "clean" installations of Windows XP SP1, SP2, SP3, Server 2003, Vista and Vista SP1 and some variants of those on my system. A lot more people are starting to use HyperV and Virtual PC around here, but given some of the limitations of those environments (e.g. inability to map USB hardware) and other little nuisances we can't use them for a full end to end test beds, this is a little more intrusive on the kernel side where you may require a piece of hardware. I know there are other virtual environments out there that do allow these features, but we're kind of prone to using our own products. :)

*Currently playing - King's X Alone

You can have a co-driver, a co-pilot and now, a co-installer

patman — Fri, 18 Apr 2008 18:47:00 GMT

They're bbbbbbbbaaaaaaaaaaacccccccccckkkkkkkkkkkkkkkkkkk. After some incantations, Ouija boarding and me dancing around a build server with a spindle of DVDs on my head and sacrificing a serial port mouse, the fixed 1.7 coinstallers are available.

Sorry for the delay and the initial issue... The 18002 build of the WDK should be out shortly (about a month...or so) which will have all the WDF redistributables back in their original homes.

Thanks for your support.

*Currently playing - The Who Won't get fooled again

How to jiggle the handle(s) and get your 1.7 to work in Vista

patman — Wed, 05 Mar 2008 23:24:00 GMT

As people who write drivers are something of a rare breed, I know we probably share a lot of common readers between our Driver blogs and via the OSR boards, but just in case the three or four of you who read my blog haven't seen this, I wanted to make sure it got out there.

We had a bit of a stumble with the 1.7 coinstaller package that went out with the WDK recently.

We're pretty close to being done with a fix as Bob said, so fret not. I'd like to thank those who pestered me about the issue for helping narrow it down, and also those who pestered the external boards and email alias.

Now, if we could all join hands around the camp fire and sing "row, row, row your boat" to complete this little moment of community unity.

Still working on the Visual Studio stuff, but those of you with free time are more than welcome to skip ahead.

*Currently playing - Not a single thing...

Intellisense-ational!

patman — Tue, 29 Jan 2008 23:14:00 GMT

After reading Ilias' post about Intellisense lacking for driver projects, I first thought about running upstairs and throwing a few more quarters at him. Then I thought about making a snarky response in his blog post. But in the end, I just decided to show him up;

That looks a lot like Intellisense to me no? And he just accused me of photoshopping these....sheesh ;)

Forgive the borders, I am just in a very goofy mood today.

Anyways, onward and upward, I promised a post regarding some cross stack communications. Well it turns out my loyal reader was suffering a bit of Patrick-itous. In this case, they were releasing a file handle after initial usage, so there wasn't anything really wrong with the UMDF process code.

But for completion sake a 60 second overview of what was going on - Suppose you wish to communicate with a WDM / KMDF driver in another stack. Simply done in UMDF land; Open a handle to the target (make sure you use the OVERLAPPED flag), then call CreateFileHandleTarget. Don't forget to store the target object returned, and don't close the file handle...especially you Anil *g*. After that it's simply a matter of determining how and what you want to send to that driver. Provided the driver recognizes the IOCTL you're sending, you're all set for communication with a driver outside the current stack.

Keep in mind that all requests submitted from the UMDF driver will fall under IRP_MJ_DEVICE_CONTROL.

Should somebody decide to email me and say they would like to see some sample code, I will churn some up for general consumption. Suffice it to say, what comes after this point isn't much different than what I posted in the OnDeviceIoControl section here. Save you don't really need to make the call to GetDefaultTarget. And if you aren't touching the request at all on pass through you can forgo the infrastructure and just follow the SubmitAsyncRequestToLower code here.

*Currently playing - Peter Gabriel, Digging in the Dirt