text:
Main Windows NT Device Driver Development

# Windows NT Device Driver Development

,
Year: 1999
Publisher: Macmillan
Language: english
Pages: 686
ISBN 10: 1-57870-058-2
File: PDF, 16.98 MB

## Most frequently terms

You can write a book review and share your experiences. Other readers will always be interested in your opinion of the books you've read. Whether you've loved the book or not, if you give your honest and detailed thoughts then people will find new books that are right for them.
1

### A History of the Girl: Formation, Education and Identity

Year: 2018
Language: english
File: PDF, 3.10 MB
2

### Beyond The Art of Finger Dexterity

Year: 2008
Language: english
File: PDF, 6.64 MB
Windows NT Device Driver
Development
P eter G. Viscarola
W. Anthony Mason

M
TIP

MACMILLAN
TECHNICAL
PUBLISHI
. NG
U•.S•A

201 West 103rd Street, Indianapolis, Indiana 46290

Resources, Inc.
FIRSTEDffiON
transmitted in any form or by any means, electronic or mechani
cal, including photocopying, recording, or by any information
storage and retrieval system, without written permission from
the publisher, except for the inclusion of brief quotations in a
review.

Publisher
Jim Le Valley
Executive Editor
Linda Ratts Engelman
Managing Editor
Caroline Roop
Acquisitions Editor
Karen Wachs
Development Editor
Christopher Cleveland

International Standard Book Number: 1-57870-058-2

Project Editor

Library of Congress Catalog Card Number: 97-80986

Copy Editor
Nancy Sixsmith

2001

00

99

4

3

2

Interpretation of the printing code: The rightmost double-digit
number is the year of the book's printing; the rightmost single
digit, the number of the book's printing. For example, the print
ing code 98-1 shows that the first printing of the book occurred

Indexer
Tim Wright
Acquisitions Coordinator
Amy Lewis

in 1998.

Manufacturing Coordinator
Brook Farling

Composed in Sabon and MCPdigital by Macmillan Computer
Publishing

Book Designer

Printed in the United States of America

Cover Designer
Aren Howell

Warning and Disclaimer

Maribeth Echard

This book is designed to provide information about Windows

Production
Tim Osborn
Staci Somers
Mark Walchle

NT device drivers. Every effort has been made to make this
book as complete and as accurate as possible, but no warranty
or fitness is implied.
The information is provided on an as is basis. The authors and
Macmillan Technical Publishing shall have neither liability nor
responsibility to any person or entity with respect to any loss or
damages arising from the information contained in this book or
from the use of the discs or programs that may accompany it.

All terms mentioned in this book that are known to be trademarks or service
marks have been appropriately capitalized. Macmillan Technical Publishing
cannot attest to the accuracy of this information. Use of a term in this book
should not be regarded as affecting the validity of any trademark or service
mark. Windows NT® is a registered trademark of Microsoft Corporation.

Feedback Information
At Macmillan Technical Publishing, our goal is to create in-depth technical
books of the highest quality and value. Each book is crafted with care and pre
cision, undergoing rigorous development that involves the unique expertise of
members from the profe ssional technical community.
Readers' feedback is a natural continuation of this process. If you have any
comments regarding how we could improve the quality of this book, or other
networktech@mcp.com. Please make sure to include the book title and ISBN in

Acknowledgments
Peter G. Viscarola: I never wanted to write a book. Of course, I always

thought it would be nice to have written a book-who wouldn't want to be
able to put "author of such and such" on their resume, right? But actually
write one ? No thanks, it always sounded like too much work to me. After all,
I've got classes to teach, clients to meet, code to write, and a consulting prac
tice to run. Where would I ever find the time to write a book?
Somehow, Linda Ratts Engelman (the Executive Editor for this book series)
convinced Tony and me that we really needed to write this book. She con
vinced us that we just had to write this book. She convinced us that we want
ed to write this book. How she managed to do this without once ever telling
us it would be easy or that we really would have the time to do it, I'll never
know. But she did it. I am thus grateful to Linda and her powers of persuasion
for talking us into doing this project.
I am also thankful for Linda's cool head and good humor in shepherding us
through the actual process. If we delivered software the same way that we
delivered this book-months late and 60% larger than planned-OSR would
I want to thank all the students over the past five years who have told me
"You guys really should write a book ! " and who insisted that it was an impor
tant thing for us to do. If you-all hadn't insisted so strenuously that we should
write this book, we never would have agreed to meet with Linda in the first
place. So, thank you.
The actual process of writing this book was made much easier for us, and
much more pleasant, by Development Editor Chris Cleveland. Chris did every
thing humanly possible to let us focus solely on writing the book. This relieved
us of having to worry about millions of bits of administrivia like manuscript
text formats, procedures, conventions, or other publishing arcana. I am most
grateful for his willingness to be flexible and advocate for us. His excellent
sense of humor and ability to keep things in perspective (of The Chicago
Manual of Style he once wrote: "I hate that damn orange book " ) were some
times the only thing that motivated me to work on the next chapter.
This book could not have been started, never mind completed, without the
assistance of the entire staff of OSR Open Systems Resources, our consulting
company. I am extremely grateful for all the support I received during the writ
ing process. I am particularly grateful to the consulting associates who assisted
with this book: Mark Cariddi for his work on the sample OMA driver and his
reviews, Pete Nishimoto for his work on the sample PIO driver and his chapter
reviews, and Mark Roddy for his technical reviews which often caught errors
nobody else saw. It is a pleasure to work with each one of you.

Our technical editor could not have been more helpful. Many thanks to Mike
Barry who, despite the fact that he was already working a million hours per
week, took the time to do thorough reviews and keep us focused on the basic
technical details the book needed. His support, especially early in the process
( "Another great chapter! " ) was really, really, important.
Finally, I want to thank my wife and my parents, who never complained about
my not being around and without whose support and encouragement I would
have quit this project within sixty seconds. My wife Karen, especially, was
always supportive and always understanding when I had to work every night
and every day every weekend for the more than six months it took to actually
do the writing. Thanks, sweetie! I couldn't have done it without you.
Peter Viscarola
September 1 998
W. Anthony Mason: The suggestion that we write a book has come up several
times over the years here at OSR. Each time we would look at our schedules,
we would conclude that there was simply no time to actually complete such a
complex task-I had previously written a book and knew that it was always
considerably more work than it seemed when it started.
Imagine my surprise when I found that Linda Ratts Engelman had convinced
us-especially Peter, who is normally quite level-headed and thoroughly willing
to say "no" when something just isn't possible-to write this book. And, of
course, we found that writing the book took longer than we'd expected. In
addition, we found that the demands of our consulting company constantly
distracted from the very important task of finishing the book.
While it will come as no small surprise to the readers, this book is fundamen
tally Peter's work. While I contributed in a few small ways, it fundamentally
represents his vision of how to teach people to construct device drivers for
Windows NT. Thus, as you read this book and find things praiseworthy, it is
Peter's doing.
Of course, my own personal thanks also go out to the MTP staff-I especially
enjoyed the comments back from Chris, as well, since he couldn't tell the parts
I wrote apart from the parts Peter wrote! Without Chris, and the other MTP
folks, this book would not have been a reality.
Throughout the stress of it all, I relied upon my wife Tammy, who was quite
understanding about my constant absences-if it wasn't because I was writing
small portions of the book, it was because I was trying to pay enough attention
to OSR Open Systems Resources to make up for Peter's focus on the book.
Tony Mason
September 1998

Peter G. Viscarola is a founder of, and Consulting Partner at Open Systems

Resources (OSR), the world-renowned consulting firm specializing in Windows
NT systems internals. During more than 20 years in the computer industry,
including more than 1 0 years as an independent consultant, Peter has developed
device drivers and protocol implementations under a wide array of operating
systems. Since the release of Windows NT, Peter has designed or developed
more than three dozen Windows NT drivers, including drivers for almost every
type of programmed 1/0 and DMA device imaginable. Recent Windows NT dri
ver projects include development of high-speed drivers for ATM®, ISDN, and
Frame Relay devices, as well as design of special Kernel mode drivers for a
number of unique situations. Peter's particular areas of expertise include net
working and high-speed DMA architectures where hardware-driver interactions
are critical. Peter has a long background developing and teaching high-tech
courses, and is the developer and chief instructor of Open Systems Resources'
Windows NT Kernel Mode Device Driver Seminar. Peter attended Columbia
University and the University of Michigan, where he studied applied statistics
and computer science, and Lesley College where he studied applied manage
ment. Peter is a regular contributor to and columnist for The NT Insider, Open
Systems Resources' journal of Windows NT systems internals. He is a Senior
Member of the IEEE and a voting member of the ACM.
W. Anthony Mason is an Open Systems Resources Consulting Partner with

experience in a wide array of system software disciplines during the past 1 6
years. Tony i s also internationally recognized expert in file systems technolo
gies. Among his recent projects have been the design and development of sever
al Windows NT installable file system drivers, including both physical media
file systems and networked distributed file systems. In addition to his file sys
tems expertise, Tony is Open Systems Resources' resident expert on NT's
Memory Manager and Cache Manager subsystems. Tony also has considerable
experience designing and developing Windows NT device drivers, his most
recent such project being a DMA driver for a high-speed video encryption
board. Tony is the architect and major designer and implementor of Open
Systems Resources' File System Filter Driver and File System Driver
Development Kits. He is also the developer and chief instructor of Open
Systems Resources' Developing File Systems for Windows NT Seminar. Tony
received his Bachelor of Science degree from the University of Chicago, where
he studied mathematics and computer science. Tony is also a regular contribu
tor to The NT Insider, Open Systems Resources' journal of Windows NT sys
tems internals.

