Default dispatch routines

NTDEV
1

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); 
    return STATUS_NOT_SUPPORTED;

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"
2

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.