<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: GDB for WinDbg Users (Part 4)</title>
	<link>https://www.dumpanalysis.org/blog/index.php/2007/07/01/gdb-for-windbg-users-part-4/</link>
	<description>Structural and Behavioral Patterns for Software Diagnostics, Forensics and Prognostics</description>
	<pubDate>Wed, 06 May 2026 03:27:48 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>By: Jonathan Aquino</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/07/01/gdb-for-windbg-users-part-4/#comment-2881</link>
		<dc:creator>Jonathan Aquino</dc:creator>
		<pubDate>Sun, 08 Jul 2007 20:17:04 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/07/01/gdb-for-windbg-users-part-4/#comment-2881</guid>
		<description>Cool stuff - thanks. I'll check out both books.

I've got "Debugging: The Nine Indispensable Rules" on order. From reading some excerpts, looks like it's an entertaining read.</description>
		<content:encoded><![CDATA[<p>Cool stuff - thanks. I&#8217;ll check out both books.</p>
<p>I&#8217;ve got &#8220;Debugging: The Nine Indispensable Rules&#8221; on order. From reading some excerpts, looks like it&#8217;s an entertaining read.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/07/01/gdb-for-windbg-users-part-4/#comment-2874</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Sun, 08 Jul 2007 15:29:00 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/07/01/gdb-for-windbg-users-part-4/#comment-2874</guid>
		<description>I'm not reading it at the moment, I plan to do it when I finish reading the second one (Why Programs Fail) and the latter is very good to understand what debugging is all about even for people with decades of programming. Basically it gives practical debugging skills coherent and solid systematical foundation.  
However I browsed Debugging by Thinking book and I canâ€™t say that it is true that programming examples are for beginners only. Most of them involve pointers, linked lists, binary trees, heaps, etc. There is good information in the book about relation of debugging to other disciplines like logic, psychology, mathematics, root cause analysis, etc. Debugging can be applied in a broader scope, for example, when troubleshooting issues in technical support environment. In the company I work for, Citrix, technical support and escalation engineers do debugging in a broader sense because debugging starts at the system level with problem isolation, involves root cause analysis, etc. Andreas Zeller describes his TRAFFIC steps: Track, Reproduce, Automate, Find origins, Focus, Isolate and Correct. On a system level some problems can be corrected by upgrading or removing components without looking at source code. Crash dump analysis and/or traces can help here. After working in such environment I can say that thinking about debugging as a process to correct defects in code is too narrow. 
Anyway when I read DBT book I would be able to say more whether it is worth reading it.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not reading it at the moment, I plan to do it when I finish reading the second one (Why Programs Fail) and the latter is very good to understand what debugging is all about even for people with decades of programming. Basically it gives practical debugging skills coherent and solid systematical foundation.<br />
However I browsed Debugging by Thinking book and I canâ€™t say that it is true that programming examples are for beginners only. Most of them involve pointers, linked lists, binary trees, heaps, etc. There is good information in the book about relation of debugging to other disciplines like logic, psychology, mathematics, root cause analysis, etc. Debugging can be applied in a broader scope, for example, when troubleshooting issues in technical support environment. In the company I work for, Citrix, technical support and escalation engineers do debugging in a broader sense because debugging starts at the system level with problem isolation, involves root cause analysis, etc. Andreas Zeller describes his TRAFFIC steps: Track, Reproduce, Automate, Find origins, Focus, Isolate and Correct. On a system level some problems can be corrected by upgrading or removing components without looking at source code. Crash dump analysis and/or traces can help here. After working in such environment I can say that thinking about debugging as a process to correct defects in code is too narrow.<br />
Anyway when I read DBT book I would be able to say more whether it is worth reading it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Aquino</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/07/01/gdb-for-windbg-users-part-4/#comment-2869</link>
		<dc:creator>Jonathan Aquino</dc:creator>
		<pubDate>Sun, 08 Jul 2007 05:28:32 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/07/01/gdb-for-windbg-users-part-4/#comment-2869</guid>
		<description>DBT looks like a big book - is it worth the time to read it? I read some Amazon reviews saying that it's geared toward beginners. But it is pretty hefty (500 pages or so). 

Worth reading for people who have been programming for a decade?</description>
		<content:encoded><![CDATA[<p>DBT looks like a big book - is it worth the time to read it? I read some Amazon reviews saying that it&#8217;s geared toward beginners. But it is pretty hefty (500 pages or so). </p>
<p>Worth reading for people who have been programming for a decade?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
