How often should we check the IRQL? what is the best practice?

NTDEV
21

or just don’t use those format specifiers.

22

This is whats confusing me, why would a filter driver raise the IRQL but before reverting it, calls another driver

Simply because it may submit an IRP in context of a DPC…

For example, consider the following scenario. Say, you are in the middle of the stack, and the driver at the bottom of the stack completes a request at DISPATCH_LEVEL. This will result in invocation of all completion routines registered by the drivers. Therefore, all these calls will be made at DISPATCH_LEVEL.

Now consider what happens if some driver above yours on the stack decides to submit a new IRP in context of a completion routine, so that this IRP traverses down the stack, eventually reaching your driver. This is just one possible scenario when you may potentially receive an IRP at elevated IRQL

how does it stop other drivers such as upper filter drivers from calling my dispatch routine after raising IRQL?

As long as all the requests to your driver have to pass through some framework, this framework can simply queue a workitem. As a result, the request will be actually sent to your driver in context of a system thread, no matter in which context it was submitted…

Anton Bassov

23

@“Peter_Viscarola_(OSR)” said:
WDF. PASSIVE_LEVEL Execution Constraint. Problem solved.

@Tim_Roberts said:
The point is, you establish a contract that your dispatch routines are called as PASSIVE_LEVEL. If some moron filter driver send you an IRP at DISPATCH_LEVEL, then the BSOD is their fault. You could defend against it, but is it really worth the trouble? Any cooperative filter driver is going to comply.

So if i use WDF with PASSIVE_LEVEL Execution Constraint, will it cause my major functions to all execute at PASSIVE_LEVEL? or is it just for switching the blame for the BSOD to the faulting filter driver?

24

will it cause my major functions to all execute at PASSIVE_LEVEL

Yes. Well, no. Well… huh?? What do you mean by “major functions” – that’s not a WDM or WDF term, as far as I know?

If you mean I/O Event Processing Callbacks for Requests (such as Read, Write, and DeviceControl)? Then, yes. It will entirely avoid your EvtIoRead, EvtIoWrite, or EvtIoDeviceControl ever being called at an IRQL other than IRQL PASSIVE_LEVEL. So, you’ll be 100% good to go.

Peter