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?

  1. 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