Hi,
I’m having a problem with an issue that verifier has found.
I am running verifier with the following settings:
Special Pool
Force IRQL checking
Pool Tracking
I/O verification (level 1)
I have gflags set to “verify end”
The error is:
p1=52 p2=A9725F90 p3=8 p4=70
This is occurring when I am freeing memory.
Looking at the documentation, I would expect that the problem is
that I am writing past the allocated memory. I explored this, and
can find no evidence of this.
We have guard blocks within the code available for memory
allocations. I turned these on, and detected no errors. Verifier
still complained when I freed the memory.
The memory that is being deallocated is part of a group of memory
allocated/deallocated at the same time. In an attempt to understand
the problem better I rearranged the order this memory was freed.
The first allocation freed is still the memory that verifier complains about
(note: this means that verifier is complaining about a different piece of
memory handled in the driver in a different way)
I have also tried allocating deliberately large chunks of memory (twice
what is required) and still verifier complains.
I need to clarify that this problem is only occurring on this particular set
of memory. The problem is not on all memory allocated and freed
by this driver.
Finally, my understanding of verifier would leave me to believe that
I should actually receive an error at the point I overwrite the allocation
rather than when it is freed (though the error code must exist for a reason!)
So, if the driver really is overwriting allocations, why don’t I get a bug check
earlier?
Any help/insight would be gratefully received at this point
Thanks very much in advance
Hazel Curtis
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
The moral of the story is that turning on all