Why does WinDbg say IRQL 2 for HwProcessServiceRequest ?

Based on https://www.osr.com/nt-insider/2010-issue1/writing-virtual-storport-miniport-driver-part-iii/ I thought the call should always be at IRQL 0, but windbg analyize -v always says IRQL 2 when I have a crash in that call, testing even by passing null pointer and trying to access, crash, but says IRQL2 as well? Is this correct or is there something else going on?

if you check the IRQL in your code, while it’s running, (with KeGetCurrentIrql) what does it say?


Well, Assertion failed: KeGetCurrentIrql()<DISPATCH_LEVEL

ISSUE was there was a spinlock in a prior function that called the function that handled the ioctl so it raised the IRQL.


Don’t be sorry. Glad you got back to us to let us know what was going on.

I’m surprised Code Analysis didn’t find that bug (not dropping the lock)…


I started with third party code to speed up part of development (dealing with the srb’s that need answers, etc…) and that had a wrapper that used a lock on startio that could be removed (so it did free it, but after calling the function to handle the ioctl itself).

Hey, on your sample, you have if(irpSp->MajorFunction == IRP_MJ_DEVICE_CONTROL) { in the HwProcessServiceRequest handler, was that really needed?