IRP_MJ_WRITE

When I trap the call to see what IRP_MJ_WRITE is doing, I find that there
is two call for a write. However I got nothing when I try to print the
buffer for the first write, while I can get back the data before the
second write (I call a read before the write).

Anybody knows what is happening in a IRP_MJ_WRITE?

FilemonHookRoutine - IRP_MJ_WRITE
FilemonWrite - irql=0, writeLength=5, offset=0, information=0,
CurrentByteOffset.LowPart=0, Irp->Flags=a00, FileObject->Flags=41062,
DeviceObject->Flags=50
FilemonWrite - readIrp->Flags=184, FileObject->Flags=41062,
DeviceObject->Flags=50
FilemonWrite - IoCallDriver - Read data success - ntStatus=0,
Information=5
Data=
FilemonWrite - writeLength=5, offset=0, information=0,
CurrentByteOffset.LowPart=5, Irp->Flags=a00, FileObject->Flags=c1062,
DeviceObject->Flags=50
FilemonWrite - Irp->UserBuffer not null
Data=
FilemonWrite - IoCallDriver - write data success - ntStatus=0,
information=5, CurrentByteOffset.LowPart=5
FilemonHookRoutine - IRP_MJ_WRITE - FileObject=8161fb48,
path=C:\FCrypt\12345.txt found in FList.
FilemonWrite - irql=0, writeLength=4096, offset=0, information=0,
CurrentByteOffset.LowPart=5, Irp->Flags=43, FileObject->Flags=c1062,
DeviceObject->Flags=50
FilemonWrite - readIrp->Flags=184, FileObject->Flags=c1062,
DeviceObject->Flags=50
FilemonWrite - IoCallDriver - Read data success - ntStatus=0,
Information=5
Data=12345
FilemonWrite - writeLength=4096, offset=0, information=0,
CurrentByteOffset.LowPart=5, Irp->Flags=43, FileObject->Flags=c1062,
DeviceObject->Flags=50
FilemonWrite - Irp->MdlAddress not null
Data=
FilemonWrite - IoCallDriver - write data success - ntStatus=0,
information=5, CurrentByteOffset.LowPart=5

---------- Forwarded message ----------

Once again hi all !
The my test application can be observed at next manner:
void main()
{
NTSTATUS Status;
UNICODE_STRING UnicodeFilespec;
OBJECT_ATTRIBUTES ObjectAttributes;
HANDLE FileHandle,ntSectHandle;
IO_STATUS_BLOCK Iosb;
LARGE_INTEGER Granularity = {0};
PTYPE_OBJECT_INFO lpTypeInfo = NULL;
CHAR lpData[0x200] = {0};
ULONG dwLen = 0;
PCHAR lpFileData = NULL;
dwLen = sizeof(lpFileData);
RtlInitUnicodeString(&UnicodeFilespec, L"\??
\d:\query\1.fil");
InitializeObjectAttributes(&ObjectAttributes,
&UnicodeFilespec, OBJ_CASE_INSENSITIVE, NULL,NULL);
Status = NtCreateFile( &FileHandle, FILE_GENERIC_READ|
FILE_GENERIC_WRITE,&ObjectAttributes, &Iosb, NULL,
0, FILE_SHARE_READ|FILE_SHARE_WRITE,
FILE_OPEN_IF, FILE_SYNCHRONOUS_IO_NONALERT
|FILE_NON_DIRECTORY_FILE ,NULL,0);
if(!NT_SUCCESS(Status))
{
printf(“Create system service failed status = 0x%
0x\n”, Status);
exit(0);
}
Status = ZwCreateSection(&ntSectHandle, SECTION_MAP_WRITE |SECTION_MAP_READ, NULL, &Granularity,
PAGE_READWRITE,SEC_COMMIT,FileHandle);
if(!NT_SUCCESS(Status))
{
printf(“Create section failed status = 0x%0x\n”,
Status);
NtClose(FileHandle);
exit(0);
}
Status = ZwMapViewOfSection (ntSectHandle,
NtCurrentProcess(), &lpFileData,0, 0, &Granularity,
&dwLen, ViewShare, 0, PAGE_READWRITE);
if(!NT_SUCCESS(Status))
{
printf(“Mapping file service failed status = 0x%0x\n”,
Status);
NtClose(FileHandle);
NtClose(ntSectHandle);
exit(0);
}
NtClose(FileHandle);
for(dwLen = 0; dwLen < CRYPTHEADFERLEN; dwLen++)
lpFileData[dwLen]= (CHAR)(‘A’+dwLen);
ZwUnmapViewOfSection(NtCurrentProcess(),lpFileData);
// In theory after of this action, NT VMM must the
// generate IRP_MJ_WRITE with IRP_PAGING_IO flag setted.
// to saved FileObject. I’ve not see of this request…
NtClose(ntSectHandle);
exit(1);
}
Do you can say to me, what i can to do for this request observing ? May be, the saved FileObject was already
deleted at this time, and lieu of it NT VMM will create of StreamFileObject for all dirty pages ? As i can find out in this case, what my FileObject is used for PAGING_IO process of write ? Any suggestions may be helpful.
Always grateful to you
Nikityenko Oleg (oleshii).

> Do you can say to me, what i can to do for this request observing ? May be, the saved

The file handle is closed, but the file object is still there. It will be there till MM will flush the dirty pages, which will be a
bit later.

Max