How does the deviceiocontrol Application Layer communicate with the driver layer?

Deviceiocontrol of one of the called Methods

The driver layer provides device names such as filedisk in the driver layer.

First, register the list.

Use winobj to view the drive object of filedisk

But how do we generate these eight objects?

We interrupt viewing process when loading filedisk. sys Driver detailed double-click debugging view my another article http://www.cnblogs.com/UnMovedMover/p/3690369.html

In the downloaded source code filedisk, add interrupt _ asm int 3 to DriverEntry, The filedisk-17 \ filedisk-17 \ sys \ SRC filedisk. c Under sys;

Query_table [0]. entrycontext = & n_devices;
Call the rtlqueryregistryvalues Function
Status = rtlqueryregistryvalues (
Rtl_registry_absolute,
Parameter_path.buffer,
& Query_table [0],
Null,
Null
);

N_devices = 4.

Then generate eight devices cyclically

For (n = 0, n_created_devices = 0; n <n_devices; n ++)
{
Status = filediskcreatedevice (driverobject, N, file_device_disk );
If (nt_success (Status ))
{
N_created_devices ++;
}
}
For (n = 0; n <n_devices; n ++)
{
Status = filediskcreatedevice (driverobject, N, file_device_cd_rom );
If (nt_success (Status ))
{
N_created_devices ++;
}
}

After a device object is created in the driver layer, the application layer links the device object with a symbolic link.

Definedosdevice (ddd_raw_target_path ,&Volumename[4],Devicename)

DevicenameFrom

If (cdimage)
{
Sprintf (Devicename, Device_name_prefix "cd" "% u", devicenumber );
}
Else
{
Sprintf (Devicename, Device_name_prefix "% u", devicenumber );
}

Device_name_prefix:

# Define device_base_name _ T ("\ filedisk ")
# Define device_dir_name _ T ("\ device") device_base_name
# Define device_name_prefix device_dir_name device_base_name

Yes

The device handle is created using the createfile Symbolic Link name.

Device= Createfile (
Volumename,
Generic_read | generic_write,
File_pai_read | file_pai_write,
Null,
Open_existing,
File_flag_no_buffering,
Null
);

Finally, pass the device handle to the driver layer through deviceiocontrol.

Deviceiocontrol (
Device, // Hdevice long, device handle
Ioctl_file_disk_open_file, // dwiocontrolcode long, the application calls the control command of the driver, that is, ioctl_xxx IOCTLs.
Openfileinformation, // lpinbuffer any, the data buffer address that the application passes to the driver.
Sizeof (open_file_information) + openfileinformation-> filenamelength-1, // ninbuffersize long, the data buffer size transmitted by the application to the driver, in bytes.
Null, // lpoutbuffer any, the data buffer address that the driver returns to the application.
0, // noutbuffersize long, the size of the data buffer that the driver returns to the application, in bytes.
& Bytesreturned, // lpbytesreturned long, the number of bytes that the driver actually returns to the application.
Null // lpoverlapped overlapped. This structure is used for overlapping operations. For synchronization operations, use byval as long to pass the zero value
))

 

In summary, the driver layer provides the device object. The application layer creates a symbolic link based on the device object, generates a device Handle Based on the symbolic link, and passes it to the driver layer. The two are connected.