verifier STOP: C4

NTDEV
1

I have a wdm lower disk class filter driver. On some Win7 machines I’m getting C4 when verifier is enabled.

I looked in MSDN and found that it is related to REMOVE LOCK. I have few questions:

Q1. I developed this driver based upon classpnp/disk.sys driver which does not call IoAcquireRemove/ReleaseLock. Then why verifier is complaining for my driver?

Q2. I do have a private mechanim to make sure all the IOs related to my driver is completed before my device object is removed. Is it not enough?

Q4. If using these routines required then is src\general\toaster\wdm\filter\filter.c a correct
sample to look at?

Thank you.

2

Forgot to add, it is: C4 (0xD5) which as per msdn [http://msdn.microsoft.com/en-us/library/ff560187(v=VS.85).aspx] is due to "The current IoReleaseRemoveLock tag does not match the previous IoAcquireRemoveLock tag. " . I’m not calling any of these routines. Looks like driver verifier is calling these functions by itself. Any help how this can be handled? Thank you.

3

Send the output of !analyze -v

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Sunday, August 14, 2011 7:50 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] verifier STOP: C4

Forgot to add, it is: C4 (0xD5) which as per msdn [http://msdn.microsoft.com/en-us/library/ff560187(v=VS.85).aspx] is due to "The current IoReleaseRemoveLock tag does not match the previous IoAcquireRemoveLock tag. " . I’m not calling any of these routines. Looks like driver verifier is calling these functions by itself. Any help how this can be handled? Thank you.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

Unfortunately, the machine on which it happens does not have any type of debug port and no dump file is created as it happens very early in the boot. Only information I have is the BSOD screen’s parameters:

STOP: 0xC4 (0xD5, memory addesss 1, memory address 2, 0x0)

5

Have you tried booting into SAFE MODE, setup for a full kernel dump, restarting the target, allowing it to crash then boot back to SAFE MODE to acquire the DMP file? Oh wait. VERIFIER is throwing the BSOD. Then turn off VERIFIER while you configure things and then turn it back on to continue testing. You need to connect WinDbg and do some active debug. Using a VM is one possible means of providing active debug support, given you can duplicate the crash in a VM.

Since this, inconveniently, happens on a machine where WinDbg is not available have you tried it on a machine where WinDbg IS available and does it show the same symptom?

Gary G. Little

----- Original Message -----
From: “cool 2k7”
To: “Windows System Software Devs Interest List”
Sent: Monday, August 15, 2011 3:12:47 AM
Subject: RE:[ntdev] verifier STOP: C4

Unfortunately, the machine on which it happens does not have any type of debug port and no dump file is created as it happens very early in the boot. Only information I have is the BSOD screen’s parameters:

STOP: 0xC4 (0xD5, memory addesss 1, memory address 2, 0x0)

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

ok so I got a pci card with firewire ports on it and was able to connect the debugger. crash points to iastor.sys but it happens only when my drivers are present. so I must be doing something wrong.

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 00000000000000d5, IoReleaseRemoveLock tag doesn’t match previous IoAcquireRemoveLock tag.
Arg2: fffffa80178213e0, Address of the chk build Remove Lock structure.
Arg3: fffffa8017954070, Tag that doesn’t match previous IoAcquireRemoveLock tag.
If the driver calling IoReleaseRemoveLock is not built chk,
Parameter 2 is the chk build Remove Lock used by the Driver Verifier
on behalf of the driver. In this case, the address of the RemoveLock
used by the driver is not used at all, because the Driver Verifier is
replacing the lock address for all the Remove Lock APIs.
Arg4: 0000000000000000

Debugging Details:

BUGCHECK_STR: 0xc4_d5

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff80002b80682 to fffff80002a81660

STACK_TEXT:
fffff880031e7868 fffff80002b80682 : 00000000000000d5 fffffa80035c3b60 0000000000000065 fffff80002ac7b14 : nt!DbgBreakPointWithStatus
fffff880031e7870 fffff80002b8146e : fffffa8000000003 0000000000000000 fffff80002ac46e0 00000000000000c4 : nt!KiBugCheckDebugBreak+0x12
fffff880031e78d0 fffff80002a89704 : 0000000000000001 fffff880031e8008 0000000000000000 fffffa8000000000 : nt!KeBugCheck2+0x71e
fffff880031e7fa0 fffff80002f133dc : 00000000000000c4 00000000000000d5 fffffa80178213e0 fffffa8017954070 : nt!KeBugCheckEx+0x104
fffff880031e7fe0 fffff80002f14ded : fffffa80178d4000 fffffa80178d41e8 0000000000000001 fffff880031e8048 : nt!VerifierBugCheckIfAppropriate+0x3c
fffff880031e8020 fffff80002b0be3f : fffffa80178213d0 fffff80002f23423 fffffa80178d41e8 0000000000000002 : nt!VfRemLockReportBadReleaseTag+0x1d
fffff880031e8060 fffff88001120db3 : 0000000000000000 00000000c0000010 fffffa801793f8e0 0000000000000000 : nt! ?? ::FNODOBFM::string'+0x4ac6d fffff880031e80d0 fffff80002f2fc16 : fffff980029acca0 0000000000000002 fffffa80178d1df0 0000000000000000 : iaStor+0x2ddb3 fffff880031e8110 fffff88001af331a : fffff980029acca0 0000000000000002 fffffa80178d1df0 fffffa8017954600 : nt!IovCallDriver+0x566 fffff880031e8170 fffff88001af3441 : fffffa80178d1df0 fffff980029acca0 fffff980029ace90 fffffa8004382580 : myPortFltr!MyPortFltrSendToNextDriver+0x3a [c:\myPortFltr\myPortFltr.c @ 1702] fffff880031e81b0 fffff80002f2fc16 : fffffa80178d1df0 fffff980029acca0 fffff980029acca0 fffff80002f2b37e : myPortFltr!MyPortFltrClose+0x51 [c:\myPortFltr\myPortFltr.c @ 1755] fffff880031e81e0 fffff80002f2ec42 : fffff980029ace48 0000000000000002 fffffa801793d8b0 fffffa8004382580 : nt!IovCallDriver+0x566 fffff880031e8240 fffff80002f2fc16 : fffff980029acca0 0000000000000002 fffffa801793d760 0000000000000000 : nt!ViFilterDispatchPower+0x62 fffff880031e8270 fffff88001a70f1a : fffff980029acca0 0000000000000002 fffffa801793d510 fffffa80179543f0 : nt!IovCallDriver+0x566 fffff880031e82d0 fffff88001ae8b7e : fffffa801793d510 fffff980029acca0 fffff980029aced8 fffffa8017955f40 : myDiskFltr!MyDiskFltrSendToNextDriver+0x3a [c:\myDiskFltr\myDiskFltr.c @ 3691] fffff880031e8310 fffff80002f2fc16 : fffffa801793d510 fffff980029acca0 fffff980029acca0 fffff80002f2b37e : myDiskFltr!MyDiskFltrClose+0x6e [c:\myDiskFltr\myDiskFltr.c @ 3797] fffff880031e8340 fffff80002f2ec42 : fffff980029ace90 0000000000000002 fffffa801793d2f0 fffffa8017955f40 : nt!IovCallDriver+0x566 fffff880031e83a0 fffff80002f2fc16 : fffff980029acca0 0000000000000002 fffffa801793d1a0 fffffa801793fa90 : nt!ViFilterDispatchPower+0x62 fffff880031e83d0 fffff88001b85cae : fffff98002914fe0 fffffa801793f8e0 0000000000000000 fffffa8017955010 : nt!IovCallDriver+0x566 fffff880031e8430 fffff88001b85dc0 : fffffa8017941be0 fffffa801793f8e0 0000000000000000 fffffa8017954180 : CLASSPNP!ClasspCreateClose+0x17e fffff880031e84b0 fffff80002f2fc16 : fffff980029acca0 0000000000000002 fffffa801793f790 fffff80002f2b37e : CLASSPNP!ClassCreateClose+0x40 fffff880031e84e0 fffff80002f2ec42 : fffff980029acf20 0000000000000002 fffffa801793f680 fffffa8017954180 : nt!IovCallDriver+0x566 fffff880031e8540 fffff80002f2fc16 : fffff980029acca0 0000000000000002 fffffa801793f530 fffff80002f2b3f5 : nt!ViFilterDispatchPower+0x62 fffff880031e8570 fffff88000ecee17 : 0000000000000000 0000000000000002 fffffa801793f1d0 fffffa8017954250 : nt!IovCallDriver+0x566 fffff880031e85d0 fffff80002f2fc16 : fffff980029acca0 0000000000000002 fffffa801793f080 fffff80002f2b37e : partmgr!PmPassThrough+0x67 fffff880031e8610 fffff80002f2ec42 : fffff980029acf68 0000000000000002 fffffa8017941d30 fffffa8003553450 : nt!IovCallDriver+0x566 fffff880031e8670 fffff80002f2fc16 : fffff980029acca0 0000000000000002 fffffa8017941be0 0000000000001000 : nt!ViFilterDispatchPower+0x62 fffff880031e86a0 fffff80002da072e : fffffa8017954070 0000000000000001 fffff980029acca0 fffffa8016ff06a0 : nt!IovCallDriver+0x566 fffff880031e8700 fffff80002a8e7b4 : fffffa8000000000 0000000000000001 fffffa80035c9360 fffff98002956fb0 : nt!IopDeleteFile+0x11e fffff880031e8790 fffff88000c071ea : 0000000000000001 0000000000000000 fffffa8017956000 fffffa8041746e4d : nt!ObfDereferenceObject+0xd4 fffff880031e87f0 fffff88000c0de76 : fffff9800261cf60 0000000000000000 fffff880031e8c80 fffffa8017941be0 : mountmgr!QueryDeviceSortOrder+0x426 fffff880031e8940 fffff88000c0f1f9 : fffff8a0001f2304 0000000000000000 fffff880031e8bd8 0000000000000000 : mountmgr!MountMgrMountedDeviceArrival+0x2ee fffff880031e8af0 fffff80002cf562c : fffff8a0001f2710 0000000000000000 0000000000000000 fffff80002c03e80 : mountmgr!MountMgrMountedDeviceNotification+0x75 fffff880031e8b20 fffff80002ec8988 : fffff8a0001f2710 fffff880031e8bd8 fffff8a0002386b0 00000000ffffffff : nt!PnpNotifyDriverCallback+0x5c fffff880031e8bb0 fffff80002def722 : fffff80002c2e500 fffffa8000000000 fffffa80035c3b00 0000000000000000 : nt!PnpNotifyDeviceClassChange+0x188 fffff880031e8c50 fffff80002a96861 : fffff80002cf5e80 fffff8a000238640 fffff80002c2e5f8 0000000000000000 : nt! ?? ::NNGAKEGL::string’+0x592d1
fffff880031e8cb0 fffff80002d2ea86 : 0000000000000000 fffffa80035c3b60 0000000000000080 fffffa80035065f0 : nt!ExpWorkerThread+0x111
fffff880031e8d40 fffff80002a67b06 : fffff880009f1180 fffffa80035c3b60 fffff880009fbf40 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff880031e8d80 0000000000000000 : fffff880031e9000 fffff880031e3000 fffff880031e7b80 0000000000000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
iaStor+2ddb3
fffff880`01120db3 33db xor ebx,ebx

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: iaStor+2ddb3

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: iaStor

IMAGE_NAME: iaStor.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ac65b7a

FAILURE_BUCKET_ID: X64_0xc4_d5_VRF_iaStor+2ddb3

BUCKET_ID: X64_0xc4_d5_VRF_iaStor+2ddb3

Followup: MachineOwner

And my drivers’ *SendToNextDriver is :

NTSTATUS *SendToNextDriver (IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp)
{
PDEVICE_EXTENSION deviceExtension;

IoSkipCurrentIrpStackLocation (Irp);
deviceExtension = (PDEVICE_EXTENSION)DeviceObject->DeviceExtension;

return (IoCallDriver (deviceExtension->TargetDeviceObject, Irp));

}

7

Are you processing an IRP_MJ_CLOSE request, and passing it on to IASTOR?? That seems odd.

In any case, it LOOKS like you’re doing something in your port filter that’s causing IASTOR a problem.

Perhaps you’re issuing a request that IASTOR doesn’t expect? Sending it to the PDO when it expects getting it in the FDO?

That’s all a guess, of course,

Peter
OSR

8

Thank you for looking at it.

For the MJ_CLOSE, I’m just passing it to the iastor.sys with no special processing at all as shown in my SendToNextDriver.

As per MSDN “Many device and intermediate drivers merely set STATUS_SUCCESS in the I/O status block of the IRP and complete the close request”, are you suggesting that MJ_CLOSE should not be forwarded to the lower driver? But classpnp did and so does other samples (toaster) in wdk ?

REF: http://msdn.microsoft.com/en-us/library/ff550720(VS.85).aspx

One thing I cannot understand is: in all the filters’ samples MJ_CREATE is not forwarded to the lower driver while MJ_CLOSE is. why?

9

http://msdn.microsoft.com/en-us/library/ff550720(v=VS.85).aspx

Above link says “In general, a driver should undo whatever actions it takes on receipt of the IRP_MJ_CREATE request.” So either I should forward both CREATE and CLOSE or none to the lower driver. And this is what my driver is doing but I see samples in wdk don’t (diskperf, toaster\wdm\filter) - they complete CREATE while forward CLOSE to lower driver.

I see that when I do complete both CREATE and CLOSE and not forward them to the lower driver - verifier is happy.

10

More importantly, Mr. Kaur… Not only is VERIFIER happy, IASTOR is happy… which is what really matters at the end of the day.

Are you filtering on the PDO or FDO instance? If you’re filtering the FDO instance, you’ll definitely want to pass Create and Close through.

Peter
OSR

11

It is also possible that this is a bug in iastor that is only exposed by
your filter driver. What happens if you do not forward IRP_MJ_CLOSE
requests? The quoted text says absolutely nothing about filter drivers,
which are neither ‘device’ not ‘intermediate’, and if you are implementing a
port filter driver you are in undocumented territory.

Another question: why are you verifying iastor anyway?

Mark Roddy

On Mon, Aug 15, 2011 at 3:35 PM, wrote:

> Thank you for looking at it.
>
> For the MJ_CLOSE, I’m just passing it to the iastor.sys with no special
> processing at all as shown in my SendToNextDriver.
>
> As per MSDN “Many device and intermediate drivers merely set STATUS_SUCCESS
> in the I/O status block of the IRP and complete the close request”, are you
> suggesting that MJ_CLOSE should not be forwarded to the lower driver? But
> classpnp did and so does other samples (toaster) in wdk ?
>
> REF: http://msdn.microsoft.com/en-us/library/ff550720(VS.85).aspx
>
> One thing I cannot understand is: in all the filters’ samples MJ_CREATE is
> not forwarded to the lower driver while MJ_CLOSE is. why?
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

12

[PV] Are you filtering on the PDO or FDO instance? If you’re filtering the FDO
instance, you’ll definitely want to pass Create and Close through.

[NK] Can you please explain me (or point me to some link) why do it differently for FDO vs PDO? I’m filtering both. I put counters for create and close - and I see that my create counter = 0 while close counter = 1 when this BSOD happens for the disk PDO. Probably because of the reason you are trying to point out.

[MR] Another question: why are you verifying iastor anyway?

[NK] I’m running velocity with verifier ON which automatically enables verifier on all the drivers.

13

> For the MJ_CLOSE, I’m just passing it to the iastor.sys with no special processing at all as shown in my

Are you properly setting the file object in the stack location when passing the request to IaStor?

Will IaStor crash alone without your driver, but with Verifier?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

14

[MSS]. Are you properly setting the file object in the stack location when passing the
request to IaStor?

[NK] this is what I’m doing in when I receive MJ_CREATE/CLOSE for FDO/PDO.

NTSTATUS *SendToNextDriver (IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp)
{
PDEVICE_EXTENSION deviceExtension;

IoSkipCurrentIrpStackLocation (Irp);
deviceExtension = (PDEVICE_EXTENSION)DeviceObject->DeviceExtension;

return (IoCallDriver (deviceExtension->TargetDeviceObject, Irp));

}

[MSS] Will IaStor crash alone without your driver, but with Verifier?

[NK] No and that’s what made me believe that there is some problem with my driver.

15

[PV] If you’re filtering the FDO instance, you’ll definitely want to pass Create and Close through.

I thought hard about it but still could not come with an explanation. I do not feel comfortable putting some code in driver which I do not understand.

Mr. Peter or anybody else, can you please explain me why for FDO CREATE/CLOSE need to be passed to the lower driver and for PDO not?

Also I’m not able to understand why verifier does not complain for the same request when my port filter is not present. iastor must be getting the same request (CLOSE) without my driver too.

I also tried with an older and the latest version of iastor and I do not see the BSOD any more with/without the change (not to pass create/close for PDOs) as Mr Peter suggested.

Thank you.

16

Sorry, Mr. Kaur… very busy here. I apologize for not answering your question earlier.

Create/Close is, as you’ve seen, a “funny” beast. In Windows, generally, create/close are not propagated down the stack from FDO to PDO. OTOH, if you write an UPPER filter driver, you certainly WANT to propagate create that you get on your filter device instance, because you’re ABOVE the function driver’s FDO.

The issue, then, is simply that many bus drivers EXPECT to see create/close on their functional instance (the FDO), but expect the create/close to be “consumed” by the Function Driver that gets instantiated on their PDOs.

When it comes to IASTOR, your guess is – quite literally – as good as mine when it comes to what IASTOR expects. It’s written by some good engineers (I can say that for certain). They test it well. But when a filter driver gets tossed into the mix, if the filter driver changes the flow of I/O requests even a litte… well, that’s an untested scenario. You hope the code is written defensively enough, but… lower filters of disk class aren’t exactly common.

I applaud you for not wanting to just throw some code into your driver that you don’t understand. Bravo for you! OTOH, sometimes you just HAVE to swallow hard and accept a “work around” when that makes your driver work when somebody else’s code is actually to blame.

Again, my apologies for not being able to answer earlier. I’m going back to writing code now (Saturday night)…

Peter
OSR

17

Thank you Mr. Peter for explaining in detail.