Errata

Errata for Inside Windows Debugging

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.

Color key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

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
PDF	Page xxix several pages.	Page xxix 11 pages still duplicated, despite the message that this is fixed (in the errata list) ! Note from the Author or Editor: Thanks for bringing this up, and apologies about the inconvenience. This is now fixed in the online PDF.	Hans De Smaele	Jun 02, 2013
Printed, PDF, , 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, , 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, , 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, , 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, PDF, ePub	Page 198 4th line of the last paragraph	Missing 0 in hexadecimal value: E_ACCESSDENIED value (0x8007005)... should be E_ACCESSDENIED value (0x80070005)	Tarik Soulami	Jul 01, 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, , 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	Page 409 2nd paragraph	The text of the secnod sentence reads "was spent inside a function called COMCTL32!EditML_BuildcchLines." The function is actually named EditML_BuildchLines (only one 'c') as can be seen in FIGURE 11-17 Note from the Author or Editor: Good catch! The function name should only have one 'c'.	Roger Orr	Jul 24, 2013
Printed, PDF, , 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