Structure

Question 1

Driver

Answer 1

Is as a container for a collection of subroutines that the operating system calls to perform various operations that relate to your hardware

Question 2

Routines present in every such container

Answer 2

DriverEntry and AddDevice routines, as well as dispatch functions for a few types of I/O Request Packet (IRP)

Question 3

Drivers that need to queue requests

Answer 3

Might have a StartIo routine

Question 4

Drivers for devices that generate hardware interrupts

Answer 4

Have an interrupt service routine (ISR) and a deferred procedure call (DPC) routine

Question 5

Jobs as the author of a WDM driver

Answer 5

Select the functions that need to be included in your particular container

Question 6

OS Scheduler

Answer 6

The operating system kernel contains a scheduler that gives short blocks of time, called time slices, to all the
threads that are currently eligible to run. An application begins life with a single thread and can create more if it wants. Each thread has a priority, given to it by the system and subject to adjustment up and down for various reasons. At each decision point, the scheduler picks the highest-priority eligible thread and gives it control by loading a set of saved register images,
including an instruction pointer, into the processor registers. A processor interrupt accompanies expiration of the thread’s time slice. As part of handling the interrupt, the system saves the current register images, which can be restored the next time the system decides to redispatch the same thread.

Instead of just waiting for its time slice to expire, a thread can block each time it initiates a time-consuming activity in another thread until the activity finishes. This is better than spinning in a polling loop waiting for completion because it allows other
threads to run sooner than they would if the system had to rely solely on expiration of a time slice to turn its attention to some other thread.

Question 7

Application is

Answer 7

A selfish thread that grabs the CPU and tries to hold on until it exits and that the operating system scheduler acts like a playground monitor to make a bunch of selfish threads play well together

Question 8

A a driver is also an executable file with extension

Answer 8

.SYS

Question 9

Who charge the driver

Answer 9

A driver doesn’t contain a main program. Instead, it contains a collection of subroutines that the
system can call when the system thinks it’s time to. To be sure, these subroutines can use helper subroutines in the driver, in static libraries, and in the operating system, but the driver isn’t in charge of anything except its own hardware: the system is in charge of everything else, including the decisions about when to run your driver code.

Question 10

Thead context

Answer 10

Running in an arbitrary thread context. A driver subroutine executes in the context of whatever thread happens to be currently active at the time the system decides to call that subroutine. It’s not possible to predict which thread will be current at the time a hardware interrupt occurs.

Question 11

Arbitrary thread

Answer 11

All the eligible threads that happens to be executing at the time of hardware interrupt is likewise not predictable

Question 12

The system doesn’t always execute driver code in an arbitrary thread context

Answer 12

A driver can create its own system threads by
calling PsCreateSystemThread. A driver can also ask the system to call it back in the context of a system thread by scheduling a work item. In these situations, we consider the thread context to be nonarbitrary.

Question 13

Thread block in an arbitrary thread

Answer 13

driver shouldn’t block

Question 14

When a driver shouldn’t block

Answer 14

• In an arbitrary thread

* When a driver creates an IRP to send to some other driver

Question 15

IRP in an arbitrary thread

Answer 15

Asynchronous IRP. The I/O Manager doesn’t tie an asynchronous IRP to any particular thread

Question 16

IRP in a nonarbitrary thread

Answer 16

Synchronous IRP. The I/O Manager ties the synchronous kind of IRP to the thread within which you
create the IRP. It will cancel the IRP automatically if that thread terminates.

Question 17

Symmetric Multiprocessing

Answer 17

In this model, each CPU is treated exactly like every other CPU with respect to thread scheduling. Each CPU has its own current thread. It’s perfectly possible for the I/O Manager, executing in the context of the threads running on two or more CPUs, to call subroutines in your driver simultaneously.

Question 18

Function driver

Answer 18

It understands all the details about how to make
the hardware work. It’s responsible for initiating I/O operations, for handling the interrupts that occur when those operations finish, and for providing a way for the end user to exercise any control over the device that might be appropriate.

Question 19

Bus driver

Answer 19

