Window IO

Provide consistent I/O abstraction to applications.

Provide a framework to do the following.◦ Dynamic loading/unloading of drivers.

◦ Support for power management so that the system or individual devices can enter low power states.

◦ Driver layering.

◦ Asynchronous I/O.

◦ Uniform enforcement of security.

All I/O requests to drivers are sent as I/O request packets (IRPs).

I/O operations are layered

The I/O manager defines a set of standard routines, some required and others optional, that drivers can support

With each user-mode request for I/O, the I/O Manager allocates an IRP from nonpaged system memory. Based on the file handle and I/O function requested by the user, the I/O Manager passes the IRP to the appropriate driver dispatch routine.

The dispatch routine checks the parameters of the request, and if valid, passes the IRP to the driver's Start I/O routine.

The Start I/O routine uses the contents of the IRP to begin a device operation.

When the operation is complete, the driver's DpcForIsrroutine stores a final status code in the IRP and returns it to the I/O Manager.

The I/O Manager uses the information in the IRP to complete the request and send the user the final status

Major function

IRP_MJ_CLOSE,IRP_MJ_CREATE,IRP_MJ_DEVICE_CONTROL,IRP_MJ_INTERNAL_DEVICE_CONTROL,IRP_MJ_PNP,IRP_MJ_POWER,IRP_MJ_READ..

Minor Function

IRP_MN_START_DEVICE,IRP_MN_QUERY_ID,IRP_MN_EJECT....

IO priority

User plugs a new device into a Bus

The Bus driver

◦ Notices the new device’s arrival

◦ Enumerates the device

◦ Retrieves identification information for the device

◦ Passes information to Plug and Play

driver must implement a Plug and Play dispatch routine, a power management dispatch routine

Need to handle both add and removal of device

devnode is made up of at least two, and sometimes more, device objects[PDO and FDO]

A physical device object (PDO) that the PnP manager instructs a bus driver to create when the bus driver reports the presence of a device on its bus during enumeration A functional device object (FDO) that is created by the driver, which is called a function driver, that the PnP manager loads to manage a detected device.

user plugin device ->bus driver enumerates device ->bus driver notifies ->pnp obtains information via IRP_MN_QUERY_DEVICE_RELATIONS=>The function driver for the bus device handles the IRP.

PnP manager creates devnodes ->PnP manager gathers information via IRP

_MN_QUERY_ID ->store them in registry

PnP manager coordinates with the user-mode PnP manager and user-mode Setup PnP manager ->user-mode Setup components direct the kernel-mode PnP manager to load the function and filter drivers.

Require hardware that complies with the Advanced Configuration and Power Interface (ACPI) specification

Power Management split into:

S-states, representing the entire system

S0: Working state, S1 – S3: Sleeping states

S4: Hibernated state, S5: Soft-off state

D-states, representing single devices

D0: Working state, D1 – D2: Low power states, D3: Off state

This can vary based on architecture and device manufacturer and corresponding drivers

Devices can be in any Dx state while the machine itself is in the S0 state

S0-D0: Device is powered on and fully active

S0-D(1-3): Device is in a low power state, but the machine is still running. The user may not even be aware that the device is not in D0

Devices in D(1-3) may be armed for wakeup, even though the machine is awake

Machine appears to be off

RAM context is maintained

All clocks are stopped, except for RTC

Devices may or may not have power

Some devices may have trickle current, but not main power source

Power in S1 >= S2 >= S3

Differences between S1, S2 and S3 are machine specific

RAM context is written to disk

Machine is powered off

All devices are in the D3 state, unless they have external power sources

Machine execution resumes through NTLDR, which restores RAM context

BIOS has a chance to reprogram devices

S5 State: All context is lost

Machine is powered off

Resume from S5 == booting

Hybrid sleepa user request to put the computer to sleep will actually be a combination of both the S3 state and the S4 state: while the computer is put to sleep, an emergency hibernation file will also be written to disk

Connected standby:

<<to be filled>>

The WDM Power Manager sends S IRPs:

IRP_MN_QUERY_POWER, IRP_MN_SET_POWER

Each device stack has a “Power Policy Owner” who converts S IRPs to D IRPs

The Power Policy Owner is typically the FDO

The mapping comes from the S D array stored in the IRP_MN_QUERY_CAPABILITIES structure

Each entry calls out the lightest possible D state for a given S state

Mappings can be rounded down (deeper)

The Power Policy Owner then uses PoRequestPowerIrp to request the appropriate D IRP

Windbg Command:

!thread – to get the test status of thread and corresponding irp detail

!drvobj,!devobj –to det driver and device object detail

!irpfind – displays information about all I/O request packets (IRP) currently allocated in the target system

!irp <addres of irp> - to get etails of particular irp.

Enable Verifier option for IRP Logging to trace irp

All Question are welcomed

Thank You