[Carlbyte]

When I try to cancel an IRP with only 1 stack and without completion routine, works normally. But if this IRP has more than 1 stack and completion routine, applications that generate this irp are hanging.

if (stackcount = 1) {
Irp->IoStatus.Status = STATUS_ACCESS_DENIED; //OR STATUS_INSUFFICIENT_RESOURCE
Irp->IoStatus.Information = 0 ;
IoCompleteRequest (Irp, IO_NO_INCREMENT) ;
return STATUS_ACCESS_DENIED;
}
else{??? }


What happens in this case? any tips?

Thank you!

[Vrtule]

Hello,

what you are attempting to do, is not, technically speaking, IRP cancellation. You are just completing the IRP. Is your driver a filter driver (meaning is it attached in a device stack and watching for certain IRPs)? Or how did you get your hands on that IRP?

If you wish to cancel an IRP, call IoCancelIrp. However, the IRP must be cancellable (it has to have a cancel routine defined). If you wish to complete the IRP, the IRP must be targetted to your driver somehow (e.g. you receive it via one of yours device objects).

So, it would be probably best if you showed us a bit more of your code.

Vrtule

[Carlbyte]

I have a driver that is hooking the TCPIP dispatchs. The intention is to deny IRP_MJ_CREATE in some cases. It works perfectly, but if I install a minifilter that in the Preop is returning only FLT_PREOP_SUCCESS_NO_CALLBACK, the processes that generate this IRP_MJ_CREATE are hanging.
...
The symptoms appear to be a kewaitforsingleobject waiting for an event that is not returned. I think IoCompleteRequest ought to perform the completionroutines and release such conditions, but it is not happening.
...
thanks for the answer

[Vrtule]

Hello,

as far as I know, you cannot install a file system minifilter over tcpip.sys devices. To monitor/block/filter requests directed at tcpip.sys, create a device object (IoCreateDevice) and attach it over the target tcpip.sys device. Then, your driver should receive requests targetted at that device, so you can do with them whatever you wish.

The FLT_PREOP_SUCCESS_NO_CALLBACK value should be returned only from a minifilter pre-operation callback, never from any DRIVER_DISPATCH driver-defined callback, such as that responsible for servicing IRP_MJ_CREATE. This value is not of NTSTATUS type.

From the perspective of IRP_MJ_CREATE blocking, there should be no dependence on the number of devices in the device stack. So, you are probably doing something wrong somewhere. That's why I asked you to post more of your code.

Vrtule

[Carlbyte]

The file minifilter that I'm installing, has no connection with the other driver to hook the tcpip.

The strange thing is that when calling ZwCreateFile to the creation of tdi Address_File, this call
pass through the minifilter in preop.

In the preop minifilter has just "return FLT_PREOP_SUCCESS_NO_CALLBACK". This (test) is to prevent error.

[Carlbyte]

In the preop minifilter has just "return FLT_PREOP_SUCCESS_NO_CALLBACK".
...
In the driver that hook tcpip, dispath IRP_MJ_CREATE:

Irp->IoStatus.Status = STATUS_ACCESS_DENIED; //OR STATUS_INSUFFICIENT_RESOURCE
Irp->IoStatus.Information = 0 ;
IoCompleteRequest (Irp, IO_NO_INCREMENT) ;
return STATUS_ACCESS_DENIED;
...
If I uninstall the minifilter, the driver that hooks tcpip works fine

[Carlbyte]

In fact, I was not sure if IoCompleteRequest was enough to complete the IRP. This confused me and now checked other possibilities and solved the problem.
...
Anyway, thanks for the answer

[Vrtule]

In fact, I was not sure if IoCompleteRequest was enough to complete the IRP. This confused me and now checked other possibilities and solved the problem.

It is enough.