Try to answer before you open the answers. Guessing is fine; checking your guess is how you learn.


QUICK REVIEW (5 minutes)

  1. What is a device driver, in one sentence?
  2. At which CPU privilege ring do kernel-mode drivers run, and what is the usual file type?
  3. What does UMDF stand for, and what happens if a UMDF driver crashes?
  4. What are the three kinds of device object in a device stack (short names)?
  5. What are the three kinds of file in a driver package?
  6. Where is the Driver Store on disk?
  7. What are the Start values 0, 1, 2 and 3 for a driver?
  8. What is a hardware ID, and how is it different from a compatible ID?
  9. What does the I/O Manager create to describe a request?
  10. What are the two steps Windows uses when a device interrupt arrives (name both)?

ANSWER KEY — DO NOT READ UNTIL YOU'VE ANSWERED

Click to reveal answers

1. Driver

A piece of software that lets the operating system talk to one kind of hardware, by translating general OS requests into the device's own commands.

2. Kernel-mode drivers

Ring 0. The file is usually a .sys file in C:\Windows\System32\drivers.

3. UMDF

User-Mode Driver Framework. The driver runs in a host process (WUDFHost.exe) in ring 3. If it crashes, only that process stops, and the PC keeps running.

4. Device objects

PDO (Physical Device Object, made by the bus driver), FDO (Functional Device Object, made by the function driver) and Filter DO (made by a filter driver).

5. Driver package

An INF file (instructions), the binaries (.sys and so on) and a catalog (.cat, a signed list of file fingerprints).

6. Driver Store

C:\Windows\System32\DriverStore\FileRepository

7. Start values

0 = boot start (loaded by the boot loader), 1 = system start (during kernel start-up), 2 = auto start (late in boot), 3 = demand start (when something needs it). (4 = disabled.)

8. Hardware ID vs compatible ID

A hardware ID identifies this exact device (for example USB\VID_xxxx&PID_xxxx). A compatible ID says "I follow this general standard" (for example USB\Class_03), so a generic class driver can be used as a fallback. A hardware ID match ranks better.

9. IRP

An I/O Request Packet (IRP).

10. Interrupt handling

The ISR (Interrupt Service Routine: the quick, urgent part) and then the DPC (Deferred Procedure Call: the follow-up, a moment later).


UNDERSTANDING QUESTIONS

Q1. Why can't an application talk straight to the hardware, and how does the driver layer help security?

Answer Programs run in ring 3, which cannot touch device registers or memory ranges; only ring 0 code can. Also, many programs share one device. If every program could drive the disk directly, they could ignore file permissions and each other. So requests go through the kernel and the driver, where Windows checks permissions and puts requests in an order. The driver layer is the single, controlled door to the hardware.

Q2. Why do most new drivers use WDF instead of plain WDM?

Answer WDM leaves every Plug and Play, power and cancel-request detail to the driver author, and mistakes in those rare cases cause hard-to-find crashes. WDF (KMDF/UMDF) supplies safe, tested handling for all of that, so the author writes only the device-specific part. The result is shorter code and fewer bugs.

Q3. Explain why an ISR must be very short and does its main work in a DPC.

Answer An ISR runs at a high IRQL (DIRQL), where lower-priority interrupts on that core are held back, it cannot wait, and it can only touch non-pageable memory. A long ISR would delay every other device and make the PC lag. So the ISR only acknowledges the device and saves key facts, and queues a DPC. The DPC runs a moment later at DISPATCH_LEVEL, when other devices can be served again, and does the real processing (such as completing the IRP).

Q4. What do DMA, scatter/gather lists and the IOMMU each contribute in a driver?

Answer DMA lets the device move data to and from RAM without the CPU copying each byte. A scatter/gather list lets the device use a buffer made of many separate pieces of memory, so no slow big copy is needed. The IOMMU makes sure the device can only reach the memory the driver mapped for it (the driver gives device addresses, not raw ones), which protects the system from buggy or hostile devices.

Q5. A signed driver is not necessarily a good driver. Why?

