Hi,
I am writing a filter driver that hooks IRP_MJ_WRITEs.
My filter dirver works above the FSD and en/decrypt the data.
In processing IRP_MJ_WRITE, I get a pointer to the written data
by using MmGetSystemAddressForMdl().
After that, I allocate my own IRPs for data encryption and send
my own IRPs to the FSD below and call IoCompleteRequest() without
sending the original IRP to the FSD below.
This process seems good, but a memory leak happens.
My filter driver causes BSOD in the end because of a shortage of
PTE(Page Table Entries)
This problem happens only when my filter diver processes the
Paging I/O for the NTFS below.
This problem doesn’t happen when the FSD below is FAT or Rdr.
Does anyone have any idea why the memory leak happens?
Any help is greately appreciated.
Thanks in advance.
Takashi.
If the memory described by an MDL was not mapped into system virtual
memory address space, then MmGetSystemAddressForMdl() does so (notice
that the macro may call MmMapLockedPages). This consumes system PTEs.
You should arrange to unmap the memory when you are done using the
virtual address. See MmUnmapLockedPages().
Dave Cox
Hewlett-Packard Co.
NSSO/SANS/SMSO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox
-----Original Message-----
From: xxxxx@itg.hitachi.co.jp [mailto:xxxxx@itg.hitachi.co.jp]
Sent: Wednesday, November 29, 2000 9:45 PM
To: File Systems Developers
Subject: [ntfsd] Memory Leak(Shortage of PTE)
Hi,
I am writing a filter driver that hooks IRP_MJ_WRITEs.
My filter dirver works above the FSD and en/decrypt the data.
In processing IRP_MJ_WRITE, I get a pointer to the written data
by using MmGetSystemAddressForMdl().
After that, I allocate my own IRPs for data encryption and send
my own IRPs to the FSD below and call IoCompleteRequest() without
sending the original IRP to the FSD below.
This process seems good, but a memory leak happens.
My filter driver causes BSOD in the end because of a shortage of
PTE(Page Table Entries)
This problem happens only when my filter diver processes the
Paging I/O for the NTFS below.
This problem doesn’t happen when the FSD below is FAT or Rdr.
Does anyone have any idea why the memory leak happens?
Any help is greately appreciated.
Thanks in advance.
Takashi.
You are currently subscribed to ntfsd as: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Hi,
It look like you don’t free Mdl for IPRs you created and sent to file
system. File system
can create Mdl for UserBuffer you sent, in this case you are responsible to
free it. I think for FAT
you will have the same problem if you will try to do a lot of asynchronous
IO.
Regards,
Alexei.
From: xxxxx@itg.hitachi.co.jp
To: File Systems Developers
> Subject: [ntfsd] Memory Leak(Shortage of PTE)
> Date: Wednesday, November 29, 2000 10:45 PM
>
> Hi,
>
> I am writing a filter driver that hooks IRP_MJ_WRITEs.
> My filter dirver works above the FSD and en/decrypt the data.
> In processing IRP_MJ_WRITE, I get a pointer to the written data
> by using MmGetSystemAddressForMdl().
> After that, I allocate my own IRPs for data encryption and send
> my own IRPs to the FSD below and call IoCompleteRequest() without
> sending the original IRP to the FSD below.
> This process seems good, but a memory leak happens.
> My filter driver causes BSOD in the end because of a shortage of
> PTE(Page Table Entries)
>
> This problem happens only when my filter diver processes the
> Paging I/O for the NTFS below.
> This problem doesn’t happen when the FSD below is FAT or Rdr.
>
> Does anyone have any idea why the memory leak happens?
>
> Any help is greately appreciated.
> Thanks in advance.
>
> Takashi.
>
> —
> You are currently subscribed to ntfsd as: xxxxx@mondenet.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Thanks a lot for all your valuable information.
I wrote a code as follows in my completion routine for that IRP
after I got your hints.
MmGetSystemAddressForMdl()
MmUnmapLockedPages()
IoFreeMdl()
I used the UserBuffer instead of the MDL and
I neglected to free the MDL created by the FSD below.
Your hints enabled me to solve this problem.
Thanks again!!!
Regards,
Takashi.