The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".
The following errata were submitted by our customers and approved as valid errors by the author or editor.
| Version |
Location |
Description |
Submitted By |
Date Submitted |
Date Corrected |
| Printed |
Page intro xxv
#5 at bottom |
"5. Then Install the components to the C:\DDK\7600.16385.1 directory, as shown in the following screenshot..."
The default install directory path for WDK 7.1 (installed on W2K8R2SP1) is C:\WinDDK\7600.16835.1; would this not have worked?
Note from the Author or Editor:
The default WinDDK (as opposed to DDK) picked by the WDK also works. |
matt grossman |
May 24, 2012 |
|
| PDF |
Page xxvi
8th element of numbered list |
When building the Code Samples via the macro "bcz", it's important to use the same command prompt window already opened in the 7th step for setting the environment via "setenv.bat".
Otherwise "bcz" (a macro, not a command) will not work.
Note from the Author or Editor:
Good point. |
Stefano Capelli |
Sep 10, 2012 |
|
| Printed |
Page Introduction
5. |
Then Install the components to the C:\ DDK\ 7600.16835.1 directory, as shown in the following screen shot. This step will take several minutes to complete.
Soulami, Tarik (2012-05-07). Inside Windows® Debugging: A Practical Guide to Debugging and Tracing Strategies in Windows® (Kindle Locations 614-615). OReilly Media - A. Kindle Edition.
The path should be ...\7600.16385.1
|
Keith Chalmers |
Oct 22, 2012 |
May 17, 2013 |
| PDF |
Page xxix
11 pages duplicated |
Introduction (xvii - xxviii) is duplicated on xxix - xl.
Note from the Author or Editor:
An earlier version of the PDF had this mistake. It was corrected before the print version went out. Apologies about the inconvenience. |
joehtg |
Mar 03, 2013 |
Apr 26, 2012 |
| Printed, PDF, Safari Books Online, Other Digital Version |
Page 7
Service Packs paragraph |
On page 7 you write hat Vista had 3 service packs. But Vista / Server 2008 only have 2 service packs. The SP2 was released in 2009 and the mainstream support ended 2012 so there will be no Sp3. Windows XP had three Service packs.
Note from the Author or Editor:
Correct. Windows Vista had only two service packs. It's Windows XP that had three. |
André Ziegler |
Jun 04, 2012 |
May 17, 2013 |
| Printed, PDF, Safari Books Online, Other Digital Version |
Page 47
First listing |
When using the x86 version of windbg.exe and notepad.exe on an x64 host Windows OS, the call stack displayed by the k command stops at ntdll!KiUserCallbackDispatcher. Reason: the x86 version of the debugger doesn't handle the WOW64 call frame in this case, so it fails to decode the rest of the call stack.
To work-around this issue when running on x64 Windows, use the x64 windbg.exe debugger. It will work with either c:\windows\system32\notepad.exe or c:\windows\syswow64\notepad.exe
*Note* this only happens if you're running the experiment on an x64 host Windows.
|
Tarik Soulami
 |
May 25, 2012 |
|
| Printed, PDF, Safari Books Online, Other Digital Version |
Page 62
Near the end of the page |
The note states that enabling kernel debugging through the boot menu results in hard-coded COM connection settings being used by the system. It then goes on to indicate that 19,200 bauds and the highest enumerated COM port are used by default. In Windows Vista and later, the defaults are now instead COM1 and 115,200.
|
Tarik Soulami
|
Jun 25, 2012 |
May 17, 2013 |
| Printed, PDF, Safari Books Online, Other Digital Version |
Page 107
Code sample, line 11 |
The code refers to Console.ReadLine("Exiting..."). This is obviously a typo for Console.WriteLine.
Note from the Author or Editor:
Confirmed this is a typo: ReadLine should be WriteLine in line 11 of the listing.
The C# file from the companion source code is correct in this case. |
Ben Monroe |
May 26, 2012 |
May 17, 2013 |
| Printed |
Page 220
code listing |
In the code listing at the bottom of the page, "g_fAttached = false;" should be "g_bAttached = false;". The downloaded code sample is correct.
Note from the Author or Editor:
Confirmed. Good catch! |
Andy Dittrich |
Apr 07, 2013 |
May 17, 2013 |
| Printed, PDF, Safari Books Online, Other Digital Version |
Page 389
Table of contents |
Chapter 13 Common Tracking Scenarios
should be:
Chapter 13 Common Tracing Scenarios
|
Tarik Soulami
|
May 25, 2012 |
May 17, 2013 |
| Printed, PDF, Safari Books Online, Other Digital Version |
Page 438
1st paragraph |
On page 438 you wrote that the xperf.exe symbols are not on the symbol server and the callstack always shows xperf.exe!?
But this is not true. xperf symbols are on the symbol server (I've tested this with xperf 4.6, 4.8, 6.2.8102, 6.2.8250 and 6.2.8400)
Here is a picture of ProcExp configured with the public Symbol server:
http://dl.dropbox.com/u/5749744/Bilder/xperf/xperf_symbols.png
|
André Ziegler |
Jun 04, 2012 |
May 17, 2013 |