It’s responsible for managing the connection between

the hardware and the computer

Question 20

PDO

Answer 20

physical device object

Question 21

FDO

Answer 21

function device object

Question 22

FiDO

Answer 22

filter device object

Question 23

Plug and Play device

Answer 23

Is one that has an electronic signature that a bus driver can interrogate to learn the identity of a device.

Question 24

Basic Data Structures

Answer 24

the driver object and the device object

Question 25

Driver object

Answer 25

represents the driver itself and contains pointers to all the driver subroutines that the system will ever call on its own motion.

Question 26

Device object

Answer 26

represents an instance of hardware and contains

data to help you manage that instance

Question 27

DeviceObject (PDEVICE_OBJECT)

Answer 27

anchors a list of device object data structures, one for each of the devices managed by the driver. The I/O Manager links the device objects together and maintains this field. The DriverUnload function of a non-WDM driver would use this field to traverse the list of device objects in order to delete them. A WDM driver probably doesn’t have any particular need to use this field.

Question 28

DeviceObject (PDEVICE_OBJECT)

Answer 28

anchors a list of device object data structures, one for each of the devices managed by the driver. The I/O Manager links the device objects together and maintains this field. The DriverUnload function of a non-WDM driver would use this field to traverse the list of device objects in order to delete them. A WDM driver probably doesn’t have any particular need to use this field.

Question 29

DriverExtension (PDRIVER_EXTENSION)

Answer 29

points to a small substructure within which only the AddDevice (PDRIVER_ADD_DEVICE) member is accessible to the likes of us. AddDevice is a pointer to a function within the driver that creates device objects

Question 30

HardwareDatabase (PUNICODE_STRING)

Answer 30

describes a string that names a hardware database registry key for the device. This
is a name like Registry\Machine\Hardware\Description\System and names the registry key within which resource allocation
information resides. WDM drivers have no need to access the information below this key because the PnP Manager performs resource allocation automatically. The name is stored in Unicode

Question 31

FastIoDispatch (PFAST_IO_DISPATCH)

Answer 31

points to a table of function pointers that file system and network drivers export.

Question 32

DriverStartIo (PDRIVER_STARTIO)

Answer 32

points to a function in your driver that processes I/O requests that the I/O Manager has serialized for you.

Question 33

DriverUnload (PDRIVER_UNLOAD)

Answer 33

points to a cleanup function in your driver.

Question 34

MajorFunction (array of PDRIVER_DISPATCH)

Answer 34

is a table of pointers to functions in your driver that handle each of the roughly two dozen types of I/O requests. This table is also something of a big deal, as you might guess, because it defines how I/O requests make it into your code.

Question 35

DriverObject (PDRIVER_OBJECT)

Answer 35

points to the object describing the driver associated with this device object, usually the one that called IoCreateDevice to create it.

Question 36

DriverObject (PDRIVER_OBJECT)

Answer 36

points to the object describing the driver associated with this device object, usually the one that called IoCreateDevice to create it.

Question 37

NextDevice (PDEVICE_OBJECT)

Answer 37

points to the next device object that belongs to the same driver as this one. This field is the
one that links device objects together starting from the driver object’s DeviceObject member. There’s probably no reason for a WDM driver to use this field. That’s just as well because proper use of this pointer requires synchronization using an internal
system lock that’s not exposed for access by device drivers.

Question 38

CurrentIrp (PIRP)

Answer 38

is used by the Microsoft IRP queuing routines StartPacket and StartNextPacket to record the IRP most
recently sent to your StartIo routine. WDM drivers should implement their own IRP queues (see Chapter 5) and may have no use for this field.

Question 39

Flags (ULONG)

Answer 39

contains a collection of flag bits

Question 40

Characteristics (ULONG)

Answer 40

is another collection of flag bits describing various optional characteristics of the device. The I/O Manager initializes these flags based on an argument to IoCreateDevice. Filter drivers propagate some of them upward in the device stack

Question 41

DeviceExtension (PVOID)

Answer 41

