Are you aware that some NON-Cached read/write operations from MM at the
end of files do not have their length rounded to a full sector boundary?
If IRP_NOCACHE is set for a read/write operation you should adjust the
length parameter up to the next sector boundary using the size defined
in the device object (devobj->SectorSize) when you allocate your memory
and construct your MDL. I would not change the length parameter in the
IRP.
If you are not doing this, it could be causing the problem you are
seeing. If you look in the FAT source you can see where it does this.
The reason this works fine when you don’t swap buffers is because MM
knows the cache manager always has a buffer that goes up to a page
boundary.
My guess as to why this problem started showing up on this new machine
is because of differences in how the disk driver works. For example if
the machines it works on are IDE devices which happen to use programmed
IO (due to old hardware), you would not see this failure. If the new
machine uses DMA in the disk driver (which it sounds like it does) then
you would probably see this overflow failure.
Neal Christiansen
Microsoft File System Filter Group
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@des.co.uk
Sent: Wednesday, November 26, 2003 2:12 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] RE: IRQL_NOT_LESS_OR_EQUAL in hal.dll after replacing
buffer in write
Yeah, that’s what I thought too. I am using pool tagging but none of
the
tagged memory allocations (from -verifier command) seem to have the tag
I
use for “write encryption buffer” and be close, or even near this
address.
Ben
-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: 26 November 2003 09:59
To: Windows File Systems Devs Interest List
Subject: [ntfsd] RE: IRQL_NOT_LESS_OR_EQUAL in hal.dll after
replacingbuffer
in write
If you’re running Driver Verifier this is most probably memory
overrun -
the
address ending with 000 notes that next page was accessed.
So… don’t look for that address, but anything in the previous
page,
or a few
pages behind that (being that you do encryption filter, 64KB before this
address
would probably be your allocated memory.)
Are you using pool tagging?
- Here is the -analyze -v, the memory address being accessed doesn`t
appear
to have been allocated by me, but I am pretty sure that it was as it
is
only
on an encrypted file that this happens.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com