Why does WinDbg say IRQL 2 for HwProcessServiceRequest ?

NTDEV
1

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?

2

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

Peter

3

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.

Sorry.

4

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

Peter

5

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?