(1)
I am using Walter Oney's power.cpp file (Second edition) created with driver
wizard. I get an error in Vista when IoVerification enabled in verifier. Did
anyone see the same problem? Any suggestions? I am using the code with minor
changes to convert it to c file. I checked service packs but found no change
in code from Second edition.

(2) I am thinking of having IoAcquireRemoveLock only in PowerDispatch and
not in PowerEvent function to avoid this issue. I didnot understand if we
need RemoveLocks in PowerEvent function as well if we are using Windows 2k or
above only. Power handling so complex I am trying to avoid errors than
modifying code.

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.
Parameter 1 = 0x1000 .. 0x1020 - deadlock verifier error codes.
Typically the code is 0x1001 (deadlock detected) and you can
issue a '!deadlock' KD command to get more information.
Arguments:
Arg1: 00000000000000d5, IoReleaseRemoveLock tag doesn't match previous
IoAcquireRemoveLock tag.
Arg2: fffffa8002c746f8, Address of the chk build Remove Lock structure.
Arg3: fffff98024c80d80, 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


1: kd> kb
RetAddr : Args to Child
: Call Site
fffff800`0200837d : 00000000`000000c4 00000000`000000d5 fffffa80`02c746f8
fffff980`24c80d80 : nt!KeBugCheckEx
fffff800`02009bbd : fffff980`000007cd 00000000`000000a4 00000001`00000001
fffff980`24c80f28 : nt!VerifierBugCheckIfAppropriate+0x3d
fffff800`01cbbdf2 : fffff980`24c80d80 00000001`00000002 00000000`00000001
fffffa80`02c74570 : nt!VfRemLockReportBadReleaseTag+0x1d
fffff980`149b4ab2 : fffff980`24c80d80 00000000`00000002 fffffa80`02c74570
fffffa80`05d53f40 : nt! ?? ::FNODOBFM::`string'+0x139b7
fffff800`01c0ec32 : fffffa80`02c74570 fffff980`24c80d80 fffffa80`02c74570
fffffa80`05d53f40 : DriverXp!DispatchPower+0x1b2 [power.c @ 207]
fffff800`020244d2 : fffff980`24c80d80 fffffa80`02c74570 fffffa80`051e55c0
fffffa80`03d9eab8 : nt!IopPoHandleIrp+0x32
fffff800`02021452 : fffff980`24c80f28 00000000`00000000 fffffa80`040b0220
fffffa80`05d53f40 : nt!IovCallDriver+0x332
fffff800`01c0dcda : 00000000`00000001 00000000`00000000 fffffa80`051e5470
fffffa80`03d9ea00 : nt!ViFilterDispatchPower+0x62
fffff800`01ee196b : ffffffff`fa0a1f00 fffffa80`02c6f580 00000000`00000080
646e6f43`79746901 : nt!PopIrpWorker+0x3ca
fffff800`01c34656 : fffff800`01d4a980 fffffa80`02c6f580 fffff800`01d4fc80
fffff800`01d7b740 : nt!PspSystemThreadStartup+0x5b
00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000
00000000`00000000 : nt!KxStartSystemThread+0x16

Raj wrote:
All I can think of is that verifier is insisting that the tag in a
release call has to match the tag in the most recent acquire call. That
was never part of the spec. Neither was it ever part of the spec that
you couldn't use the same tag in more than one call -- which may be
happening with my power code because the same IRP gets touched multiple
times.

Be careful deleting remove-lock calls. The lock taken in the dispatch
routine is released in the finite-state-machine, if memory serves.

--
Walter Oney, Consulting and Training
http://www.oneysoft.com

the io verifier code for the remlock assumes neither. it will track
multiple acquires of the same tag and a deep history, you do not need to
release in lifo order. if the verifier complained about a tag being release
that was not in the list, you either double released it or never acquired
it.

the io verifier code behaves exactly the same way as a chk kernel does wrt
to tag release validation

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Walter Oney" <waltoney@oneysoft.com> wrote in message
news:47BDC687.8783A38B@oneysoft.com...

Thank you very much for taking time to answer this.

I read that in vista this new bug check was implemented for check
build drivers. In XP, only check build OS has this check enabled. So I
thought the code was not tested for this specific check. I just want
to know if I can ignore this error message or something more bad is
going on. As of now, I am thinking of leaving this code untouched, as
much as possible.

It will be nice if there is a way to tell verifier to ignore this
bugcheck for this file only.

P.S: Walter's book is of great help to me to understand device driver
concepts. I like the precision and clarity in writing. I appreciate
the bug list and service packs maintained in the website. I was
surprised to see a soft copy too. Cannot believe we get so many
services for just buying a book

you cannot ignore this error, it is a bug in your (or walter's code) and you
are going to end up with an incorrect io rem lock count which will hang
remove device processing.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<r_konjeti@yahoo.com> wrote in message
news:f46b39a8-b5d5-4f15-b249-dbd35a58364e@q70g2000hsb.googlegroups.com...

Thanks Doran.

My PNP code is not exactly same as Walter's code even though power Irp
handling code is almost same. May be there is a bug in my code. I will
work on this.