IoCallDriver to NDIS IM

[Deneb]

Hello guys,

a TDI driver calls IoGetDeviceObjectPointer(
[name],
FILE_ALL_ACCESS,
&( gOTIMDumpModule.IMComm.pIMFileObject ),
&( gOTIMDumpModule.IMComm.pIMDevObject )
);
to get a pointer to a device object exported by a NDIS IM driver, much like passthru. This call succeeds.

struct
{
struct
{
PDEVICE_OBJECT pIMDevObject;
PFILE_OBJECT pIMFileObject;
}
IMComm;
}
gOTIMDumpModule;

Then the TDI driver wants to comunicate with the NDIS driver by calling IoBuildDeviceIoControlRequest with FALSE at the 3-rd last arg ( to build an IRP_MJ_DEVICE_CONTROL ). Then calls IoCallDriver.

The IoCallDriver returns STATUS_UNSUCCESSFULL.

Issuing the same calls, but the IoBuildDeviceIoControlRequest called with TRUE ( to set IRP_MJ_INTERNAL_DEVICE_CONTROL ), IoCallDriver succeeds and the NDIS IM is called through the device driver handler. Can anyone tell me what is the problem?
I really need to call the NDIS IM driver with IRP_MJ_DEVICE_CONTROL. Please tell me if it is possible.

Thank you

[Vadim Smirnov]

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…}

[Deneb]

Hello ,

Thanks for the reply. The IM driver does not fail the request ( the IM driver is developed by me also ), and the main problem is the driver cannot be modified since it was certified and the binary cannot be modified anymore ( request from the outside world ). Perhaps the IM layer fails the request ( it was created with NdisMRegisterDevice ).
When the IM driver will be available for modification there will be more elegant solution … :)…

[Vadim Smirnov]

I would trace through the IRP processing to figure out the exact reason to fail the IRP. May be there is a workaround for this.

[Author]

Posts