Debug tips and tricks for HID Miniport Drivers?

NTDEV
1

I am writing a HID Miniport Driver (WDM driver model), and am having a problem during the driver load sequence.
My past experience has been that the HID Class Driver very promptly tells your driver to unload (sends you a DispatchPnP with IRP_MN_REMOVE_DEVICE) as soon as you do any IoCompleteRequest() with contents that it does not like for any reason.

This is currently happening to me when I respond to the IOCTL_HID_GET_DEVICE_ATTRIBUTES, but I cannot figure out what it is unhappy about [my Irp->IoStatus.Information == sizeof(HID_DEVICE_ATTRIBUTES) == 32 and my Irp->IoStatus.Status == STATUS_SUCCESS == 0].

Anyone on the list have any Best Known Methods to figure-out what the HID Class Driver doesn’t like? Can I use kd to single-step into the HID Class code and have a prayer of figuring out what that assembly-code is doing?

2

Following OSR’s traditions, I’d recommend you to implement the driver using WDF.

As for debugging, are you sure that HID class driver actually sends MN_REMOVE? It’s more likely that it calls IoInvalidateDeviceState which causes PnP manager to send MN_SURPRISE_REMOVAL. Though I remember that some of HID drivers sends START_DEVICE to stack by itself.

Anyway, I’d check it by putting a bp on IoInvalidateDeviceState and, if triggered, analyzed which condition leads to the branch. If the bp not triggered it worth to go over the driver’s IoCTL handler in a disassembler. Usually IoCTL handler has a big switch (CtlCode) construction. IOCTL_HID_GET_DEVICE_ATTRIBUTES’s function code is 9. So, you need to locate and examine switch (CtlCode) case 9.