Windows Internals 4th Ed. Comments&Corrections

Edit 2010-01 · net helpmsg 4006

I am
starting this topic to try to complement the comments and corrections for the Book
which are indicated at

http://support.microsoft.com/kb/892212 

(this kb page
has not been updated since March 28, 2007).
Edit 2010-01. This page has now a revision date of April 13, 2009, but is basically the same as in March 2007.

Here is a
first list, please feel free to add your own comments and corrections.

Page 53

Note that figure 2-4 corresponds to Windows 2000 only. With Windows XP or later, the Os2 value is not present.
Page 68

Experiment: Determining which HAL you�re
running. The two
methods presented may give different results. An alternate method is to use the
properties/original filename for the file \windows\system32\hal.dll
Page 78-79

In the last line of page 78 and the first line of page 79, an alternate to the !dso windbg extension command to dump the first argument to ExQueueWorkItem, i.e. nt!_WORK_QUEUE_ITEM, is dt  _work_queue_item esp+4
The address of the worker routine to be called in the context of the worker thread is then at [_work_queue_item+0x8].

Page 90

Experiment: Viewing the PIC and APIC. In the second paragraph, 
"so this is the I/O APIC for processor 0: 
lkd> !apic"
should be replaced by 
"so this is the local APIC for processor 0:
0: kd> !apic"
Page 98
Kernrate experiment: In the first line of this page, the sec. is missing in Interrupt Rate= 1911/sec.
The first sentence could better read : "The overall summary shows that the system spent 11.7 percent of the time in kernel mode (including 6.4 percent DPC time and 1.3 percent interrupt time), 30.2 percent in user mode and 58.1 percent idle.
Page 107

Step 2. The
command �tracelog �stop to stop logging.� should really be �tracelog �stop� the
remaining words �to stop logging.� are comments
Page 139
Figure 3-21
is specific to Windows 2000, so its text could be amended to read: 

Figure 3-21a Structure
of a handle table entry (Windows 2000 case)

 A figure for
XP/ Server 2003 could be added as follows:

 |_______Pointer
to object header________|A|I|L|

 |________|P|   Access mask _________________|
                 bit#25

 Figure 3-21b Structure of a handle table entry
(Windows XP / Server 2003 case)

 The first paragraph below the figure could be slightly
amended to read as follows:

"The P flag indicates whether the caller is allowed to
close this handle (this flag can be specified with the Windows SetHandleInformation function). The I
flag is the inheritance designation-that is, it indicates whether processes
created by this process will get a copy of this handle in their handle tables.
As already noted, handle inheritance can be specified on handle creation or
later with the SetHandleInformation
function. The A flag, at bit number 2, indicates whether closing the object should generate an
audit message (this flag isn't exposed to Windows API-the object manager uses it
internally). The L flag is the lock bit.

Page 167

In the middle of the page, add "base" before priority in the following lines:
Delayed worker threads execute at base priority 12, ...
Critical worker threads execute at base priority 13, ...
(reason: These threads may execute at higher dynamic priorities)

In the sentence before last above Table 3-11 add the following:
"Table 3-11 shows the initial number of worker threads created on different system configurations with at least 64 MB of RAM." [these were known as "large systems"!!] (ref:ExpWorkerInitialization, MmInitSystem)

Page 176

In the list of events that can be traced with the Kernel Logger, below TCP/UDP activity, add : DPC/ISR events (for  XP SP2, Server 2003 SP1 and  later) 
Page 257
Two more boot options valid for Windows XP and Windows Server 2003 could be added to Table 5-2. Namely, /CHANNEL and /USEPMTIMER.
/CHANNEL is used when connecting 2 PCs for debugging purposes via an IEEE1394 link
/USEPMTIMER specifies that the PM-timer, if supported by the processor, should be used for timer purposes rather than the TSC
See http://support.microsoft.com/kb/833721 for more information on both options
Page 260
/NOEXECUTE boot option: in fact this option is available on other processors than AMD64, as described on page 390 under "No Execute Page Protection", first paragraph.Page 262

The meaning
for /TIMERES has misprints.

The table
should read as follows:

Hundreds of nanoseconds                               Milliseconds (ms)

9766                                                                                                                 
0.98

19532                                                       2.00

39063                                                       3.90

78125                                                       7.80

Page 278
Remark concerning the sample boot log shown on this page and on page 279:
The 15 first lines (up to dmio.sys) were captured when the system was running XP SP1, while the other lines (from Microsoft (R) Windows 2000 (R)) were captured some years earlier when the system was running Windows 2000.
Page 281
4th line before last replace"MBR" by "boot sector"Page 292

In the KPROCESS description, from XP SP2 and Server 2003 SP1, replace
+0x06b Spare                   : UChar
by
+0x06b Flags                    :_KEXECUTE_OPTIONS
+0x06b ExecuteOptions    :UChar

These flags give information on the DEP status of the Process
Page 295

Figure 6-3 should read "Structure of the kernel process block" instead of "Structure of the executive process block"
Page 318

In the experiment pasted output, replace "Not imersonating" by "Not impersonating" and  replace "kernal32!BaseProcessStart" by "kernel32!BaseProcessStart" as well as "Kernal stack not resident" by "Kernel stack not resident"
Page 323

In figure 6-10, Pviewer from the Support Tools does not provide the thread ID, as mentionned, but only the thread ordinal. It also gives only the thread total processor time not the individual total user time and total privileged time.
On the other hand, Process Explorer (version 11.31), while not mentionned in this figure, indicates the addresses of threads' Ethreads via the handle panel of each process in the "object address" column.
AFAIK, PE does not provide the threads' percentages of CPU time, user time and privileged time as mentionned in this figure.
Page 331

