Possible bug in driver verifier, or user error?

Hello,

While running a old-style WDM driver for a PCI device through the HLK, I received a driver verifier IO violation when the machine awoke from S3 sleep during one of the tests. The error is nonsensical to me, so I’m thinking it’s a bug with driver verifier, unless I’m missing something. Although it is a non-fatal error, I’m currently blocked from passing the HLK because of the error. If it is indeed a bug, how can I report it to Microsoft? Is the sysdev DL an appropriate place?

Here is the top of the output from !analyze -v:

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 0000000000000301, A driver has forwarded an IRP at IRQL > DISPATCH_LEVEL.
Arg2: xxxx, The address in the driver’s code where the error was detected.
Arg3: xxxx, IRP address.
Arg4: 0000000000000002, Incorrect IRQL value.

The IRQL is already at DISPATCH_LEVEL (2) and not above that, so I’m not sure why I’m getting this error. I verified that the code path does not lower or raise the IRQL either. Just in case below is the relevant part of the stack:

00 nt!ViErrorFinishReport+0x8e
01 nt!ViGenericVerifyIrpStackDownward+0x114
02 nt!VfMajorVerifyIrpStackDownward+0xb4
03 nt!IovpCallDriver1+0x476
04 nt!VfBeforeCallDriver+0x130
05 nt!IovCallDriver+0x221
06 nt!IofCallDriver+0x14c9cf
07 nt!ViFilterDispatchPnp+0x1a2
08 nt!IovCallDriver+0x245
09 VerifierExt!IofCallDriver_internal_wrapper+0x19
0a nt!VerifierIofCallDriver+0x21
0b mydriver!PciRegisterRead_UseOS+0xf3
0c mydriver!PciFindCapability+0x2d
0d mydriver!Power_CompleteDevicePowerUp+0x30
0e nt!IovpLocalCompletionRoutine+0x175
0f nt!IopfCompleteRequest+0x117
10 nt!IovCompleteRequest+0x1c0
11 nt!IofCompleteRequest+0x144a73
12 pci!PciPowerUpDeviceTimerDpc+0xf6

The function mydriver!PciRegisterRead_UseOS is the last function from the driver on the stack, and it’s responsible for creating the IRP and forwarding it down to the next lower device.

I should be clear: this driver has been around for a long time with minimal changes (I didn’t write it either), so I’d be surprised if the problem was with the driver itself.

Let me know if you need any more information.

xxxxx@gmail.com wrote:

While running a old-style WDM driver for a PCI device through the HLK, I received a driver verifier IO violation when the machine awoke from S3 sleep during one of the tests. The error is nonsensical to me, so I’m thinking it’s a bug with driver verifier, unless I’m missing something. Although it is a non-fatal error, I’m currently blocked from passing the HLK because of the error. If it is indeed a bug, how can I report it to Microsoft? Is the sysdev DL an appropriate place?
…
The IRQL is already at DISPATCH_LEVEL (2) and not above that, so I’m not sure why I’m getting this error. I verified that the code path does not lower or raise the IRQL either. Just in case below is the relevant part of the stack:
…
0b mydriver!PciRegisterRead_UseOS+0xf3

Given the name of the function, can I assume you are calling
IRP_MN_READ_CONFIG? That IRP requires IRQL < DiSPATCH_LEVEL. There are
instructions on the doc page for IRP_MN_READ_CONFIG that describe how to
use the BUS_INTERFACE_STANDARD interface from the PCI driver. Its
GetBusData call can be called at DISPATCH_LEVEL.

I should be clear: this driver has been around for a long time with minimal changes (I didn’t write it either), so I’d be surprised if the problem was with the driver itself.

Ah, foolish mortal…

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Looks like you are correct, Tim. I shouldn’t have trusted the developer

That said, the driver verifier violation error is misleading at best, and I probably should’ve focused less on that and instead on getting to know the surrounding code.

Thanks!