Windows File System filter driver development tutorial (4)

Windows File System filter driver development tutorial 4. device stack, filtering, file system awareness

The front side is introducing the structure of the file system driver, but we haven't talked about how our filter driver can capture all the IRPs sent to the file system driver and let us handle them by ourselves? The device object has been explained earlier. Now let's explain the device stack.

Any device object exists in a device stack. A device stack is a set of Device objects. These Device objects are correlated. That is to say, if you get a do pointer, you can know where the device stack is.

Any request from an application is eventually translated into IRP by Windows Io Mgr, which is always sent to the device at the top of the device stack.

Original IRP
--------------> ------> -------> ----->
Devtop dev2... devvolumne ...???
<-------------- <------ <------- <-----
Original IRP (return) IRP

The arrow to the right indicates the sending process of the irp request, and returns to the left. It can be seen that IRP is sent gradually from the top of the device stack. Devvolumue indicates the volume device to be filtered, and devtop indicates the top of the device stack. As long as we bind another device to the top of the device stack, the request sent to volume will naturally be sent to our device for processing.

There is a system call that can bind our device to the top of a device stack. This call is ioattachdevicetodevicestack, which can be used by both the 2000 and later systems (so this is because there is another ioattachdevicetodevicestacksafe, which is not available in 2000. This often causes your filter to be unavailable in 2000 .)

I wrote a function to help me implement the binding function:

// ---------------------- Content in WDF. h ----------------------------------
// This routine binds the source device to the device stack of the target device and returns the result directly from the source device.
// Connect to the bound device. Note that the source device may not be directly bound to the target device. It should be bound
// The top of the device stack of the target device.
_ Inline wd_stat wd_dev_attach (in wd_dev * SRC,
In wd_dev * DST,
In out wd_dev ** attached)
{
* Attached = DST;
* Attached = ioattachdevicetodevicestack (SRC, DST );
If (* attached = NULL)
Return wd_stat_no_such_dev;
Return wd_stat_suc;
}

Here, we already know how to filter requests to volume. For example, if the device "C:" is connected with the symbol "C:", it is not difficult to get the device name. After obtaining the device name, it is not difficult to obtain the device. In this case, iocreatedevice () generates a device object and calls wd_dev_attach to bind it. Isn't everything okay? All IRPs sent to "C:" must be sent to our drivers first. We can also capture all operations on the file!

This is indeed a simple solution. I got Filemon'sCodeThis is the case. If you do not want to handle dynamic volume, you can do this. But here we have a higher requirement. When you insert a USB flash drive into the USB port, a volume such as "J:" is born dynamically, we still need to capture this event and generate a device to bind it.

The process of generating a volume in a file system is called mounting. at the beginning of the process, the CDO of FS will get an IRP. The major function code is irp_mj_file_system_control, and the minor function code is irp_mn_mount. In other words, if we have generated a device bound to the file system's CDO, then we can get this IRP where we know that a new volume is being mounted. in this case, we can perform the operations mentioned above.

The question now is how to know which file systems are in the system, and when should I bind their control devices.

Ioregisterfsregistrationchange () is a very useful system call. This call registers a callback function. When any file system is activated or deregistered, the registered callback function is called.

// ---------------------- Content in WDF. h ----------------------------------
Wd_stat wdff_reg_notify (
In wd_drv * driver,
In wdff_policy_func func
)
{
Return ioregisterfsregistrationchange (driver, func );
}

You need to write a callback function for this purpose.

// ------------------- My callback handler function ----------------------------------
Wd_void my_fs_notify (
In wd_dev * Dev,
In wd_bool active)
{
Wd_wchar name_buf [wd_dev_name_max_len];
Wd_ustr name;
Wd_ustr_init_em (& name, name_buf, wd_dev_name_max_len );

// If registered, you should be notified.
Wd_printf0 ("Policy: A file SYS have been acitved !!! \ R \ n ");

// Obtain the name of the file system object and print it out.
Wd_obj_get_name (Dev, & name );
Wd_printf0 ("policy: file SYS name = % WZ \ r \ n", & name );

If (active)
{
Wd_printf0 ("Running Y: Try to attach. \ r \ n ");
//... Please bind the control device of the file system here
}
Else
{
Wd_printf0 ("Running Y: unactive. \ r \ n ");
//...
}
}

How should I bind a file system CDO? We will describe in detail in the following chapter.

Now we should add the content of the upper and lower sides in the wd_main function:

If (wdff_reg_notify (driver, my_fs_notify )! = Wd_stat_suc)
{
Wd_printf0 ("error: Reg failed y failed. \ r \ n ");
Wd_fio_disp_release (driver );
Wd_dev_del (g_cdo );
G_cdo = wd_null;
Return wd_stat_insufficient_res;
};

Wd_printf0 ("success: Reg 127y OK. \ n ");

Let's review what we should do in wd_main.

A. Generate a control device. You must specify a name for the control settings.

B. Set dispatch functions.

C. set fast Io functions.

D. Compile a my_fs_notify callback function to bind the activated fs cdo.

E. Use wdff_reg_notify to call the registration callback function.