Windows File System filter driver development tutorial (10)

Windows File System filter driver development tutorial

Note: If you have any questions and suggestions, please add qq16191935, email MFC_Tan_Wen@163.com

I have been busy with work for a long time. Please forgive me.

10 send an IRP Read Request by yourself

This document is explained in detail, but I think the exampleCodeThis document is a little too simple. Please search for it yourself in the OSR document attached to IFS.

Why do I need to send IRP by myself? In a file filter driver, if you want to read and write files, you can try zwreadfile. But there are some problems. ZW native APIs

Handle. The handle has restrictions on the thread environment. There are also restrictions on the interruption level. In addition, ZW functions are used to read and write files, and eventually IRP will be sent and driven by their own filters.

Captured. The results are difficult to judge. It is also a waste of resources. So what is the best solution? Of course, IRP is sent directly to the volume device.

However, IRP is a very complex data structure and is processed by many unopened components constructed by Microsoft. Therefore, it is not a simple task to send IRPs by yourself.

The omnipotent method is ioallocateirp, which is filled in one by one after allocation. The problem is that there are too many details and many documents are not available. If you are interested, take a look at what I mentioned above.

That articleArticle"Rolling your own ".

Interestingly, this article later mentioned shortcuts, that is, using three functions:

Iobuildasynchronousfsdrequest (...)
Iobuildsynchronousfsdrequest (...)
Iobuilddeviceiocontrolrequest (...)

So I referred to his sample code and found that the code runs well,ProgramIt is also very simple. It is recommended that contestants who are afraid of in-depth research can use the methods provided below.

We recommend that you use iobuildasynchronousfsdrequest () instead of the synchronized one. Asynchronous IRP is used to make IRP irrelevant to the thread. And your filter driver 1

It is difficult to grasp the current thread (if you open a system thread to specifically read files ). At this time, you can easily Delete the allocated IRP in the IRP completion function to avoid chasing

Thread-related issues.

However, this method has limitations. This method can only be used for irp_mj_read, irp_mj_write, irp_mj_flush_buffers, and irp_mj_shutdown.

I only want to read the file here.

To use IRP to read files, you need a file_object.fileobject which is better than the handles used by the ZW series. This fileobject is irrelevant to the thread. You can

Safely use it in unknown threads.

To obtain a file_object, you must send irp_mj_create IRP. This is not an easy task. However, I skipped this issue. Because I am a File System

System filter driver, so I get file_object from the IRP sent above, and then construct my own IRP to use this file_object. I found that the operation is good.

However, another problem occurs. If the IRP-> flags in the irp_paging (or the IRP sent by the cache manager) Mark, the fileobject is obtained and

When used, errors are always returned. Reading online experiences shows that fileobject with irp_paginge cannot be used. Therefore, I avoid using fileobject.

Irp_paging IRP (read request sent by the user program.

Well, now there is a lot of nonsense. Now let's look at the code for constructing IRP:

_ Inline wd_ir* wd_irp_fsd_read_alloc (wd_dev * Dev,
Wd_void * Buf,
Wd_ulong length,
Wd_lgint * offset,
Wd_io_stat_block * io_stat)
{
Return iobuildasynchronousfsdrequest (irp_mj_read, Dev,
Buf, length,
Offset,
Io_stat );
}

I don't know how to use io_stat. I generally fill in null. If the type is pio_status_block.buf, the buffer is used. Userbuffer is used in IRP to receive data. Offset is

The offset of this read.

The above function constructs a read IRP. Please note that you have not set fileobject. In fact, I am sending the request as follows:

IRP = wd_irp_fsd_read_alloc (Dev, Buf, Len, & START, null );
If (IRP = NULL)
Return;
Irpsp = wd_irp_next_sp (IRP );
Wd_irpsp_file_set (irpsp, file );
Wd_irp_comp (IRP, my_req_comp, context );

Please note that wd_irp_next_sp, I got the next io_stack_location of this IRP, And then I set fileobject. After the settings are complete, I will

You can send a request! After the request is sent, your my_req_comp will be called once the system completes the request.

Let's take a look at how my_req_comp ends:

Wd_stat my_req_comp (in wd_dev * Dev,
In wd_irp * IRP,
In wd_void * context)
{

// Please note that IRP must be completely destroyed here no matter whether it succeeds or fails.
Wd_irp_send_by_myself_free (IRP );

// This is returned only because the IRP has been destroyed and the system does not want to destroy it again.
Return wd_stat_more_processing;
}

Wd_stat_more_prcessing is status_more_processing_required. This is returned because I have deleted the IRP. I don't want windows

And then what to do to this IRP. So I will continue to process it, which avoids the possibility that I/O manager can use this IRP.

Finally, the Code of the IRP deletion function is as follows:

_ Inline wd_void wd_irp_send_by_myself_free (wd_irp * IRP)
{
If (IRP-> mdladdress)
{
Mmunmaplockedpages (mmgetsystemaddressformdl (IRP-> mdladdress ),
IRP-> mdladdress );
Mmunlockpages (IRP-> mdladdress );
Iofreemdl (IRP-> mdladdress );
}
Iofreeirp (IRP );
};

Because I have not assigned mdladdress. So if MDL is returned below, I have to clean it with it.

Well, I wish you a happy mood. If you are as lazy as you are, use the simple method above to send IRP to read the file.