Answer A signature proves who made the files and that they have not been changed since signing. It does not prove the code is free of bugs or that it cannot be abused. Signed-but-vulnerable drivers have been used to attack systems, which is why Windows also keeps a blocklist of known bad drivers, and offers protections such as Memory Integrity.

SCENARIO QUESTIONS (Troubleshooting)

S1. After installing a new graphics driver, your PC shows a blue screen with SYSTEM_SERVICE_EXCEPTION and a .sys file from the graphics maker. What do you do?

Answer Write down the stop code and file name. The new driver is the most likely cause, so undo it: boot into Safe Mode if the PC cannot start normally, then Device Manager → the graphics adapter → Properties → Driver → Roll Back Driver (or uninstall the driver and let Windows use its basic one). Then install a different, newer or older version from the maker's site. If it still crashes, check the memory dump with WinDbg (`!analyze -v`) or look at Event Viewer's BugCheck 1001 entry.

S2. After a Windows update, the PC shows INACCESSIBLE_BOOT_DEVICE before the desktop. Which kind of driver is most likely involved, and why?

Answer A **boot-start storage driver**. Windows can only read its own system disk if the storage controller driver (Start = 0) loads very early. If the driver is missing, broken or incompatible with the controller mode (for example the BIOS was switched from AHCI to RAID), Windows cannot reach the disk. Fix by restoring the correct controller mode, or by repairing/rolling back the update from the Windows Recovery Environment.

S3. A USB device you plug in appears in Device Manager as "Unknown USB Device (Device Descriptor Request Failed)". What does this tell you?

Answer The USB bus driver detected the device and enumerated it (steps 1 and 2 of Section 16 worked), but could not read its device descriptor (step 3), so no hardware ID could be built and no driver could be matched. Try another cable or port, avoid unpowered hubs, check for a faulty device, and update the chipset/USB controller drivers. The problem is below the driver-matching stage, in the signal or the device.

S4. Task Manager shows 40% CPU in "System interrupts", the mouse stutters and audio crackles. Which part of this chapter explains it and what would you do?

Answer Section 10: a slow ISR/DPC or an interrupt storm. Some driver is spending too long at a high IRQL or its device keeps firing interrupts. Use a tool like LatencyMon to name the driver, then update it, roll it back, or unplug or disable that device (on a test basis) to confirm.

S5. A device shows a yellow warning mark with "Code 52: Windows cannot verify the digital signature". What happened and what is the safe answer?

Answer The driver is unsigned, altered or signed in a way Windows does not accept for kernel code (Kernel-Mode Code Signing, Section 8.4). The safe answer is to get a properly signed driver version from the maker or Windows Update. Do not turn on test signing or disable signature enforcement on an everyday PC just to force it in.

INTERVIEW QUESTIONS

I1. Explain the difference between kernel-mode and user-mode drivers and give the trade-offs.

Answer Kernel-mode drivers run in ring 0 with direct hardware access and can handle interrupts and DMA. They are fastest, but a bug can crash the whole system (BSOD) or give an attacker full control. User-mode drivers (UMDF) run in a host process in ring 3 and reach the kernel through a reflector. They are a bit slower and cannot handle interrupts or DMA directly, but a crash only stops the host process. Microsoft recommends the least possible code in ring 0.

I2. Describe the life of an IRP for a ReadFile call.

Answer The program calls `ReadFile`, which makes a system call. The I/O Manager finds the device object from the handle, allocates an IRP with major code `IRP_MJ_READ` and one stack location per driver, and sends it to the top of the device stack. Each driver can pass it down, complete it, or mark it pending. The bottom driver starts the hardware (often with DMA). When the device finishes, it raises an interrupt; the ISR queues a DPC, which completes the IRP. The IRP climbs back up, running any completion routines, and the I/O Manager returns the result to the program.

I3. How does Windows choose a driver when a new device is plugged in?

