Hi,
I came across an old posting (http://www.osronline.com/showThread.cfm?link=67087) which suggests that having multiple instances of the same driver may result in a false DRIVER_VERIFIER_DETECTED_VIOLATION (c4) bugcheck with arg1:Arg1: 00000054.
I have encountered te same bugcheck with two instances of my driver loaded. The memory block listed in the bugcheck seems to be valid, ending with four intact guard bytes.
The osr article quoted in the posting above (http://www.osronline.com/lists_archive/ntfsd/thread1122.html) is no longer available, so I was wondering if anyone can confirm if this is still an issue?
Thanks in advance,
–Basil.
What means two instances? two services loading same .sys binary?
–PA
xxxxx@symantec.com wrote:
Hi,
I came across an old posting (http://www.osronline.com/showThread.cfm?link=67087) which suggests that having multiple instances of the same driver may result in a false DRIVER_VERIFIER_DETECTED_VIOLATION (c4) bugcheck with arg1:Arg1: 00000054.
I have encountered te same bugcheck with two instances of my driver loaded. The memory block listed in the bugcheck seems to be valid, ending with four intact guard bytes.
The osr article quoted in the posting above (http://www.osronline.com/lists_archive/ntfsd/thread1122.html) is no longer available, so I was wondering if anyone can confirm if this is still an issue?
Thanks in advance,
–Basil.
> What means two instances? two services loading same .sys binary?
Very dangerous thing. If the second DriverEntry will fail - then MM will unmap the whole image and BSOD will soon occur on the first driver instance.
The thing is that in this case there is only 1 entry in MM’s loaded module list (and one module mapping), which is shared by 2 driver objects.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
xxxxx@symantec.com wrote:
I came across an old posting (http://www.osronline.com/showThread.cfm?link=67087) which suggests that having multiple instances of the same driver may result in a false DRIVER_VERIFIER_DETECTED_VIOLATION (c4) bugcheck with arg1:Arg1: 00000054.
I have encountered te same bugcheck with two instances of my driver loaded. The memory block listed in the bugcheck seems to be valid, ending with four intact guard bytes.
The post you quoted refers to a very special circumstance, in which two
DIFFERENT copies of a single driver were loaded in memory at the same
time, each handling one instance. It was not referring to the extremely
common circumstance of having multiple devices served by one driver.
It’s not easy to get into that first situation, so I doubt that’s what
you are seeing.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thank you all for the replies.
Tim, my driver is not related to any hardware, the case where two instances are loaded simultaneously is caused by installing two products that carry different versions of the same driver (.sys file), but register them under different service names. Having the two products installed at the same time is possible but does not happen frequently.
So is the false verifier bugcheck a known issue in this case?
Note to self: guy from Symantec is loading his kernel driver multiple times into the system… hmm…
xxxxx@symantec.com wrote:
Thank you all for the replies.
Tim, my driver is not related to any hardware, the case where two instances are loaded simultaneously is caused by installing two products that carry different versions of the same driver (.sys file), but register them under different service names. Having the two products installed at the same time is possible but does not happen frequently.
So is the false verifier bugcheck a known issue in this case?
I’m not sure I would go that far. The original post reports what seems
to be a problem, but I never saw any followup nor any resolution,
positive or negative. The only way to get a definitive answer, unless
one of the kernel team here happens to know, is to open a support incident.
Before I did so, I’d be darned sure to check the dump for evidence that
it REALLY wasn’t my own problem…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Will look into it some more, but for now i’ll modify the test harness to use a different driver name.
thanks,
–Basil.
I tried to post a reply to this thread earlier today. I don’t see my reply now on the web interface, so I am trying again (sorry if you will receive two replies):
When the pool block was allocated, Verifier Pool Tracking stored some information that was consistent with the information from the block’s pool header. At the time of the ExFreePool call, Verifier detected that the Pool Tracking information and the block header information were inconsistent. A common cause for that kind of inconsistency is a pool buffer overrun. Less often, the pool block header was corrupted. The header lives right behind the address that the driver received back from ExAllocatePool, if this was not a Special Pool block. If this was a Special Pool block, the header lives at the very beginning of the memory page were the pool block lives.
I am very interested to understand this issue. I don’t expect that it was related to loading multiple copies of a driver, but I guess it is possible that I am missing something.
Basil, if you are willing to show me a memory.dmp from this kind of break, please send email to verifier @ microsoft.com, or directly to my microsoft.com email address (dmihai). Then I will setup a channel to receive the dump file from you.
Thanks,
Dan
Just in case some of you guys might hit similar problems in the future:
It turns out that Verifier was indeed confused by the loading in parallel of two different verified drivers that shared the same image file name.
On OS versions older than Vista, Verifier wiped out the Pool Tracking information about driver1, when driver2 (using the same file name) got loaded. Later, when driver1 tried to free one of its pool allocations, Verifier panicked because it didn?t find the corresponding Pool Tracking information, and issued the bugcheck described above. Also, the description of the bugcheck 0xC4, subcode 0x54 was confusing in this case.
I believe that on Vista and newer OS versions, this problem is less severe. It will not result in spurious bugchecks. However, it can still result in spurious assertions failed on checked builds, when one of driver1 or driver2 gets unloaded, or loaded again. Also, it can result in displaying of incorrect Verifier counters about these drivers (e.g. the number of outstanding pool allocations, number of outstanding pool bytes allocated, etc.).
I am following up on all of these issues. Meanwhile, the workaround is to rename one of the driver image file names ? e.g. use foo.sys and bar.sys, rather than two different copies of foo.sys loaded from two different directories.
Basil, thanks for all the help with this!
Dan
Thank you Dan, for taking the time to research this.
Regards,
–Basil.