The document discusses the Windows driver model and I/O architecture. It describes how I/O requests from applications are abstracted via IRPs that are passed to drivers. Drivers implement standard routines to handle IRPs for operations like read, write, power management. PnP manages device enumeration and loading of drivers to handle new devices. Power management coordinates transitioning devices and the system between various D-states and S-states.

3.  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.

4.  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

5.  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 DpcForIsr
routine 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

7.  Major function
IRP_MJ_CLOSE,IRP_MJ_CREATE,IRP_MJ_DEVICE_C
ONTROL,IRP_MJ_INTERNAL_DEVICE_CONTROL,I
RP_MJ_PNP,IRP_MJ_POWER,IRP_MJ_READ..
 Minor Function
IRP_MN_START_DEVICE,IRP_MN_QUERY_ID,IRP_
MN_EJECT....

11. IO priority

12. 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

13.  driver must implement a Plug and Play
dispatch routine, a power management
dispatch routine
 Need to handle both add and removal of
device

14.  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.

18.  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.

19.  PnP manager creates devnodes ->PnP manager gathers
information via IRP
 _MN_QUERY_ID ->store them in registry

20.  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.

21.  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

22.  This can vary based on architecture and device manufacturer
and corresponding drivers

23.  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

24.  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

25.  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

26.  Hybrid sleep
a 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>>

27.  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

28.  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

29. All Question are welcomed 
Thank You 