IRP_MJ_WRITE paging IO not caught in some cases RRS feed

  • Question

  • Hello, I am writing a legacy OTF encryption FSD (I am not doing it in a minifilter as an exercise to improve my understanding of windows internals). I encrypt/decrypt data only of all the paging IO I catch so that the cache will remain clear but data on the disk will be encrypted.

    I know this topic has been extensively discussed here and on other places and I have dug through the archives (which is how I could get to where I am) but something still eludes me.

    When I create a new file smaller than 736 bytes and save it, I catch two Irp out of which only one paging IO, and everything works fine. However, when I create a new file bigger than that, I only catch one Irp which is not a paging IO - therefore I don't encrypt anything and the file ends up being clear on the disk.

    I have run FileSpy to see if I was missing something, and indeed, I was. There is actually a second Irp (paging IO) in the second case, but I just happen not to catch it in my driver. Does anyone have an idea about what is causing this ?


    • Edited by MatthieuM Tuesday, August 13, 2013 1:45 PM
    Tuesday, August 13, 2013 12:20 PM

All replies

  • I actually see the paging IO, but with a different file name : \$ConvertToNonresident. I'm checking the IrpSp->FileObject->FileName to get the file name. 

    FileSpy seems to be able to tell that this Irp is refering to the real name file. I can see that both Irp file objects have the same context. 

    How can I get the file name from the Irp without using IrpSp->FileObject->FileName ?

    PS: second Irp is sent only because I do a CcFlushCache after the first Irp.


    • Edited by MatthieuM Tuesday, August 13, 2013 1:49 PM
    Tuesday, August 13, 2013 1:48 PM
  • Your efforts here are beyond learning windows internals, it is a wasting more time than getting benefit. Nearly everyone who deals with FS issues is now correctly just dealing with fs filter manager, it is the sane route to go for all fs activities.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, August 13, 2013 2:26 PM