Answer The bus driver reads the device's identity and reports hardware IDs and compatible IDs to the PnP Manager. The PnP Manager searches the Driver Store (and Windows Update if allowed) for INF files that list those IDs, and ranks the matches: a hardware ID match beats a compatible ID match, signed drivers are preferred, and newer date and version win ties. It then loads the driver, calls AddDevice to build the stack, assigns resources and sends the start message.

I4. What is IRQL, and why is "IRQL_NOT_LESS_OR_EQUAL" such a common blue screen?

Answer IRQL (Interrupt Request Level) is a priority level of a CPU core; only higher levels can interrupt lower ones. Code at DISPATCH_LEVEL or above (DPCs, ISRs) cannot wait for a page fault to be resolved from disk. If a driver touches pageable memory at such a level, or uses a bad pointer, the kernel cannot recover and stops with this bug check (and DRIVER_IRQL_NOT_LESS_OR_EQUAL when it can tell a driver was involved). It is common because it is an easy mistake to make in ISR/DPC code.

I5. How would you investigate a BSOD on a customer's PC, step by step?

Answer Record the stop code and any `.sys` name. Ask what changed recently. Check Event Viewer (System log: Kernel-Power 41 and BugCheck 1001). Collect the minidump from `C:\Windows\Minidump`, open it in WinDbg with symbols and run `!analyze -v`; read the bug check parameters and the stack. Be careful about blaming the named driver, since memory corruption may come from another one. Roll back or update the suspect driver, run memory diagnostics if the crashes look random, and on a test machine consider Driver Verifier to expose the real culprit (and then `verifier /reset`).

PRACTICAL TASK

Draw "the driver map" of one of your devices. Pick one device on your PC (a keyboard, a mouse or a network adapter). Using Device Manager (Devices by connection, the Driver tab, the Details tab) and the commands from the lab, draw a diagram that shows: the device tree path from the PCI Express root down to the device; the driver (.sys) names involved; the hardware ID and compatible ID; the driver provider and signer; and the registry service key for its main driver (Start and Type values). Label which drivers are likely kernel-mode and which parts are bus, function or filter layers.

Why This Matters

When a device misbehaves, you need to know what lies under it. A map like this tells you where to look (the bus parent? the class driver? a filter?), which driver to update or roll back, and how to read a blue screen that names a .sys file.


CHAPTER SUMMARY

  • A driver translates between Windows and one kind of hardware. It exists because of diversity, abstraction and security.
  • Kernel-mode drivers (.sys, ring 0) are fast and powerful, but a bug can cause a BSOD. User-mode drivers (UMDF) are safer and more limited.
  • WDM is the original model; WDF (KMDF, UMDF) makes drivers easier and safer. Each driver has a driver object; each device or layer a device object (PDO, FDO, filter). Requests travel down a device stack.
  • Installation uses an INF, a catalog and binaries in a driver package, kept in the Driver Store. Staging puts the package in the store; installing binds it to a device.
  • Loading: DriverEntry (once per driver), AddDevice (once per device), then the start message. Start types 0–4 (boot, system, auto, demand, disabled) are recorded under HKLM\SYSTEM\CurrentControlSet\Services, like Chapter 12's services.
  • Plug and Play: bus drivers enumerate devices; hardware IDs and compatible IDs are matched and ranked; devices come and go while the PC is running.
  • Signing: catalogs and signatures prove who made a driver and that it is unchanged; WHQL, attestation, test signing and kernel-mode code signing are linked to Secure Boot and Memory Integrity.
  • IRPs are the request envelopes: created by the I/O Manager, passed down the stack, completed back up.
  • Interrupts are handled as ISR then DPC. DMA needs the driver to supply device addresses and scatter/gather lists, with the IOMMU as a guard.
  • Symbolic links (C: → \Device\HarddiskVolume3) let programs open devices via CreateFile.
  • Dependencies and filter chains link drivers together; failures cascade.
  • BSODs have stop codes and often name a .sys file; dumps live in C:\Windows\Minidump and MEMORY.DMP. WinDbg with !analyze -v analyses them. Driver Verifier is for test machines only.
  • Plugging in a USB keyboard uses nearly all of the above in one chain.