DRIVER_VERIFIER_DETECTED_VIOLATION

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

How many bytes more than usual are You allocating? Since You corrupt 70 bytes,
anything less than this would be useless.
Can You get the stack at the error time?

Regards, Dejan.

xxxxx@allstor-sw.co.uk wrote:

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: xxxxx@ptt.yu
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


Regards, Dejan M. CEO Alfa Co. www.register.co.yu and www.alfaunits.co.yu
E-mail : xxxxx@ptt.yu, xxxxx@register.co.yu and xxxxx@alfaunits.co.yu
ICQ# : 56570367
Professional file&system related components and libraries for Win32 developers.
Alfa Units - #1 file and system handling units for Delphi.
Alfa File Monitor - #1 file monitoring system for Win32 developers.
Alfa File Protector - #1 file protection and hiding system for Win32 developers.


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

Thanks,

I was under the impression that Parameter 4 was the number of
bytes requested by the driver.

For example, if I request 288 (0x120) bytes (which is exactly
the correct amount) then the bug check
(DRIVER_VERIFIER_DETECTED_VIOLATION) has the following parameters:
p1 = 52, p2 = AC325EE0, p3 = E, p4 = 120

If I request 688 (0x2b0) bytes (400 extra) then the bug check
parameters are:
p1 = 52, p2 = B630dd50, p3 = E, p4 = 2B0

As for the stack, I’m using SoftIce, so know exactly where the
bug check occurs. I’m calling ExFreePool(), and from this the
stack below is:

ntoskrnl!_KeBugCheckEx+0001
ntoskrnl!_VerifierFreeTrackedPool+00B1
ntoskrnl!_MmFreeSpecialPool+0211
ntoskrnl!_ExFreePoolWithTag+0022
ntoskrnl!_VerifierFreePoolWithTag+001F
ntoskrnl!_VerifierFreePool+0020
mgrpfs!_pfs_free+0208 <---- from where we call ExFreePool()

I’ve also tried changing from verify end to verify start (gflags)
(just in case I’m getting an under-run) this has had no effect on
what bug check occurs, or its location!

I’m still rather confused as to what is going on here!
Thanks
Hazel

How many bytes more than usual are You allocating?
Since You corrupt 70 bytes, anything less than this
would be useless.
Can You get the stack at the error time?

Regards, Dejan.


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

Turn off pool tracking. Your failure should appear …

Whats happening here is that the pool tracking data which is next to
your allocation got nailed. This serves as a slop between your
allocation and the guard page, and is “saving” you since it takes the
corruption.

Those folks who’ve heard me talk about the verifier at IFS events may
recall this warning :slight_smile: The moral of the story is that turning on all
of the verifier elements at once is not neccesarily going to help all
the time.

-----Original Message-----
From: xxxxx@allstor-sw.co.uk [mailto:xxxxx@allstor-sw.co.uk]
Sent: Wednesday, March 28, 2001 2:35 AM
To: File Systems Developers
Subject: [ntfsd] Re: DRIVER_VERIFIER_DETECTED_VIOLATION

Thanks,

I was under the impression that Parameter 4 was the number of
bytes requested by the driver.

For example, if I request 288 (0x120) bytes (which is exactly
the correct amount) then the bug check
(DRIVER_VERIFIER_DETECTED_VIOLATION) has the following parameters:
p1 = 52, p2 = AC325EE0, p3 = E, p4 = 120

If I request 688 (0x2b0) bytes (400 extra) then the bug check
parameters are:
p1 = 52, p2 = B630dd50, p3 = E, p4 = 2B0

As for the stack, I’m using SoftIce, so know exactly where the
bug check occurs. I’m calling ExFreePool(), and from this the
stack below is:

ntoskrnl!_KeBugCheckEx+0001
ntoskrnl!_VerifierFreeTrackedPool+00B1
ntoskrnl!_MmFreeSpecialPool+0211
ntoskrnl!_ExFreePoolWithTag+0022
ntoskrnl!_VerifierFreePoolWithTag+001F
ntoskrnl!_VerifierFreePool+0020
mgrpfs!_pfs_free+0208 <---- from where we call ExFreePool()

I’ve also tried changing from verify end to verify start (gflags)
(just in case I’m getting an under-run) this has had no effect on
what bug check occurs, or its location!

I’m still rather confused as to what is going on here!
Thanks
Hazel

How many bytes more than usual are You allocating?
Since You corrupt 70 bytes, anything less than this
would be useless.
Can You get the stack at the error time?

Regards, Dejan.


You are currently subscribed to ntfsd as: xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


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

You seem to be in a very “nice” position - i.e. one easily
traceable. Try what D. suggested (turning off Pool Tracking). If it
doesn’t help, You probably know where You allocated the original pool
(since You know where You free it), and where it’s used. Most of the
time, the overruns happen in memcpy, memset, strcpy functions, because
all other memory writes or reads are 1-4 bytes.

Regards, Dejan.

xxxxx@allstor-sw.co.uk wrote:

Thanks,

I was under the impression that Parameter 4 was the number of
bytes requested by the driver.

For example, if I request 288 (0x120) bytes (which is exactly
the correct amount) then the bug check
(DRIVER_VERIFIER_DETECTED_VIOLATION) has the following parameters:
p1 = 52, p2 = AC325EE0, p3 = E, p4 = 120

If I request 688 (0x2b0) bytes (400 extra) then the bug check
parameters are:
p1 = 52, p2 = B630dd50, p3 = E, p4 = 2B0

As for the stack, I’m using SoftIce, so know exactly where the
bug check occurs. I’m calling ExFreePool(), and from this the
stack below is:

ntoskrnl!_KeBugCheckEx+0001
ntoskrnl!_VerifierFreeTrackedPool+00B1
ntoskrnl!_MmFreeSpecialPool+0211
ntoskrnl!_ExFreePoolWithTag+0022
ntoskrnl!_VerifierFreePoolWithTag+001F
ntoskrnl!_VerifierFreePool+0020
mgrpfs!_pfs_free+0208 <---- from where we call ExFreePool()

I’ve also tried changing from verify end to verify start (gflags)
(just in case I’m getting an under-run) this has had no effect on
what bug check occurs, or its location!

I’m still rather confused as to what is going on here!
Thanks
Hazel

> How many bytes more than usual are You allocating?
> Since You corrupt 70 bytes, anything less than this
> would be useless.
> Can You get the stack at the error time?
>
> Regards, Dejan.


You are currently subscribed to ntfsd as: xxxxx@ptt.yu
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


Regards, Dejan M. CEO Alfa Co. www.register.co.yu and
www.alfaunits.co.yu
E-mail : xxxxx@ptt.yu, xxxxx@register.co.yu and
xxxxx@alfaunits.co.yu
ICQ# : 56570367
Professional file&system related components and libraries for Win32
developers.
Alfa Units - #1 file and system handling units for Delphi.
Alfa File Monitor - #1 file monitoring system for Win32 developers.
Alfa File Protector - #1 file protection and hiding system for Win32
developers.


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

Thanks for everyone’s help.

It appears that there wasn’t an issue with overwriting at all!
(Turning off pool tracking didn’t show up the error - though useful to
know!)

It appears that there was a problem with how the driver was being started.
I was running two copies of the driver - which was resulting in this
problem
when freeing memory while unloading the driver.

So, thanks again for everyone’s help!

Hazel


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