Is device created with NdisMRegisterDevice? Well, it is difficult to say who exactly fails your IRP (NDIS, IM driver itself or filter driver attached to the IM created device), but you can check it yourself in kernel mode debugger. Probably one of these components checks the IRP origination (user or kernel) and if kernel mode component issues IRP_MJ_DEVICE_CONTROL then it fails. Basically as DDK documentation says kernel mode component usually issues IRP_MJ_INTERNAL_DEVICE_CONTROL:
IRP_MJ_DEVICE_CONTROL
A driver receives this I/O control code because user-mode thread has called the Microsoft® Win32® DeviceIoControl function, or a higher-level kernel-mode driver has set up the request.
IRP_MJ_INTERNAL_DEVICE_CONTROL
This I/O control code has been defined for communication between paired and layered kernel-mode drivers, such as one or more class drivers layered over a port driver. The higher-level driver sets up IRPs with device- or driver-specific I/O control codes, requesting support from the next-lower driver.
I suppose it is far easier to change NDIS IM driver to process IRP_MJ_INTERNAL_DEVICE_CONTROL along with IRP_MJ_DEVICE_CONTROL.
case IRP_MJ_DEVICE_CONTROL:
case IRP_MJ_INTERNAL_DEVICE_CONTROL:
{… PUT YOUR I/O PROCESSING CODE HERE…}