Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Default dispatch routines

AvalonAvalon Member Posts: 28
edited December 2019 in NTDEV

Hello. There are 2 default dispatch routines I've come across, either complete the IRP via IoCompleteRequest() and go back up the device stack, or ignore the IRP and call the lower driver via IoCallDriver().

I currently iterate over IRP_MJ_MAXIMUM_FUNCTION, in the classic for loop, and assign all IRP_MJ_XX to DefaultDispatchHandler(), and do:

    Irp->IoStatus.Information = 0; 
    Irp->IoStatus.Status = STATUS_NOT_SUPPORTED; 
    IoCompleteRequest(Irp, IO_NO_INCREMENT); 

Microsoft samples, some return STATUS_INVALID_DEVICE_REQUEST (but that's the default return with a NULL handler by the I/O manager), I've seen some return STATUS_SUCCESS. And I've read the Walter Oney book on the IRP section, and it says the default handler should use IoCallDriver() in the default dispatch routine, but it's around the filter driver section so I assume it's just relating to them, of which I'm not. As I'm the only device driver in this PNP stack (mydriver=FDO, ACPI=PDO), there's no point me in ever checking if someone is below me right and always completing. And what does the I/O manager do in response to seeing STATUS_NOT_SUPPORTED, or what should I use.

  !DevObj           !DrvObj            !DevExt           ObjectName

ffff940be529d6b0 \Driver\mydriver ffff940be529d800

  ffff940be98f2e10  \Driver\ACPI       ffff940be6ea5560  00000083
!DevNode ffff940be55485a0 :
  DeviceInst is "ACPI\aaaaaaaa\0&bbbbbbb&0"
  ServiceName is "cccccccc"
Post edited by Avalon on


  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,627

    Is there a question here?

    You can't arbitrarily return STATUS_NOT_SUPPORTED for all IRPs. In particular, IRP_MJ_PNP, IRP_MJ_POWER and IRP_MJ_SYSTEM_CONTROL have very strict rules that must be followed. Those IRPs must be passed down the driver stack in a very specific way. Not doing so will result in BSOD. In your case, the ACPI driver is the lowest-level driver. IT will complete the PnP and power in the proper way.

    And, to sing the familiar refrain, you really ought to be using KMDF anyway.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE