The document provides an overview of the Windows operating system, summarizing its key goals, components, and design principles. The Windows OS aims for hardware and software portability, high performance, and a secure object-oriented architecture. It uses a thread-based process model, handles for object access control, and structured exception handling for robust error handling. The OS implements standard objects like events, mutexes, and files using its object manager and security model.

1. The Windows Operating
System

2. Goals
• Hardware-portable
– Used to support MIPS, PowerPC and Alpha
– Currently supports x86, ia64, and amd64
– Multiple vendors build hardware
• Software-portable
– POSIX, OS2, and Win32 subsystems
• OS2 is dead
• POSIX is still supported—separate product
• Lots of Win32 software out there in the world

3. Goals
• High performance
– Anticipated PC speeds approaching
minicomputers and mainframes
– Async IO model is standard
– Support for large physical memories
– SMP was an early design goal
– Designed to support multi-threaded processes
– Kernel has to be reentrant

4. Process Model
• Threads and processes are distinct
• Process:
– Address space
– Handle table (Handles => file descriptors)
– Process default security token
• Thread:
– Execution Context
– Optional thread-specific security token

5. Tokens
• “Who you are”—list of identities
– Each identity is a SID
• Also contains Privileges
– Shutdown, Load drivers, Backup, Debug…
• Can be passed through LPC ports and
named pipe requests
– Server side can use this to selectively
impersonate the client.

6. Object Manager
• Uniform interface to kernel mode objects.
• Handles are 32bit opaque integers
• Per-process handle table maps handles to
objects and permissions on the objects
• Implements refcount GC
– Pointer count—total number of references
– Handle count—number of open handles

7. Object Manager
• Implements an object namespace
– Win32 objects are under BaseNamedObjects
– Devices under Device
• This includes filesystems
– Drive letters are symbolic links
• ??C: => the appropriate filesystem device
• Some things have other names
– Processes and threads are opened by
specifying a CID: (Process.Thread)

8. Standard operations on handles
• CloseHandle()
• DuplicateHandle()
– Takes source and destination process
– Very useful for servers
• WaitForSingleObject(),
WaitForMultipleObjects()
– Wait for something to happen
– Can wait on up to 64 handles at once

9. Security Descriptors
• Each object has a Security Descriptor
– Owner—special SID, CREATOR_OWNER
– Group—special SID, CREATOR_GROUP
– DACL
• Discretionary Access Control List
• List of SIDs and granted or denied access rights
– SACL
• System Access Control List
• List of SIDs and access rights to be audited

10. Access Rights
typedef struct _ACCESS_MASK {
USHORT SpecificRights;
UCHAR StandardRights;
UCHAR AccessSystemAcl : 1;
UCHAR Reserved : 3;
UCHAR GenericAll : 1;
UCHAR GenericExecute : 1;
UCHAR GenericWrite : 1;
UCHAR GenericRead : 1;
} ACCESS_MASK;

11. Security Use
• Objects are referred to via handles
• Security checks occur when an object is
opened
– Open requests contain a mask of requested
access rights
– If granted to the token by the DACL, the
handle contains those access rights
• Access rights are checked on use
– Just a bit test—very fast

12. Object Open
evt = OpenEvent(EVENT_MODIFY_STATE,
FALSE, "SomeName");
– Finds the event object by name
– Walks the DACL, looking for token SIDs
– Keeps looking until all permissions are
granted
– If access is granted, inserts a handle to the
object into the process’s handle table, with
EVENT_MODIFY_STATE access

13. Object Use
SetEvent(evt);
– SetEvent() requires EVENT_MODIFY_STATE
access, and an event object.
– The kernel looks up the handle in the
process’s handle table.
– Checks to make sure that it maps to an event
object, and that the granted access bits
contain the EVENT_MODIFY_STATE bit.
– If all is good, the event is set.

14. Object Use
WaitForSingleObject(evt)
– WaitForSingleObject() requires a
synchronization object (like an event) and
SYNCHRONIZE access.
– evt maps to an event object
– SYNCHRONIZE access was not requested
when the handle was inserted.
– Even if the DACL permits it, the wait fails.

15. Types of Objects
• Events
– State is set or clear.
– Can clear when a wait completes (auto-reset)
• Mutexes
– Can be acquired by a single thread at a time.
– Automatically release when owner exits.
• Semaphores
– Maintain a count
– Waits decrement the count

16. More objects
• Threads, Processes, Timers—like events
• Registry Keys
– Manipulate data in the registry—centralized
store of system configuration info.
• LPC Ports
– Fast local RPC
– Security tokens can transfer over LPC calls
• Files

17. Files & IO
• File objects maintain a current offset, and
a pointer to the underlying stream.
• Default internal model is asynchronous
– Synchronous IO just waits for the IO to
complete
– Async IO can set an event, or run a callback
in the thread which queued the IO, or post a
message to an IO completion port.
• Each request is an IRP

18. IRPs
• Maintain state of IO requests, independent
of the thread working on the IO
• IRPs are handed off through the device
stack to their destinations
– Threads process IRPs
– Initiating thread processes the IRP until a
device returns STATUS_PENDING
– Subsequent processing can be done in kernel
worker threads

19. Interrupts
IRQL—Interrupt Request Level:
0 => PASSIVE_LEVEL
Processor is running threads
All usermode code is at IRQL 0
1 => APC_LEVEL; threads, APCs disabled
2 => DISPATCH_LEVEL
• Running as the processor: can’t stop!
• Can’t take a page fault
• Only locks available are KSPIN_LOCKs