points to a data structure you define that will hold per-instance information about the device. The I/O Manager allocates space for the structure, but its name and contents are entirely up to you. A common convention is to declare a structure with the type name DEVICE_EXTENSION. To access it given a pointer (for example, fdo) to the device object, use a statement like this one:

Question 42

DeviceType (DEVICE_TYPE)

Answer 42

is an enumeration constant describing what type of device this is. The I/O Manager initializes
this member based on an argument to IoCreateDevice. Filter drivers might conceivably need to inspect it

Question 43

StackSize (CCHAR)

Answer 43

counts the number of device objects starting from this one and descending all the way to the PDO. The
purpose of this field is to inform interested parties regarding how many stack locations should be created for an IRP that will be sent first to this device’s driver. WDM drivers don’t normally need to modify this value, however, because the support routine they use for building the device stack (IoAttachDeviceToDeviceStack) does so automatically.

Question 44

AlignmentRequirement (ULONG)

Answer 44

specifies the required alignment for data buffers used in read or write requests to this device.

Question 45

DriverEntry Routine

Answer 45

Do the global initialization that the driver

needs to perform only once when it’s loaded for the first time

Question 46

NTSTATUS

Answer 46

Always return NTSTATUS

Question 47

DriverEntry Routine first argument

Answer 47

The first argument to DriverEntry is a pointer to a barely initialized driver object that represents your driver. A WDM driver’s DriverEntry function will finish initializing this object and return.

Question 48

DriverEntry Routine second argument

Answer 48

is the name of the service key in the registry. This string is not persistent—you must copy it if you plan to use it later. In a WDM driver, the only use I’ve ever made of this string is as part of WMI registration

Question 49

WDM job in DriverEntry

Answer 49

A WDM driver’s main job in DriverEntry is to fill in the various function pointers in the driver object. These pointers indicate to the operating system where to find the subroutines you’ve decided to place in your driver container

Question 50

• DriverUnload

Answer 50

Set this to point to whatever cleanup routine you create. The I/O Manager will call this routine just prior to unloading the driver. If there’s nothing to clean up, you need to have a DriverUnload function for the system to be able to unload your driver dynamically.

Question 51

• DriverExtension->AddDevice

Answer 51

Set this to point to your AddDevice function. The PnP Manager will call AddDevice once for each hardware instance you’re responsible for

Question 52

• DriverStartIo

Answer 52

If your driver uses the standard method of queuing I/O requests, you’ll set this member of the driver object to point to your StartIo routine

Question 53

• MajorFunction

Answer 53

The I/O Manager initializes this vector of function pointers to point to a dummy dispatch function that fails every request. You’re presumably going to be handling certain types of IRPs—otherwise, your driver is basically going to be deaf and inert—so you’ll set at least some of these pointers to your own dispatch functions.

Question 54

Handle IRPs

Answer 54

Every WDM driver must handle PNP, POWER, and SYSTEM_CONTROL I/O requests, and it should handle
SYSTEM_CONTROL I/O requests

Question 55

DriverUnload

Answer 55

The purpose of a WDM driver’s DriverUnload function is to clean up after any global initialization that DriverEntry might have done. If your DriverEntry routine returns a failure status, the system doesn’t call your DriverUnload routine. Therefore, if DriverEntry generates any side effects that need cleaning up prior to returning an error status, DriverEntry has to perform the cleanup.

Question 56

AddDevice Routine

Answer 56

a driver might be called upon to manage more than one actual device. In the WDM architecture, a driver has a special AddDevice function that the PnP Manager can call for each such device.
The basic responsibility of AddDevice in a function driver is to create a device object and link it into the stack rooted in this PDO. The steps involved are as follows:
1. Call IoCreateDevice to create a device object and an instance of your own device extension object.
2. Register one or more device interfaces so that applications know about the existence of your device. Alternatively, give the device object a name and then create a symbolic link.
3. Next initialize your device extension and the Flags member of the device object.
4. Call IoAttachDeviceToDeviceStack to put your new device object into the stack.

Question 57

ISR

Answer 57

interrupt service routine

Question 58

DPC

Answer 58

deferred procedure call