The Table
should be numbered Table 6-14.
In this Table, a check mark is missing to indicate that KD!thread also gives the thread base priority.

Page 339

The Table
number should be changed to Table 6-15
Page 340

It would be useful to insert the following paragraph or similar just before the experiment:
"The above description of the clock interval assumes that the timer resolution is set at its default (i.e. lowest) value. If the timer resolution is increased, as typically is the case with multimedia applications, the clock interrupt rate is increased accordingly (typically it would accelerate from 15.625 ms to 0.9766 ms in the case of an XP multiprocessor system).
However, internally a counter called KiTickOffset is maintained so that the clock interval (called a "tick") used to calculate the quantum value, is always the one corresponding to the lowest resolution (internally known as KeMaximumIncrement, expressed in 100s of nanoseconds) even if the actual clock interval is shorter."
Also, in the experiment, it would be clearer if all occurences of "clock interval" were replaced by "clock tick"; noting that Clockres delivers the system clock tick not the current system clock resolution.

Page 342

The text
for Figure 6-18 should be changed to:

Figure 6-18
Quantum configuration on Windows Server 2003 and Windows XP

Page 344

The Table
number should be changed to Table 6-16.
In the description of the Foreground Quantum Boost field, the kernel variable PsPrioritySeparation is in fact (mis)spelt PsPrioritySeperation in the kernel. The same variable is also quoted on page 351 (3 occurrrences) and on page 353, in each case it should be replaced by PsPrioritySeperation.

Page 348

In the last paragraph, the first line should read:"In five cases,Windows can boost (increase) the base or current priority value of threads"
Edit 2010-01: The line "In five cases, Windows can boost (increase) the current priority value of threads" is correct
Page 349

The Table number should be changed to Table 6-17.
Three lines before the bottom of the page, the sentence could better read:"This cycle continues until the thread's priority level has decayed back to its initial base priority."
Edit 2010-01: The first sentence below the Table, which reads "The boost is always applied to a thread's base priority, not its current priority" should rather read:"The new current priority is derived by adding the boost on top of the thread's base priority".
Page 350
In the paragraph concerning Boosts after waiting for events and semaphores, the sentence "THe boost is always applied to the base priority (not the current priority)" should rather read: "The new current priority is derived by adding the boost on top of the thread's base priority".
In the last paragraph, "priority" means "current priority".

Page 351

Under Priority boosts for foreground thread after waits, the sentence "KiUnwaitThread boosts its current (not base) priority by the current value of PsPrioritySeparation" should rather read:"KiUnwaitThread increases its current priority by adding the value of PsPrioritySeperation on top of its base priority plus any return-from-wait boost"
Page 351-352

The
Cpustres thread priority behaviour shown in the screenshot at step 9 on page
352, i.e. a slow priority boost decay, is specific to Windows 2000.
With XP and Server 2003, the same behaviour is not observed: the priority boost in this case is
suppressed at the end of the quantum  (ref:KiUnwaitThread)

So that on
page 351 below the text describing�priority boost for foreground thread after
waits�, a sentence could be inserted to indicate that at the end of the quantum
in the case of Windows 2000, the thread priority will decay one level, while with
XP or Server 2003 the boost will be removed.

Page 354

Under
Priority boosts for CPU starvation, the text �for approximately 4 seconds�
could be changed to a more precise text �for 300 clock ticks, i.e. 4.6875
seconds for a tick duration of 15.625 ms.�

Page 355

The
experiment �watching priority boosts for CPU starvation� does not work as
described for multi processor systems. In such a case, it is necessary to affect the affinity of the two instances of cpustres.exe and of perfmon4.exe to the
same processor (via Process Explorer or Task Manager).

Page 359

Second
line: �dt nt!_prcb� should be changed to �dt nt!_kprcb�

The Table
number should be changed to Table 6-18

Page 362

Both
occurences of �Table 6-18� should be changed to �Table 6-19�

Page 368

10th line
before last: �nonempty read queue� should be changed to �nonempty ready queue�

Page 369

The Table
number should be changed to Table 6-20

Page 377

In the second paragraph, the sentence "(Memory zeroing in some cases is done.." should start with  "(In Windows Server 2003 and later, memory zeroing in some cases is done..."

Page 426

13th line: �212  = 4096� should be changed to �2¹²
= 4096�

Page 473

The "zero page thread" (i.e. the one first calling nt!Phase1Initialization) may also be identified as the one with TID 8 in the System process when using Process Explorer.
Page 579

"kd> !irp 8a1716f0" is referring to an entry in the IRP list which should have been kept.
After the line:89cb4640 [8a165498] irpStack: ( e, 9) 8a19e208 [ \Driver\AFD]
the following line should be inserted in the !irpfind results 
..8a1716f0 [8a3acbc0] irpStack: ( 3, 0) 8a1eccb8 [ \Driver\Kbdclass]
Page 673

In the experiment "Looking at Shared and Private Cache Maps", 4th line,  "In this example, the file is a Microsoft Outlook data file" should be replaced by "In this example, the file is the help file for Windbg" (the Microsoft Outlook data file was present in the experiment on page 666, not in this one..)
Page 675

A comment on figure 11-13:
AFAIU, CcFastCopyRead and CcCopyRead, when accessing pages that faulted from the disk, read the data into a cache view and copy it to the user buffer, while in the case of read-ahead, CcPerformReadAhead, in the same situation, reads the data only into a cache view. (Here, a reference to the CcCopyRead more detailed description given on page 703 could be useful). 

Edited by dirbase - 21 January 2010 at 9:09pm