20. Interupts
3-26 => Device Interrupt Service Routines
• Device interrupts are mapped to an IRQL and an
interrupt service routine; ISR is called at that IRQL
27 => PROFILE_LEVEL—profiling
28 => CLOCK2_LEVEL—clock interrupt
29 => IPI_LEVEL—interprocessor interrupt
• Requests another processor to do something
30 => POWER_LEVEL—power failure
31 => HIGH_LEVEL—interrupts disabled

21. Interrupts
• Hardware signals an interrupt
• Interrupt’s ISR runs at device IRQL
– Has to be fast; get off the processor and allow
other ISRs to run
– Typically queues a DPC, acknowledges the
interrupt, and returns
• DPC—Delayed Procedure Call
– Further processing at DISPATCH_LEVEL
– Queues work to kernel worker threads

22. IO Completion
• Driver calls IO Manager to complete the
IRP
• IO Manager queues a kernel mode APC to
the initiating thread
• APC: Asynchronous Procedure Call
– Kernel mode APC preempts thread execution
– Writes data back to user mode in the context
of the thread which initiated the IO
– Signals completion of the IO

23. IO Cache
• Classic: block cache
– Page mappings translate directly to blocks on
the underlying partition.
• Windows: stream cache
– Page mappings are offsets within a stream.
– IO Cache Manager uses the same mappings.
– All cache management (trimming) is
centralized in the memory manager
– All modifications show up in mapped views.

24. Virtual Memory
• Sections—another object type
– Can be created to map a file
– Can also be created off the pagefile
– Optionally named, for shared memory
• Reservation
– Range of VA which will not be handed out for
some other purpose
• Committed
– VA which actually maps to something

25. Aside: CreateProcess
• Just a user mode Win32 API
{
NtCreateFile(&file, szImage);
NtCreateSection(&sec, file);
NtCreateProcess(&proc, sec);
NtCreateThread(&thrd, proc);
}
WaitForSingleObject(proc);

26. Virtual Memory
• Memory Manager maintains processor-
specific page table entry mappings.
– Some parts of the address space are shared
between processes—for instance, the kernel’s
address space and the per-session space.
• On a pagefault, mm reads in the data
• Pages can be mapped without the
appropriate access… what to do?

27. Signals
• With threads, signals don’t work very well.
• Some software designs expect to touch
inaccessible memory.
– Large structured files
– Concurrent garbage collection
– SLists
• Single global handler has to somehow
know about all possible situations.

28. Structured Exception Handling
• Exceptions unwind the stack
– Almost like C++!
– C++ matches against a type hierarchy
– SEH calls exception filter code—filters are
Turing-complete.
• Two ways to deal with exceptions:
– try/finally
– try/except

29. try/finally
res = AllocateSomeResource();
try {
SomeOperation(res);
} finally {
if (AbnormalTermination()) {
FreeSomeResource(res);
}
}
return res;

30. try/except
try {
SomeOperationWhichMayAV();
} except (Filter(
GetExceptionCode(),
GetExceptionInformation())) {
DoSomethingElse();
}

31. try/except
• GetExceptionCode()
– A code indicating the cause of the exception
• GetExceptionInformation()
– Additional code-specific info
– The full processor context
• Filter decides what to do
– EXCEPTION_EXECUTE_HANDLER
– EXCEPTION_CONTINUE_SEARCH
– EXCEPTION_CONTINUE_EXECUTION

32. Structured Exception Handling
• On x86, TEB points to stack of
EXCEPTION_REGISTRATION_RECORD
– auto structs, pointing to handler code
– pushed by function prolog
– popped by function epilog
• On exception, RtlDispatchException()
walks the list.
– Runs the filters to figure out what to do
– Calls handler functions

33. Structured Exception Handling
• On x86, there’s some overhead with
pushing and popping the registration
record
• On ia64, there is no overhead
– Stack traces are reliable
– It’s always possible to look up the handler
• Exception handling is very slow
– Especially on ia64
• Used only for truly exceptional conditions

34. Structured Exception Handling
• Used in kernel mode too!
– Most user mode access will just work
– Still need to validate address ranges & data
– Works great for SMP when another thread
might be in the middle of modifying the
address space
– Expected read exceptions are returned as
status codes from system calls
– Expected writes are returned as SUCCESS
– Unexpected => buggy kernel => blue screen

35. Top-level Exception Filter
• Top frame on each thread defines a
catchall exception filter
• Top-level exception filter:
– Notifies the debugger (if being debugged)
– Launches a just-in-time debugger (if set up)
– Loads faultrep.dll to report the failure

36. Faultrep.dll
• faultrep.dll offers to report the failure back
to Microsoft
• We analyze the failures
– A significant number are recognized instantly;
we can tell the user what happened and how
to fix it.
– The others go through the standard triage
process; developers analyze the dumps and
figure out what happened.

37. OCA
• 67 million machines running XP
• Tens of thousands of drivers
• Over 100 drivers on any given machine
• One bug in one driver => Crash
• A significant number of crashes come
from third-party drivers (some of which
ship on the CD)
• Lots of different problems, though

38. Driver Verifier
• Controlled by verifier.exe
• Special-pool’s allocations
– Detects allocation overruns & use after free
• Validates some behaviors
– IRQL—touching paged memory?
– DMA buffers
• Can inject failures—useful for testing
behavior under sub-optimal conditions

39. Stress
• Every night, a couple hundred machines
run stress on the latest build
• Stress exercises filesystems, memory,
GUI, scheduler, &c, trying to uncover low-
memory handling problems and race
conditions
• Every morning, the stress test team
triages failed machines
• Developers debug the failures

40. Questions?