(

Michael W. Barry contributed his considerable practical, hands-on expertise to

the entire development process for Windows NT Device Driver Development.
As the book was being written, Mike reviewed all the material for technical
content, organization, and flow. His feedback was critical to ensuring that
Windows NT Device Driver Development fits our reader's need for the highest
quality technical information.
Mike Barry has 17 years of programming experience. Upon receiving a BSEE
from the University of Texas at Austin, Mike went to work for Datapoint
Corporation where he was involved in networking and desktop video confer
encing. Mike holds numerous patents ranging from video teleconferencing to
color-image processing to cluster printing. He has been involved in NT Kernel
and User mode programming since the Windows NT 3 . 1 beta and is considered
an expert on the Windows NT operating system. Currently, Mike is Vice
President of Development at T/R systems, Inc. (the inventors of cluster print
ing), where he and his group are pioneering cluster printing systems based on
Windows NT.
Mike lives in Atlanta, Georgia, with his lovely wife and two wonderful chil
dren. In his free time, he enjoys scuba diving, tennis, camping, water skiing,
and knee boarding.

Errata Contributors
The authors are grateful to the following individuals who took the time to
write us with technical questions or additions to the list of errata.
Andre Asselin
Roger Coote
David Hawkins
Tuong Hoang
Paul Lever
Jon Moore

Tom Picard
Venkatesan Ranganathan
Nikolaus Rollinger
Hong Son
Steven M. Whitman
Christopher S. Worley
Jicun Zhong

Contents at a Glance
Part I

1
2
3
4
5
6
7
Part II

8

9
10
11
12
13
14
15
16
17
18
19
20
Part ID

21
22
23
24
Part IV

A
B
c

Introduction

1

Windows NT Architecture

7

Windows NT Operating System Overview
Achieving Hardware Independence with the HAL
Virtual Memory
The Registry
Dispatching and Scheduling
Interrupt Request Levels and DPCs
Multiprocessor Issues

9
29
45
93
1 07
121
139

The 1/0 Manager and Device Driver Details

153

1/0 Architectures
The 1/0 Manager
How 110 Requests Are Described
The Layered Driver Model
Driver Structure
DriverEntry
Dispatch Entry Points
Interrupt Service Routines and DPCs
Programmed 1/ 0 Data Transfers
DMA Data Transfers
Building and Debugging Drivers
Creating a Finished Driver
Installing and Starting Drivers

1 55
1 67
1 83
211
245
257
321
363
391
433
485
515
529

Alternate NT Driver Architectures

549

File System Drivers
Video Miniport Drivers
SCSI Miniport Drivers
NDIS Miniport Drivers

551
559
569
577

Appendixes

587

Windows NT Status Codes/Win32 Error Codes
Sources of Information for Driver Writers
Changes in NT V5.0
Index

589
625
629
645

x

Windows NT Device Driver Development

Part I

1

Introduction

1

Windows NT Architecture

7
9

Windows NT Operating System Overview

Windows NT Major Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... .... . . . . . . . . . . . 1 0
Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0
Multitasking ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1
Demand Paged Virtual Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2
Multiprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2
Processor Architecture Independence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3
Microkernel Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3
Integrated Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4
Multiple Operating System Emulation ..................................... 1 4
User Mode Programs and Environment Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . 1 5
Bypassing the Environment Subsystem ................... ........ . . . . . . . . . 1 7
The Native Windows NT API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . 1 8
The Win32 Environment Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . 1 8
The Windows NT Executive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . 1 9
I/O Manager .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Object Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Security Reference Monitor ..................................................... 25
Process Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Local Procedure Call Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Memory Manager and Cache Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Win32 Support Components . . . . . . . . . . . . . . . . . .................................. 27
Windows NT Microkernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 7
Hardware Abstraction Layer . . . . . . . ... . . . . . . . . . . . . . . . . . . ................................. 28

2

Achieving Hardware Independence with the HAL

29

The HAL's Role in the Windows NT Operating System ................... .30
Device Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ........................ . . . . . . . . . 32
I/O Architecture
33
Choosing the Correct HAL Function for Device Access . . . . . . . . . . 34
HAL Buffer Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .... . . . . . . . . .37
Interrupt Management . . . . . . . . . . . . . . . . ..................................................... .40
DMA Operations ... .... . . . . . . . . . . . . . . . . . ..................................................... .4 1
Other HAL Facilities ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Processor Architecture Differences Not Handled by the HAL . . . . . . . . . . .43
................................................................................

Contents

3

xt

45

Virtual Memory

Demand Paged Virtual Memory ....... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Rationale for Demand Paged Virtual Memory ........................ .4 7
Memory Manager Operations ................................................. 49
Address Space Separation and Control .................................... 50
Memory Sharing
58
Copy-On-Write .
.
58
Memory-Mapped Files ............................................... ...... . . . . . . . . 62
Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... , . . . . . . 63
Address Translation .............................................................. . . ........... 69
......................................................................

......... .............................................................

Page Tables .............................................................................. 71
Virtual-to-Physical Address Translation . . . ..... ........................... 76
Context ............................................... . . . . . .... . . . . . . . . . . . ................. 80
Physical Memory Management ........................ . ... . . . . . . . . . . . . . . . . . . ........... 82
Page Frame Database . . . . . . . . . ..... ................................................. 82
The Page Recovery Algorithm . . . . . . . . . . . . . ........ . . . . . . . . . . . . . . .............. 83
Section Object
.
.
...
.
.
.
.
85
Memory-Manager Tuning
. . .
.
..
. 85
Drivers and VM ........................ ........................................................ 87
Memory Descriptor Lists
.
.
88
Structured Exception Handling ................................................ 89
.......... ..... .....

.................. ..... ..... ....... ..........

..... .... .. ..... ...... . ...... ......................... ....

..... ............................................. .....

4

93

The Registry

Viewing and Modifying the Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .............. 94
Registry Organization . . . . . . . . . . . . . . . . . . ..................................................... 98
Subkeys, Values, and Data Types ............................... .............. 99
Managing Wide Character Strings ............................. ..... . . . . . . . 1 0 1
Registry Keys o f Interest t o Device Driver Developers . . . . . . . . . . ... . . . . . . . 1 0 1
HARDWARE ................................................................................ 1 0 1
SOFTWARE ................................................................................ 103
The SYSTEM Subkey and Control Sets ..................................... 1 04

5

Dispatching and Scheduling

107

Dispatching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .................... . ... ............................ 107
Scheduling
111
Thread Priorities . . . . . . . . . . . . . . . . ... ................................................. 1 1 3
Pre-emption . . . . . . . . . . . . . . . . . . . . . . .... . . . . . . . . . . . . . . ................................... 1 1 7
The Impact o f Scheduling on Drivers ..................................... 120
.......................................................................................

6

Interrupt Request Levels and DPCs

121

Understanding Interrupt Request Levels (IRQLs) ............................ 122
IRQLs Are Not Scheduling Priorities ........................ ............. 1 23
Determining the IRQL ...... .... . . . . . . . . . . . . ........ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

XII

Windows NT Device Driver Development
How IRQLs Are Used
IRQL PASSI VE_LEVEL
IRQL APC_LEVEL
IRQL D I S PATCH_LEVEL
DIRQLs
IRQL H I GH_LEVEL
Deferred Procedure Calls (DPCs)
DPC Objects
Invoking and Servicing DPCs
DPC Object Characteristics
The DpcForlsr

.....................................................................

.............................................................

....................................................................

............................ ...............................

.................................................................................

..................................................................

....................................................

.............................................................. . . ..........

.................................................

...................................................

.................................................................................

7

139

Multiprocessor Issues
The Problem with Shared Data

125
125
125
127
128
129
130
130
132
134
136

.......................................................

...............................

Spin Locks
Executive Spin Locks
Interrupt Spin Locks
Spin Lock Implementations on Uniprocessor Systems

............

142
143
1 50
151

..............................................................................

1 52

.......................................................................................

.............................................................

...... ........................................................

Spin Lock Issues

Part II

8

140
141

153
155

The 1/0 Manager and Device Driver Details
1/0 Architectures
Programmed I/O Devices
Busmaster DMA Devices
Two Categories of Busmaster DMA Devices
Scatter/Gather
System DMA Devices

.............. ...................................................

................ .................................................

..........................

..................................................................

........................................................................

............... .......................................................

9

The 1/0 Manager
I/O Subsystem Design Characteristics: An Overview
The NT I/O Subsystem Is Consistent and Highly Structured
The NT I/O Subsystem Is Portable Across Platforms
The NT I/O Subsystem Is Configurable
The NT I/O Subsystem Is Pre-emptible and Interruptible
The NT I/O Subsystem Is Multiprocessor Safe
The NT I/O Subsystem Is Object-Based
File Objects
Driver Objects
Device 0 bjects
Interrupt Objects

155
159
159
1 60
1 62
1 65

167

.......................

...........

......................

...........................................

................

... .............................

..........................................

............................................................................

.......................................................................

.......................................................................

...................................................................

.....................................................................

167
1 68
1 70
171
1 72
1 72
1 73
1 74
1 75
1 76
1 79
1 79

Contents
The NT 1/0 Subsystem Is Asynchronous
The NT 1/0 Subsystem Is Packet-Driven
The NT 1/0 Subsystem I s Layered

xiu

.........................................

.........................................

...................................................

10

183

How 1/0 Requests Are Described
IRP Structure
Fields in the IRP's Fixed Part
Fields i n the IRP 11 0 Stack Location
Describing Data Buffers
Describing Data Buffers with Direct 1/ 0
Describing Data Buffers with Buffered 1/ 0
Describing Data Buffers with Neither 1/0
Evaluating Available Data Buffer Descriptor Options
1/0 Function Codes

1 80
181
181

...................................................................................

.................................................

......................................

..................................................................

................................

............................

..............................

............

.........................................................................

Understanding Device 1/0 Control Functions (IOCTLs)
Defining Custom IOCTLs
1/0 Request Parameters
Handling and Processing IRPs
Case Study: When Neither 1/0 Was the Only Alternative

1 84
186
187
188
189
1 92
1 94
1 94
196

198
1 99
205
208
209

.......

......................................................

.........................................................

.........................................................

...............

11

211

The Layered Driver Model
Kernel Mode Drivers
File System Drivers
Intermediate Drivers
Device Drivers
Mini-Drivers
Intermediate and Device Driver Layering
File System Driver Layering
Finding the Driver at the Top of the Stack
Understanding Driver Structure
Processing 1/0 Requests in Layers

213
214
214
214
215
216
220
223
223
224

.......................................................................

................................................................

..............................................................

.......................................................................

..........................................................................

........................................

.............................................................

......................................

.......................................................

...................................................

Processing the IRP ltself
Passing IRPs to Lower-Layer Drivers
Creating Additional IRPs to Be Passed to
Lower-Level Drivers
Advantages of the Layered Driver Model
Driver Capabilities in a Completion Routine
Special Understandings Between Drivers
Filter Drivers
Filter Driver Usage Guidelines
Fast 1/0
Case Study: The Importance of Load Order

.............. ...........................................

............................ .........

225
225

227
229
229
232
233
235
239
240
242

............................................................

..............................

.................................................................

.........................

.........................................

...................................................................................

...............................................

...........................................................................................

..........................

Windows NT Device Driver Development

xiv

12

245

Driver Structure
DriverEntry Points
. .
Understanding Driver Organization
Request Processing for Device Drivers
Request Processing for Intermediate Drivers

245
247
247
248
251

...... .. .................................................................

................................................

.

.................................... .................

.... ...............................

..
Request Processing Context
...........

.....

..........................

.. .

......................................... ..........

13

252
252

.. ........................................

257

DriverEntry
Determining Device Configuration
.
Resource Lists, Descriptors, and Partial Descriptors

.................. ...............................

Querying System Configuration Data
.
Querying Bus-Configuration Data
Querying the Registry
Creating Device Objects
Device Extensions
.
Device Names
.
.
..
Device Types and Characteristics
Device Exclusivity
.. .
Device-Naming Considerations
Claiming Hardware Resources
Mapping Logical Addresses to Kernel Virtual

..............

259
260

262
267
2 74
277
2 78
. 279
2 79
280
. 2 81
282
285
293

............. . . ....................

.........................................

............................................................

..................................................................

................. ................................................

.................. ............... .................

............... ..

...........................................

..........

...

.

.

.................................... ... .........

.......................................... ...

............................. ..............................

........................................................

......................................................

.

........

.
.
296
. .
297
300
Exporting Entry Points ................................................................... .301
Connecting to Interrupts and the Registering DpcForisr ................. 3 02
Translating Interrupt Levels and Vectors ............................... 302
Connecting Driver JSR to Interrupts ...................................... 303
Initializing the DPC Obj ect for the DpcForlsr ....................... 307
Getting an Adapter Object . . . . . . . . . .... . . . . . . . . . . . . . . . .................................. 307
Performing Device Initialization ...................................................... 3 1 0
Other DriverEntry Operations ....................................................... . 3 1 2
Intermediate Buffers . . . . . . . . . . . .................................................... 3 1 2
Common Buffers for DMA Devices ...................................... . 3 1 3
I/O Timers
315
Intermediate and Filter Drivers .................. . . . . . . . . . . . . . . . . . . ... . . . . . . .3 1 8
Dynamic Driver Unloading ................................................... ... . . . . . . . 3 1 8
........................... ................................ .... .....

......... .... .....................

...................................

.............................................................................

Contents

14

xv

321

Dispatch Entry Points

Validating Requests
. . .
.
. 324
Completing Requests
.
.
.
.
327
Boosting 1/0 Request Thread Priority ....................................329
How the 110 Manager Completes Requests ........................... 330
Pending and Queuing Requests ....................................................... 332
System Queuing ..................................................................... 335
Driver Queuing ...................................................................... 338
Supplementary Device Queues .............................................. 341
Request Processing .
.
.
341
Synchronous Processing and Completion
.
342
Asynchronous Processing and Completion
.
..
349
Combining Synchronous and Asynchronous Approaches
350
.
.
.
349
Cancel Processing
.
.
.
350
System Queuing and IRP Cancellation.
.
.
354
Driver Queuing and IRP Cancellation
.
.
357
Canceling In-Progress Requests
.
.360
S ummary
.36 1
..................... .... .... ................................. ..... .

................... ..... ................ .................... .......

.

... ................................. ........................... ........

............. .................

............ ...... . ......

......

.... ................................. ...... ............. ........

.......................... ................... .................... ........

.......... .............. ........

..... ..................... .......

............................. ..............

........................................................................................

15

363

Interrupt Service Routines and DPCs
Interrupt Service Routines
.
Processing Within an ISR
.
Interrupt Sharing and ISRs
.
The DpcForlsr and CustomDpc . .
.
The DpcForlsr Entry Point
Processing Within the DpcForlsr
ISR and DpcForlsr Design
ISR Versus DPC
.
ISR t o DPC Routine Latency
Case Study
.
..

.

364
365
3 73
. 374
374
3 77
.3 8 6
386
. . ..3 8 7
.3 8 9

............ ............................. ....................

.

.

.

........ .............................. ....... .... ..

.

.

.

..... ............... ................. .. .........

.

... ..... ................................. ..... ...

.
.
.

.......................................... .........

................................. .........

..................................................... ........

............ ........................................................

.
.

.

.

.

............ ..... ............ ..... ... ....

....................... ..........

16

.............. ...................................

Programmed 1/0 Data Transfers
Processing Programmed 1/0 Data Transfers

. .

.

.

.

391

.

391
393
398

.... ... .... ....... . . ..........

Getting the Requestor's Buffer Length
Manipulating the Device to Request and
Control the Transfer . .
..
Moving the Data Between the Device and
the Requestor's Buffer
Programmed 1/0 Example Driver .
.
Dispatch and Startlo Routines .
.
Interrupt Service Routine .
.
.
.

.

............. ....................

.

........................... .......

. .. .....

.

..398

.................................. ...........

.

. .

. 399
401
. .403
.. .4 1 1

....................................... .......... . . .

.

.
.. .

.. ......... ................ ........ .............

.

.. ............ ..... ......... . .. ....... .

. ...... ...... ....... .........................

...

xvi

Windows NT Device Driver Development
DPC Routine .........................................................................4 1 5
DPC Versus ISR i n the Example Driver .................................4 1 9
Design Issues fo r Programmed I/ O Device Drivers ..........................420
Mapping Device Memory into User Space .............................42 1
Polling
422
Synchronous Driver Implementations ....................................427
...................................................................................

17

433

DMA Data Transfers

Processing DMA Data Transfers ....................................................434
Map Registers .................................................................................436
DMA Device Architectures ..............................................................439
Packet-Based DMA ................................................................439
Common-Buffer DMA ...........................................................440
Comparing Packet-Based DMA with
Common-Buffer DMA ........................................................441
Packet-Based DMA Transfers ..........................................................442
Preparing for the Transfer......................................................443
Programming the Device ........................................................449
Completing the Transfer ........................................................456
Propagating Driver Execution ................................................458
Common-Buffer DMA Transfers .....................................................460
Allocating the Common Buffer ..............................................46 1
Performing the Transfer .........................................................462
Propagating Driver Execution ................................................463
Packet-Based DMA Driver Example ................................................464
Dispatch Routine ...................................................................465
Preparing for the Transfer ......................................................468
Programming the Device
.
.
.470
Interrupt Service Routine .......................................................4 72
Completing the Transfer and Propagating
...................... ........................ .......

Driver Execution .................................................................4 74
Design Issues for DMA Device Drivers ...........................................479
Alignment Restrictions
.
.4 79
System DMA .........................................................................48 0
......... ................................................

18

Building and Debugging Drivers

485

Setting Up the Driver Development Environment ............................486
Getting the Necessary Software .............................................48 6
Setting Up the Systems ...........................................................487
Setting Up Debugging ............................................................49 1
Building Drivers ..............................................................................500
Driver Debugging ............................................................................504
Kernel Debugger Extensions ..................................................506
Debugging and Testing Hints and Tips ............................................507
Displaying Output in WinDbg ...............................................508

Contents
Installing Multiple System Images on Your Test System
Turning Up the Serial Port Speed
SysRq Stops the Test System
Asserting Assumptions
ASSERT ( ) Works Only in the Checked Build
Define Your Own ASSERT ( ) Macro
Test on MP Systems
Use the Tools Supplied in the DDK
Check Your Driver with Performance Monitor
Enable Pool Checking
Test o n Both the Free and Checked Builds
Stay Up-to-Date
Turn t o the World for Help
Behind the Blue Screen
Blue Screen Format
Reporting o r Interpreting Blue Screens
Crash Dumps

xvn

..................................................

........

...........................................

..................................................

...........................................................

..........................

.......................................

...............................................................

.......................................

......................

............................................................

.............................

.....................................................................

...................................................

........ ............................................................

................................................................

..................................

..................................................................................

19

515

Creating a Finished Driver
Driver Error Logging
Defining Error Messages
Allocating the Error Log Packet
Writing Packets to the Event Log
Invoking the Message Compiler with BUILD
Registering Your Driver As an Event Logging Source
Defining Driver Version Resources

508
508
508
508
508
509
509
509
510
510
510
511
511
511
511
512
513
514

.......................................................................

515
516
520
522
524
524
525

........................................................

............................................

...........................................

........................

............

..................................................

Defining RC Files from the Microsoft-Supplied Templates
.

20

529

Installing and Starting Drivers
How Drivers Are Started
Driver Service Entries
Driver- and Device-Specific Parameters
Driver Installation
Text Setup
GUI Setup
Custom Setup

525
527

....

........................

530
53 1
540
541
542
546
546

.................................................................

............................................................

...........................................

...........................................................................

..............................................................................

..............................................................................

.......................................................................

Part ID

21

Alternate NT Driver Architectures
File System Drivers
File System Driver Characteristics
FSDs Are Called in the Context of the Requesting Thread
FSDs Are Tightly Integrated with the VM Subsystem
FSDs Are Closely Intertwined with the I/O and Object
Managers
Learning More About Developing File System Drivers

549
551

...................................................

....

............

............................................................................

....................

551
553
555

556
557

xvu1

Windows NT Device Driver Development
22

559

Video Miniport Drivers
Video Port/Miniport Drivers

...........................................................

Video Port Drivers
.
Video Miniport Drivers
Display Drivers
Device Display Interface (DDI) Drivers
.
DMA and Video Display Drivers
.
.
Learning More About Developing Video Display Drivers

560

560
561
563
565
. 567
568

...................................................... ..........

.........................................................

................................................................................

....................... ..........

.............. ....................... ......... ...

...............

23

569

SCSI Miniport Drivers

SCSI Miniport Driver Characteristics
5 69
SCSI Miniport Driver Structure
571
Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ........... .572
Request Initiation . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Interrupt Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ............ 574
Learning More About Developing SCSI Miniport Drivers ............... 575
..............................................

......................................................

24

577

NDIS Miniport Drivers

The NDIS Family of Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
The Windows NT Networking Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
NDIS Driver Types and the NDIS Library ..... . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
NDIS LAN Miniport Drivers . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ............ 581
Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Transmit Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Interrupt and DPC Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Transmit Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Message Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Serialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Learning More About Developing NDIS Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585

Part IV

Appendixes

A

Windows NT Status Codes/Win32 Error Codes

B

Sources of Information for Driver Writers

587
589
625

This Book's Web Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . .... . . . . . .. 625
Periodicals and Journals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . .... . . . . . . . . 626
The NT Insider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . 626
Windows NT Magazine ........................................... ....... . . . . . . . 626
Dr. Dobb's Journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Microsoft's Knowledge Base
.
.
626
Newsgroups, Mailing Lists, and FAQs .
.
627
comp . os . ms-windows . programme r . nt . kernel-mod e ............... 627
microsoft . public . win32 . programme r . kernel
.
627
NTDEV Mailing List
.
627
............................. .................... .........

... ..................... ..................

............ .........

................................................... .........

Contents

xix

NTFSD Mailing List
.
DDK-L Mailing List
The Windows NT Kernel-Mode Driver FAQ

........................................ .....................

..............................................................

.........................

627
627
628

Seminars
628
OSR Open Systems Resources, Inc. (http : / /WWW . osr . com) 628
David Solomon Expert Seminars (http : I /www . solsem . com) 628
..........................................................................................

...

..

C

Changes in NT VS.O
NT V4.0 Device Drivers on NT V5 .0.0
Driver Entry Changes .
Driver Entry in NT V5 .0
Processing Plug and Play IRPs
DMA Implementation Changes
Power Management

629
..........................................

. ....................................................................

.......................................................

...................................................

...............................................

.......................................................

.........................................................................

! R P_MN_QU ERY_POWER

Index

.

........ .....................................................

! R P_MN_S ET_POWER

.................................................................

I R P_MN_WAI T_WAKE

.................................................................

630
630
63 1
632
634
639
641
642
642
643

645

Introduction
This book describes the workings, both architectural and pragmatic, of stan
dard kernel mode device drivers for Windows NT. It explains how to design
and develop these drivers, as well as how to compile, link, and debug them.
The book focuses on standard Kernel mode device drivers, which are the kind
of driver you would write to support a custom add-on device in Windows NT.
The types of devices for which a standard Kernel mode driver are typically
written range from those as simple as a specialized parallel or serial port to
devices as complex as DMA-based realtime video encryption devices. While
this book might be generally useful to developers writing other types of drivers
on NT, we have shamelessly restricted our discussion of details in most cases to
those relevant to the development of standard Kernel mode device drivers.
We have designed this book to be useful to software engineers who have never
written a device driver, to those who have written drivers on other operating
systems, and even to those engineers who have already written a few drivers on
Windows NT. The book does assume a basic knowledge of operating systems
internals and a solid knowledge of the C programming language. We also
assume that the reader has a general understanding of how devices work: what
device registers are and how interrupts work. But, even if you've got a vague
grasp of these topics, this book should be within your reach.
If you've written lots of device drivers on Windows NT, you will undoubtedly
know much of what we present in this book. In fact, you will probably already
know the vast majority of the information. However, we hope that we will be
able to add at least one or two items of information to the repertoire of even
these old NT driver hands.

2

Not

Windows NT Device Driver Development

a

Cookbook

This book is not a cookbook with easy answers about how to write device dri
vers. Over the past five years, we've written several dozen NT drivers. We've
also taught something like 3,000 students how to write NT drivers in our three
day Windows NT Kernel Mode Device Drivers seminar. During that time
we've come to the conclusion that the cookbook approach to driver writing
only works if you're writing a device driver for a cookbook. In other words, it
almost never works at all.
Rather, what we have done in this book is identify, organize, and present as
clearly as possible all the information that a typical device driver writer will
need to truly understand how Windows NT device drivers "work." We have
mixed this with pragmatic hints, tips, and details which we have gained
through our experience designing and developing NT drivers for the real
ing every possible topic that might be of interest to some device driver writer
somewhere, we typically focus on those topics that we have found to be critical
for device driver writers to understand. We cover those topics fully and in
detail.
Basically, our goal was to give you all the information that we wish we had
when we started writing NT drivers. Understanding this information will allow
you to write not j ust any driver for your device, but the most optimal driver
offs. This approach will also allow you to make better sense of the information
presented in the Windows NT Device Driver Kit (DDK) .
The order in which the material is presented in this book is loosely based on
our seminar. Our seminar, and thus this book, utilizes what we have come to
call "The OSR Approach" to teaching people how to write device drivers. This
approach emphasizes the fact that a device driver is really an operating system
extension. In order to extend Windows NT effectively, a developer needs to
understand many of the details of how the operating system works. Thus, we
approach the task of explaining how to write a device driver in the following
steps:
1 . Start with general Windows NT operating systems concepts relevant to
driver writers
2. Progress to more detailed information about the operating system, such
as the virtual memory subsystem, interrupt management, and synchro
nization issues
3. Next discuss in detail how the 1/0 Subsystem works, and how drivers
interact with the 1/0 subsystem and with each other

Introduction

3

4. Discuss in detail the implementation of standard Kernel mode drivers
5 . Discuss, in great detail, the implementation of specific categories of stan
dard Kernel mode drivers
6. Use the knowledge of standard Kernel mode drivers to describe alterna
tive Windows NT driver architectures, such as SCSI, NDIS, and Video
Miniport drivers.

Organization of the Book
To reinforce the approach described previously, we have divided the book into
three parts. Part One ( Chapters 1-7) discusses details of the overall Windows
NT architecture relevant to driver writers. If you're new to working with the
Windows NT operating system at the internals level, understanding the con
tents of these chapters is absolutely vital to understanding how to design
Windows NT drivers. If you're an old hand at working with NT internals, you
should still probably skim these chapters to be sure that you're up on all the
terminology we use in the remainder of the book.
Part Two ( Chapters 8-20) covers the details of implementing standard kernel
mode drivers for Windows NT. In this part, we first discuss the basics of the
NT 110 Subsystem, and how 1/0 requests are described and processed. We then
move on to a detailed discussion of how Windows NT device drivers are orga
nized. After that, we delve into the major sections of an NT device driver (first
Driver Entry, then dispatch entry points, followed by ISRs and DPCs). Next,
we cover in great detail how both programmed 1/0 and DMA data transfers
are performed in NT drivers. In so doing, we present code for two nontrivial
sample device drivers. Part Two ends with a discussion of how drivers are built
and debugged on NT.
As we discuss each of the topics in Part 2, we try to give you the benefit of our
experience of writing NT drivers. We tell you not only how certain things are
supposed to work, but how they actually do work in our experience. Our goal
Part Three ( Chapters 21-24) expands on the knowledge gained in the other
parts of the book, and provides a basic overview of some of the additional dri
ver types used in Windows NT. This part relates the information already pre
sented about standard Kernel mode drivers to File System drivers, NDIS drivers,
SCSI Miniport drivers, and Video drivers. In so doing, our goal isn't to cover in
any depth or detail how to write these types of drivers. Rather, it is to provide
you with enough information to be able to understand the architecture and
structure of these special types of drivers.

4

Windows NT Device Driver Development

This book focuses on NT V4.0. However, we have gathered what information
on NT VS that we can (and that we think is reliable) and placed that in
Appendix C. As of this writing, NT VS is still a pretty distant goal. More
information about NT VS can be found on our Web site.

Web Site Support
We have dedicated a portion of the OSR Web site ( http: / /WWW .o s r . com ) to sup
porting this book. On our Web site you will find complete downloadable
source code for the sample drivers presented in Chapters 1 6 and 17. You will
also find updates, technical errata, clever utilities, and other things that may be
useful to driver writers.
We also will be placing information on our Web site about NT VS as it
becomes available. By the time NT VS is fully stable, we expect to have the
two sample drivers presented in the book available in both NT V4 and NT VS

Conventions Used in This Book
The following conventions are used in this book:

Note
A note explains terms or concepts that relate to what is discussed in the

text, but doesn't warrant full explanation in the text, as it may be dis
tracting.

A warning is a system critical reminder or guideline that provides cau

tionary advice to help limit exposure to potential problems, failures, secu
rity gaps, and so forth.
Function prototypes appear in boxes without shading and provide explanation
of function parameters.
Dispatch entry points appear in shaded boxes and provide explanation of entry
point parameters.

Introduction

5

Bug Bounty
This book contains thousands of technical details. We have worked very hard
to try to ensure every one of these details is correct. I have no doubt that we've
missed some. Thus, we ask for your help in ferreting out any remaining techni
cal glitches that might remain in this book.
To this end, the authors and Macmillan Technical Publishing are pleased to
offer you a " bug bounty" on this book. If you are the first to report a signifi
cant technical error in this book, we will provide you with gifts from both
OSR and the publisher as a token of our thanks. And, of course, we will keep
an up-to-date technical errata available on our Web site. This is part of the
commitment to technical accuracy that we make to you, our readers.

1 "Windows . ·.··· NT
the HAL

3 Virtual
-

.

MenJ(.)fY
---0--

Dispatching and Sched1:ding

5

7

•. .

lB�� R.egt�tif�,

.4
· · : •• . 6

•.

J\cliii:ving �itware ��pendeill .with

2

.·•·

OperatiJ.!g System Q¥.erview

- _ -,_

-- - -- :

·

�l���·�!P·.�i:.Rr��"l.1.�s�,i:,·i���!s..-, �'-� ;�gQj!
_ _
. _
·,:::_:::::::- ':.·:_:: .:,:.'�:-·.-.. >· ·_:.-<..:.:· .<_: ·· :· ·:.:.-:. ·.: .. ' : : -.. ·:.: '(: :_.:i:·:·: :·-:.>():;::�\-�-:':· _-'·" _.:·.:-'.:_;.-_;::.:· ·.:' :·_.:· ' ' ' :.>: · .,: ..._. ·: _ · -. _ .::-�:-_:·>:
_
'

'•

'

M�Itipro��s�()r Issues
•

· ·

·1·•

·
.1<. •: ·

·
.· ··· :;;.\ ., ;i!>C,>.

i�

Chapter

1

Windows NT Operating
System Overview
This chapter will review:
•

Windows NT Major Characteristics. This section describes the key archi

tectural features of the Windows NT operating system.
•

User Mode Programs and Environment Subsystems. Environment

Subsystems provide the interface between most User mode programs and
the Windows NT operating system. This section describes the role that
Environment Subsystems play in the Windows NT operating system.
•

The Windows NT Executive. The Kernel mode component of the

Windows NT operating system that interfaces with applications and
makes operating system policy decisions is called the Executive. This sec
tion provides an overview of the Executive's subsystems, and the func
tions those subsystems perform.

•

Windows NT Microkernel. The Windows NT Executive is built on top of

a Microkernel, which provides processor-specific support for the
Executive layer. This section describes the Microkernel.
•

Hardware Abstraction Layer. The Hardware Abstraction Layer (HAL)

decouples other parts of the operating system from the specific implemen
tation of underlying hardware. This section provides a brief introduction
to the HAL.
This chapter provides an overview of the architecture and characteristics of the
Windows NT operating system. If you're new to systems programming on
Windows NT, the information in this chapter will provide the background you
need to understand how the various pieces of the operating system that are dis
cussed in later chapters fit together. Even if you're experienced at using and
programming Windows NT, we recommend that you at least briefly skim this
chapter to become familiar with the terminology used throughout the book.

10

Part I: Windows NT Architecture

Windows NT Maj or Characteristics
How do you begin to describe an operating system? One way is to look at its
major characteristics or key features. The major characteristics of Windows
NT are that it implements:
•

•

•

Demand paged virtual memory, which utilizes a single, global common
cache

•

Multiprocessing

•

A processor-independent architecture

•

An internal OS structure based on a modified Microkernel model

•

Integrated networking

•

Multiple operating system emulation

The following sections consider each of these characteristics in a bit more
detail.

Although different processors have differing numbers of privileged execu
tion levels, Windows NT always uses only two processor-privilege levels.
It uses the most privileged processor execution level (Ring 0 on x86
architecture systems), which it calls Kernel mode. NT also uses the least
privileged mode of execution (Ring 3 on x86 architecture systems), which
is referred to as User mode.

The Windows NT model for executing programs is: Each program that exe
cutes is represented by a process. The process is created when program execu
tion is requested (for example, via the Win32 API function Create Process ( ) , or
via the native NT system service NtCreateProcess ( ) ) .
A process i s simply a container for the various resources and attributes o f the
program. For example, the process "owns" the address space used by the pro
gram. It also owns any handles (more about that later) that the program opens.
Resource utilization and quotas are tracked by the process. The process also
owns one or more threads of program execution.
The unit of execution and scheduling on Windows NT is the thread. An initial

Chapter 1 : Windows NT Operating System Overview

11

threads (via the Win32 API function CreateThread ( ) or the native NT
NtCreateThread ( ) system service) at any time. Unlike in OS/2, for example, no
thread within the process has any special status of any kind.
It is absolutely vital to understand that threads in Windows NT are truly the
basic units of execution and scheduling. Unlike some UNIX operating systems,
port a variant of lightweight threads called fibers) .
I n Windows NT, each thread has its own scheduling priority and is
autonomous in terms of scheduling. That is, the operating system does not take
into account the process to which a thread belongs when it makes scheduling
decisions. Thus, all other things being equal, two runnable threads within the
same process will compete for CPU time in precisely the same way that two
runnable threads from two different processes do.

As in any modern, general-purpose operating system, Windows NT allows
multiple units of execution to run simultaneously. It rapidly switches among
these units of execution, allowing each to run for a short period of time. This
In NT, multiple threads may run at one time. The decision of which thread is
selected to run is almost entirely based on priority. NT has 32 possible thread
priorities:
•

Priorities 0-1 5 are dynamic priorities.

•

Priorities 1 6-3 1 are real-time priorities.

NT implements what is known as pre-emptive multitasking. In NT, when a
thread is selected to run, it is scheduled to run for a time period called a
quantum. The quantum indicates the maximum length of time the thread will
be allowed to run before another thread is scheduled. If the thread waits or is
blocked during its quantum, a new thread is scheduled. While a given thread is
running, if a thread with a higher priority becomes runnable, the lower priority
thread is stopped from running and the higher priority thread is started. If the
thread runs for its entire quantum, the system pre-empts the thread from run
ning and selects a new thread to run.
The quantum value varies considerably, according to the platform (Intel or
Alpha) , the operating system type (Workstation or Server), whether the thread
in question is in the foreground or background, and the system tuning settings.
Suffice it to say that on an x86 architecture system running Windows NT
Workstation, the value used for quantum will typically range from 20

12

Part I: Windows NT Architecture

milliseconds to 90 milliseconds. On NT Server, the values typically range from
120 milliseconds to 1 80 milliseconds.
Scheduling is discussed in more detail in Chapter 5, "Dispatching and
Scheduling. "

Demand Paged Virtual Memory
Windows NT utilizes a virtual memory architecture in which each process has
its own 4GB virtual address space. This virtual address space is subdivided into
pages, in which each page is 4KB on x86 architecture systems or 8KB on
their processes' virtual address space, with the remaining 2GB of address space
to be used by the system. A tuning mechanism in Windows NT Enterprise
Server allows this to be extended to 3 GB (leaving 1 GB of address space for use
by the system) .
Virtual memory pages are loaded o n reference. When the amount o f virtual
memory exceeds the amount of physical memory, excess read-only image pages
may be freed (to be reloaded later from their original location), and read-write
pages may be temporarily written to one of the available paging files.
The NT virtual memory model allows the same physical addresses space to
appear within the virtual address space of multiple processes. This enables the
implementation of various methods of inter-process data sharing.

Multiprocessing
Although Windows NT was originally designed to support both asymmetric
and symmetric multiprocessing systems, today only symmetric multiprocessing
(SMP) systems are supported. In NT's model of SMP, all systems share the
same main memory, and each system has equal access to peripheral devices.
The operating system runs on all the processors in the SMP system. In
Windows NT, there is no concept of "master" or " slave" CPUs, as there is in
some other multiprocessing operating systems. In NT, thread-scheduling and
interrupt-handling can be equally distributed among all the processors in the
SMP complex.
The basic Windows NT architecture supports SMP systems with up to 32
CPUs. The actual number of CPUs that may be enabled, however, is governed
by licensing restrictions. By default, Windows NT Workstation systems support
up to only two processors. Windows NT Server systems, by default, support up
to four processors, and Windows NT Enterprise Server supports up to eight
processors. Hardware vendors, with appropriate license rights from Microsoft,
can alter these numbers.

Chapter 1 : Windows NT Operating System Overview

13

Processor Architecture Independence
Windows NT was designed to work on a wide variety of processors. To facili
tate this, most Windows NT operating system code is written in the C pro
gramming language. Use of Assembly language has been deliberately kept to a
minimum. Throughout its history, Windows NT has been supported on a vari
ety of processors ; As of this writing, Windows NT supports the x86 and Alpha
processor architectures.
The Windows NT operating system code is divided into three major groups:
•

The Executive, including the major operating system subsystems

•

The Microkernel

•

The Hardware Abstraction Layer (HAL)

The relationship among these major groups can be seen in Figure 1 .2 (which
appears later in this chapter). The Executive-level components utilize services
provided by both the Microkernel and the HAL. The HAL and Microkernel
work together to isolate the Executive-level components from processor archi
tecture dependencies. This is one of the keys to Windows NT's processor
independent architecture.
Another aspect of Windows NT processor-independence that is of particular
interest to driver writers is that Kernel mode drivers are compatible across var
ious processor architectures at the source level. This means that a driver writer
need only write a driver once. That driver can then be compiled by using the
Windows NT Device Driver Kit (DDK) to support any of the processor archi
tectures that Windows NT supports.
Note

Although there are a few drivers that are compatible between Windows
NT V4 and Windows 9x, the standard Kernel mode drivers described in
this book are not portable across these two operating systems. Windows
NT and Windows 9x have very different internal structures, and do not
share any significant operating system code between them.

Microkernel Model
The Windows NT operating system is based on a much-modified version of the
Microkernel architecture that was first pioneered by the Mach operating system.
Mach was designed by Carnegie Mellon University in the mid- to late-1 980s.
In Mach, privileged-mode activities were restricted to a very small subset of
functions, which resided in the Microkernel.

14

Part I: Windows NT Architecture

In Windows NT, the Microkernel is the module of the operating system that
typically deals with the mechanics of doing things on the system. It is the
Microkernel that is responsible, for example, for handling and routing inter
operation. The Microkernel has deliberately been kept small and tight, and is
for the most part processor-dependent.
Services provided by the Microkernel are utilized by the Executive-level com
ponents of the operating system. The Executive-level components are generally
responsible for implementing policy (that is, deciding what the operating sys
tem should do next).
It is important to realize that Windows NT is an exceptionally well-designed
operating system, which never arbitrarily adheres to a given set of architecture
constructs. Thus, although policy code is generally not implemented in the
Microkernel, exceptions are made when such a division is not practical. One
example of this is scheduling. In Windows NT, thread scheduling (or thread
dispatching, as it's often called) is the responsibility of the Microkernel.
Although moving scheduling to an Executive-level component would have been
more architecturally correct, the resulting overhead would be unacceptable.

Integrated Networking
From the time of its initial inception, Windows NT was designed to support
networking. This is in dramatic contrast to other PC-based operating systems
of the time (late 1 989 and early 1 990), which had networking added to them
as an afterthought.
Windows NT has always supported multiprotocol networks. Out of the box,
Windows NT supports the following protocol families:
•

AppleTalk

•

DLC

•

NetBEUI

•

IPX/SPX

•

TCP/IP

Multiple Operating System Emulation
One of the least-known attributes of Windows NT is that it was designed with
the goal of being able to emulate multiple operating systems. Thus, NT sup
ports execution of Win32, POSIX, OS/2, DOS, and Windows 3 . 1 programs
with their native semantics.

Chapter 1 : Windows NT Operating System Overview

15

This is not to say that any programs written for any of the operating systems
listed can be executed without restriction on Windows NT. Rather, the point is
that Windows NT was designed at a time when there were many different
operating systems contending to be "the one dominant operating system. " It
was not clear, for example, whether the IEEE 1 003 (POSIX) standard was
going to be preeminent in the marketplace, whether OS/2 was going to become
a major success, or whether Windows was going to catch the public's fancy.
Thus, being rather clever folks, the Windows NT development team designed
an operating system that was capable of emulating each of the popular operat
ing systems of the day, providing their native APis and semantics.
As the market developed, the Win32 API has become preeminent. As a result,
the multiple operating system support features in Windows NT have become
less important. More emphasis is now being placed on getting Windows exe
cutables to execute as fast as possible. However, understanding that these facil
ities exist is vital to understanding the overall architecture of Windows NT.

User Mode Programs and Environment
Subsystems
Processes in Windows NT typically run under the control of a specific
Environment Subsystem. An Environment Subsystem is an independent User
mode process that exports a set of APis for use by applications, exercises con
trol over those applications, and communicates with the Windows NT operat
ing system on behalf of those applications. Figure 1 . 1 shows the relationships
between a typical user application program, an Environment Subsystem being
used by that user application, and the Windows NT operating system.
As shown in Figure 1 . 1 , a User mode application utilizes one or more APis that
are provided by an Environment Subsystem. These APis are typically imple
mented by a client-side DLL, to which the user application links. When the
application calls an API function in the client-side DLL (as shown in Step 1 in
Figure 1 . 1 ), the DLL checks to see if it can handle the request locally. By this,
we mean that that DLL can process the request entirely within the client-side
DLL, without reference to any other module. If the request can be handled
locally, the client-side DLL processes the request and returns an appropriate
Most requests cannot be handled directly within the client-side DLL, however.
When a function is called, the client-side DLL typically builds a message that
represents that function and sends the message to the Environment Subsystem
(Step 2 in Figure 1 . 1 ). The message is sent using Windows NT's Local
Procedure Call facility, a highly optimized interprocess communication method,
designed specifically for this purpose.

16

Part I: Windows NT Architecture
User
Application

Native NT
System Service
(direct request
path)

(3)

Native NT
System
Service

User Mode
Kernel Mode
NT Operating System

Figure 1.1. User mode program and Environment Subsystem.

the request from the application, it will typically perform any Environment
Subsystem-specific processing required, and then translate that request to a
native Windows NT system service. The Environment Subsystem then issues
the Windows NT system service request on behalf of the user application (Step
3 in Figure 1 . 1 ) .
The Windows NT operating system processes the system service, and returns
its results to the Environment Subsystem, which in turn forwards the relevant
portion of the results to the requesting user application. This is shown in Step
4 of Figure 1 . 1 .
Hopefully, an example will make the relationships between the user applica
tion, the Environment Subsystem, and the NT operating system clear. Suppose
an OS/2 application is running under the control of the OS/2 Environment
Subsystem. This application issues a DosExecPgm ( ) function call (which requests
the execution of a child process). This function is implemented by code in the
OS/2 Environment Subsystem's client-side DLL. When the DosExecPgm ( ) func
tion is called, the code in the DLL assembles all the arguments and a unique
code representing the function requested ( oosExecPgm ( ) , in this case), and sends
all this to the OS/2 Environment Subsystem using NT's LPC facility.

Chapter 1 : Windows NT Operating System Overview

17

A server thread running a s part of the OS/2 Environment Subsystem process
receives the message sent by its client-side DLL. It notes that it has received a
request to process a DosExecPgm ( ) function. It then does whatever OS/2 sorts of
things it needs to do to process this request, implementing OS/2 semantics for
the request. For example, the Environment Subsystem determines whether the
execution of this new process was requested to be synchronous (in which case,
the request is not completed until the requested process exits) , asynchronous
(and hence parallel with the requesting process) , or background (totally inde
pendent of the requesting process) .
To actually execute the requested process, the OS/2 Environment Subsystem
issues the native Windows NT system service NtCreateProcess ( ) to the NT
operating system. When the NT process is created in response to the request,
the OS/2 Environment Subsystem will keep track of that process as being a
child of the requestor. If the new process was requested to be synchronous, the
OS/2 Environment Subsystem waits until the process has completed to return
status to the requestor. If the request was for an asynchronous OS/2 process,
status is returned immediately.
The POSIX Environment Subsystem implements support for fork ( ) and exec ( )
in the same way that the OS/2 Environment Subsystem implements support for
DosExecPgm ( ) . The POSIX Environment Subsystem applies POSIX-specific rules
and semantics to the function calls it receives. It translates received requests
into native Windows NT system service calls on behalf of the requestor, and
sends these system service calls to the NT operating system for processing.
Results are passed back to the original requesting process.
Originally, the Win32 Environment Subsystem was implemented in precisely
the same way as the POSIX and OS/2 Environment Subsystems. However, NT
V4.0 introduced a number of optimizations that resulted in much of the Win32
Environment Subsystem being moved from user mode to kernel mode. These
are discussed later in this chapter, in the section entitled "The Win32
Environment Subsystem. "

Bypassing the Environment Subsystem
In some cases, the client-side DLL can directly map a request to a native
Windows NT system service. This is the case when the native Windows NT
system service is close enough in terms of syntax to the original request, and
the Environment Subsystem does not need to perform any "value-added" pro
cessing to ensure that its semantics are maintained. This direct path is shown
by the dotted line in Figure 1 . 1 .
The most common case when the direct path is used i s for file and device 1/0
operations. In addition to avoiding the overhead inherent in first sending the
request to the Environment Subsystem, the direct path allows the 1/0 operation
to initially execute in the context of the requesting thread.

18

Part I: Windows NT Architecture

The Native Windows NT API
Windows NT implements a native set of system services that were designed to
facilitate operating system emulation. This API was never intended for direct
use by applications programmers, however, and is therefore largely undocu
mented.
A simple example of how the native NT API is specifically aimed at supporting
multiple Environment Subsystems is demonstrated by the NtCreateFile ( ) func
tion. This system service may be used to either create a new file or open a file
that already exists. In either case, part of the information passed to the
NtCreateFile ( ) system service indicates whether the call should treat the sup
plied filename as case-sensitive or not. This is important because in the Win32
API, filenames are always non-case-sensitive. Thus, the names foo . txt and
FOO . TXT (in the same directory) refer to the same file. However, in POSIX, file
names are always considered case-sensitive. Thus, the names foo . txt and
FOO . TXT (and Foo . Txt, and FOO . txt, and so on) all refer to different files.
A number of Windows NT native system services are documented in the DDK
in their zw variants. The functions documented include those used for 1/0 such
as zwcreateFile ( ) , ZwReadFile ( ) , ZMYri teFile ( ) , ZwClose ( ) ,
zwset l nformationFile ( ) , and ZwGet l nformationFile ( ) . Although either variant of
the function may typically be called from Kernel mode, the zw variant is used in
place of the Nt version to cause the previous mode (and hence the mode in
which the request was issued) to be set to Kernel mode.
To request a native Windows NT system service, the service parameters are
pushed on the stack and the system service is called. On x86 architecture sys
tems, Windows NT native system services are called by using software inter
rupt 2E. On Alpha systems, system services are called by using the syscall
instruction.

The Win32 Environment Subsystem
Starting with Windows NT V4.0, changes were made to the operating system
to enable faster support for programs running under the control of the Win32
Environment Subsystem. Prior to NT V4.0, all requests, except for file and
device 1/0 requests, were sent to the Win32 Environment Subsystem in the
manner described previously for the POSIX and OS/2 subsystems. Starting
with NT V4.0, however, many of the Win32 functions were moved directly
into Kernel mode. This allows the Win32 client-side DLLs (the Win32 subsys
tem uses multiple client-side DLLs) to use the direct path of sending requests
directly to the Windows NT operating system more often than was previously
possible.

Chapter 1 : Windows NT Operating System Overview

19

The modules moved from User mode to Kernel mode in NT V4.0 include the
Window Manager code, the Graphics Device Interface (GDI), and display dri
vers. Moving this code into Kernel mode significantly reduces the overhead of
making graphics requests. This is because significantly fewer transitions
between User mode and Kernel mode are required in NT V4.0 to perform a
given function.

The Windows NT Executive
The Windows NT operating system is divided into individual modules, as
shown in Figure 1 .2.
'

Eicecutive and System Services

1/0
Manager

[EJ

Object
Manager

Security
Reference
Monitor

Process
Manager

Local
Procedure
Gall

Memory
Manager

Cache
Manager

rs

Window Manager
and
Graphics Device
Interface

>

Graphics

Device
Drivers

Mlcrokemel

Hardware Abstraction Layer (HAL)

Figure 1 .2. Windows NT operating system structure.

The Windows NT operating system is comprised of a number of different mod
ules. As Figure 1 .2 illustrates, and as previously discussed in this chapter, these
modules are grouped together into three groups:
•

The Executive, which includes the operating system subsystems

•

The Microkernel

•

The Hardware Abstraction Layer (HAL)

The Executive is actually a specific module within the NT operating system
that is responsible for many miscellaneous functions, including system service
dispatching and managing the paged and non-paged system pools. The
Executive module utilizes services provided by the other Executive-level com
ponents (such as the 1/0 Manager, Object Manager, and so forth), and thus
lends its name to this entire group of operating system modules.
In addition to the Executive module itself, the major components within the
Executive level of the operating system are:
•

1/0 Manager

•

Object Manager

20

Part I: Windows NT Architecture

•

Security Reference Monitor

•

Process Manager

•

Local Procedure Call facility

•

Memory Manager

•

Cache Manager

•

Win32 support, including Window Manager, and Graphics Device
Drivers.

The following sections describe each of these components in more detail.

110 Manager
As you can probably guess from its name, the 1/0 Manager is responsible for
managing the input/output subsystem of the operating system. The 1/0
Manager does this by supporting create, read, write, set information, get infor
mation, and a whole host of other operations on File Objects. The I/O
Manager implements what is basically a packet-based asynchronous 1/0 sub
system that uses 1/0 Request Packets (IRPs) to describe 1/0 operations.
The 1/0 Manager is also responsible for providing a framework for Kernel
mode drivers, and provides support for those drivers. Kernel mode drivers are,
in fact, dynamically loaded into the operating system and may be thought of as
part of the 1/0 Manager. Because much of this book is about the 1/0 Manager,
and how it supports and provides an environment for device drivers, we will
defer any additional discussion of the 1/0 Manager for later. More general
information about the 1/0 Manager appears in Chapter 9, "The 1/0 Manager. "

Object Manager
The Object Manager is a key part of the Windows NT operating system.
Programmers who mostly work in User mode are typically unaware of the
Obj ect Manager's existence because it is not directly manipulated from User
mode and, by default, its namespace is not visible.
The Object Manager is responsible for maintaining a single namespace for all
named objects on the system. It is also responsible for the creation, deletion,
and management of named and unnamed NT system objects. The following
sections describe some of the major duties performed by the Object Manager
that are of particular relevance to driver writers.
Resolvi ng System Names
As mentioned previously, the Object Manager is responsible for maintaining a
single namespace for all named system objects. In fact, the Object Manager
serves as the root of all namespaces on a Windows NT system. The Object

Chapter 1 : Windows NT Operating System Overview

21

Manager's namespace can b e examined by using the o b j d i r utility that i s pro
vided with the DDK, or the winobj utility that is provided with the SDK. Figure
1 . 3 shows the Object Manager's top-level namespace, as displayed by o b j d i r .

Figure 1 . 3 . The Object Manager's root namespace.

To illustrate how the Object Manager's namespace is used in Windows NT,
let's examine how the Object Manager works together with the 1/0 Manager
to parse a file specification provided to a file open request.
A user that wants to access a file will typically use the Win32 API to issue a
function call that might look something like the following:
h file = CreateFile ( " c : \ \ foo \ \bar . txt " ,
GEN E R I C_READ : GENER I C_WR ITE ,

0,
NULL ,
OPEN_EX IST I NG ,
F I LE_ATTR IBUTE_NORMAL ,
NULL ) ;

II
//
//
//
//
//
//

dev , pat h , name
access
share mode
secu rity
disposition
attributes & f lags
template f ile

If successful, this function call creates a File Object (that's why the function is
called c r e a t e F i l e ) that represents an open instance of the named file, on the
named path, on the named device. The function returns a handle to this File
Object that may be used for subsequent 1/0 operations on the file.

22

Part I: Windows NT Architecture

In assisting the 1/0 Manager with processing this function, it is the Object
Manager that is responsible for initially parsing the supplied name
( c : \foo\bar . txt ) . It passes that part of the name that it cannot parse on to the
1/0 Manager for interpretation by the appropriate file system.
As previously discussed, when the C reateFile ( ) Win32 API call is issued, the
Win32 Environment Subsystem's client-side DLL converts this function call to
the native NT system service NtCreateFile ( ) . As part of the process of convert
ing the parameters, Win32 converts the supplied name to a native format name
that Windows NT can understand. It does this by pre-pending the supplied
name with the string " \ ? ? \ " . Thus, when it issues the native NT system service
NtCreateFile ( ) , it does so by using the name \ ? ? \ c : \ foo \ ba r . txt.
The Executive's system service Dispatcher calls the 1/0 Manager to process the
NtCreateFile ( ) request. The 1/0 Manager in turn calls the Object Manager to
create a File Object to represent the entity named in the function call. Part of
the Object Manager's job in creating the File Object is to parse the provided
name.
The Object Manager parses the provided name, one piece at a time, with each
piece being delimited by a backslash character. Thus, the Object Manager
starts by looking to see if it has an entry in its top level namespace that corre
sponds to " \ ? ? " . As Figure 1 .3 illustrates, in fact it does, and this entry is an
Object Manager directory. Figure 1 .4 shows a sample of the contents of the
Object Manager's \ ? ? .

Figure 1.4. The Object Manager's

\ ?? directory.

Chapter 1 : Windows NT Operating System Overview

23

With the first piece of the name resolved, the Object Manager next attempts to
resolve the next piece of the name within the \ 77 directory. The next piece of
the name is " c : . As shown in Figure 1 .4, c : represents a symbolic link to the
Object Manager name \ Device \ Harddisk0\ Partit io n 1 . Thus, the Object
Manager substitutes \Devic e \ Harddisk0 \ Pa rt itio n 1 for the name c : in the origi
nal name.
"

The Object Manager continues parsing the name. It returns to its base directo
ry and attempts to resolve the first piece of the name, which is now " \ Device " .
As shown in Figure 1.3, this is a directory, which the Object Manager next
opens. Figure 1 .5 shows the contents of the \ Device directory on a sample
system.

E::l:

... ...
Dauico
Do11ico
l>GUico
Dovico
Douico
'Douico

Euont

:Dbeat11>rJ1
Dboct:1u•y
Dor.iico
Do11ico
llor.1ico
Douico
Douiao
Doi.iioo
Douica
hutco
Dauiao
Euont:
.....
Do11ico
Doutco
llouillo
DoYico
huioo
......
Dodoo
�vico
Dodoo

Dcluico
So.ct:iaQ
Dooioo
Da..,ico
Doviu

Dou:lco
Daulco
......
Dodoo
Do11ico
Doutco
hu:loo
Doutco
Do11ico
Douico
Douico
D:booot:oPll
Dtnriao
Dauiao
Do111 ico
Douico

Figure 1.5. The Object Manager's

\ Device directory.

The Object Manager continues parsing pieces of the supplied name. Within the
\ Device directory, the Object Manager finds an entry that represents Harddisk0.
This is also a directory, the contents of which are shown in Figure 1 .6.
Now within the \ Devic e \ Harddisk0 directory, the Object Manager continues
parsing the provided name. The next piece of the name is Parti tion 1 , which
represents the name of a Device Object within this directory. Because a Device
Object was located (and not another Object Manager directory or symbolic
link), the Object Manager passes control to the 1/0 Manager's parse method
for Device Objects.

24

Part I: Windows NT Architecture
�' '""":.:.1��1':..".:•1•1

--

--

-

-

-

- --

-

-- -

--

-

-

-

--

--

----

- --

---

-- -

-

- --

____

!?.:.!;:

Dou:lco
Douico
Douico

Figure 1 .6. The Object Manager's

\ Devic e \ Ha rddisk0 directory.

The Object Manager passes the 1/0 Manager's parse method the remaining
part of the name { \ foo\ bar . txt ) to be resolved. The 1/0 Manager's parse
method resolves this part of the name by finding the File System mounted for
the indicated Device Object, building an 1/0 Request Packet representing the
Create File request, and thus passing the remaining part of the name on to the
File System for parsing and validation. If the file system decides the supplied
name is valid, and if the requested access can be granted to the entity by the
file system to the user, then the 1/0 Manager and Object Manager complete the
request successfully, returning a handle to the created File Object.
System Obj ect Management
As mentioned previously, in addition to parsing names, the Object Manager is
responsible for the actual creation, deletion, and management of NT system
objects. These objects include the File Objects, Device Objects, and Driver
Objects used by the 1/0 Manager; the Process Objects and Thread Objects
used by the Process Manager; and Section Objects used by the Memory
Manager, among others. The Object Manager is also responsible for maintain
ing reference counts on system objects, managing object handles, and tracking
the access granted to each object via each handle. The Object Manager also
supports converting a handle to a given object to a pointer to that object.

To illustrate the 1/0 Manager's role in the management of system objects, let's
expand on the open file example that we started in the previous section.
As discussed in the previous section, to access a file, a user must create a File
Object that represents that file. This File Object can be created by using the
Win32 API function CreateFile ( ) or directly via the NT native API
NtCreat eFile ( ) . Both of these functions allow the caller to specify the name of
the entity to be accessed (such as the device, directory path, and name of the
file to be opened), as well as the access being requested to the entity.
NtCreat eFile ( ) is processed by the 1/0 Subsystem, which calls the 1/0 Manager
to create a File Object on its behalf.
If the Obj ect Manager successfully creates the File Object, and if the Object
Manager, 1/0 Manager, and file system successfully parse the supplied file

Chapter 1 : Windows NT Operating System Overview

25

specification, the 1/0 Manager returns a handle to the newly created File
Object to the requestor. This implies that the access requested to the entity
underlying the File Object was successfully granted. The Object Manager cre
ates an entry in the handle table for the current process to track this File
Object, and records the access that was successfully granted to the object.
On subsequent 1/0 operations to this File Object, the requestor supplies the
File Object handle (typically referred to as a file handle, for convenience) .
Using the current process' handle table, the Object Manager converts the file
handle to a pointer to a File Object and increments the reference count on the
File Object. At the same time, the Object Manager also checks to see if the
access required by the 1/0 operation that is being requested is allowed by the
access that was granted to this File Object when the File Object was created. If
the access is not allowed, the 1/0 Manager immediately aborts the 110 opera
tion with an error status. If the requested access is allowed, the 1/0 Manager
proceeds to build an 1/0 Request Packet that represents the requested 1/0 oper
ation on this File Object.
As can be seen from the preceding description, the Object Manager plays a key
role in the Windows NT system. It's important to realize that the Object
Manager doesn't j ust work with the 1/0 Manager, as shown in the preceding
example. Rather, the Object Manager works with all the Executive-level
subsystems in much the same way as it works with the 1/0 Manager in the
example.

Security Reference Monitor
The Security Reference Monitor is responsible for implementing Windows NT
security access policy. As such, it is not of much interest to device driver writ
ers. However, its existence and its responsibilities are worthy of a brief men
tion.
The Security Reference Monitor implements Access Control Lists (ACLs) and
Security Identifiers (SIDs) for use in implementing system security policy. It
supports a unique per-thread security profile, and supports security-based vali
It is particularly interesting to note that Windows NT implements a unified
security policy. That is, access to all system resources (that are access
controlled) is the responsibility of the Security Reference Monitor. For exam
ple, access validation to files on the NTFS file system is implemented not by an
internal NTFS security policy, but rather by NTFS utilizing the services provid
ed by the Security Reference Monitor.
Another interesting aspect of the Security Reference Monitor is support for
what NT refers to as impersonation. This allows one thread to pass along to

26

Part I: Windows NT Architecture

credentials. This is most often used in client-server operations. In these opera
tions, the client will authorize the server to impersonate the client, thereby
allowing the server to use the client's security credentials when performing a
particular operation.

Process Manager
The Process Manager is responsible for process and thread creation and dele
tion. The Process Manager accomplishes this by working with the Object
Manager to build Process Objects and Thread Objects, and with the Memory
Manager to allocate virtual address space for the process.

Local Procedure Call Facility
The Local Procedure Call (LPC) facility provides a local implementation of the
RPC interprocess communication service. LPC supports passing data between
clients and servers by using either messages or shared memory. One interesting
feature of LPC is that messages may be passed between clients and servers
without the overhead of a scheduling operation.
LPC was specifically designed for use between an application and its
Environment Subsystem. As a result, the API needed to access LPC is not docu
mented. It is interesting to note that RPC requests between applications on the
same Windows NT system will actually use LPC as the transport mechanism.

Memory Manager and Cache Manager
The Memory Manager and Cache Manager together form what we refer to as
Windows NT's Virtual Memory Subsystem. The Virtual Memory Subsystem is
described in detail in Chapter 3, "Virtual Memory. " Here, we will mention
some of the main characteristics of NT's implementation of virtual memory as
a quick introduction to the topic.
The NT Virtual Memory Subsystem provides a 32-bit demand paged environ
ment. Although 64-bit support is being added to Windows NT, it is not avail
able in NT V4.0 or earlier.
The Virtual Memory Subsystem supports the sharing of physical pages among
memory segments.
The Virtual Memory Subsystem is responsible for implementing Windows NT's
data and file caching mechanisms. File data may be accessed on Windows NT
via the I/O Manager, using standard read and write operations to files, or via
the Memory Manager by mapping the file's data directly into virtual memory.
To ensure cache coherency between these two access methods, the Windows

Chapter 1 : Windows NT Operating System Overview

27

NT Cache Manager implements a single, global, common cache. This single
cache is used to cache both process data pages and file data pages.

Win32 Support Components
As discussed previously, the Win32 support components are new to NT V4.0.
The Window Manager implements Windowing, Windows messaging, and the
like. It comprises much of that code that formerly resided in the User compo
nent of the Win32 Environment Subsystem.
The Win32 support components also include the Graphics Device Interface
(GDI) and its associated display drivers. These facilities interface between GUI
applications and graphics devices, and provide a set of standard text and draw
ing primitives.

Windows NT Microkernel
The Windows NT Microkernel is responsible for providing processor-specific
support for all low-level functions in the operating system. Unlike the HAL,
which provides support for processor resources that can change among specific
models within a family of processors, the Microkernel provides support for
basic architectural constructs, such as handling and dispatching interrupts, sav
ing and restoring thread context, and multiprocessor synchronization.
The Microkernel exports two different types of kernel objects: Dispatcher
Objects and Control Objects.
Kernel objects are distinct from Object Manager (or Executive-level) objects.
Kernel objects provide the lowest level of support for certain entities. Kernel
objects are often the basis for Object Manager objects.
One type of kernel object is the Dispatcher Object. Dispatcher Objects are used
for scheduling (or "dispatching," as it's called in Windows NT) and synchro
nization. Dispatcher Objects are prefixed by a common D I S PATCH_HEADER (the
definition of which appears in the standard DDK header file, ntdd k . h ) . A pic
ture of the D I S PATCHER_HEADER is shown in Figure 1 . 7.
Dispatcher Objects have an attribute called "signal state. " Using the appropri
ate system service a caller can wait, with an optional timeout, on a Dispatcher
Object until the object is signaled. Kernel Dispatcher Objects include events,
mutexes, semaphores, and timers.
Many kernel objects may be directly manipulated by device drivers and the
Executive. A simple example of such an object is the kernel Event Object.
Space for a kernel Event Object may be allocated fr om any non-paged loca
tion, including non-paged system pool. A driver may then initialize this event

28

Part I: Windows NT Architecture

(using the Microkernel-supplied function Ke i n it ializeEvent ( ) ) to either sig
naled or not-signaled state. Any Kernel mode thread with a pointer to this
object may then wait for it to become signaled by calling the Microkernel func
tion KeWai t F o rSingleOb j e c t ( ) .
Inserted

I

Size

I

Absolute

I

Type

Signal State

Figure 1 .7.

An example of how a Kernel Object can form the basis of an Executive-level
object is also provided by the Event Object. Event Objects in the Win32 sub
system (created by the Win32 API function CreateEvent ( ) ) are actually
Executive-level ( Object Manager-created and managed) Event Objects. Each
Executive-level Event Object contains a kernel-level Event Object. Waiting for
an Executive-level Event Object is accomplished via the Win32 API function
Wait ForSingleOb j e c t ( ) which, once translated to an NT native system service
and processed by the Object Manager, results in a call to
KeWai t F o rSingleOb j ect ( ) on the kernel Event Object that forms the basis of the
Object Manager's Event Object.
The second type of object exported by the kernel is the Control Object. These
objects are used to control specific aspects of system operations. Control
Objects include Asynchronous Procedure Call (APC) Objects, Deferred
Procedure Call (DPC) Objects, Interrupt Objects, and Profile Objects.
Although it is a bit complicated to explain Control Objects at this point, one
example is the Interrupt Obj ec