<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" media="screen" href="/styles/xslt/rss.xslt"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:c9="http://channel9.msdn.com">
<channel>
	<title>Comment Feed for Channel 9 - Visual Studio Debugger Tips &amp; Tricks</title>
	<atom:link rel="self" type="application/rss+xml" href="http://channel9.msdn.com/Blogs/pdc2008/TL59/RSS"></atom:link>
	<image>
		<url>http://ecn.channel9.msdn.com/o9/previewImages/100/432385_100x75.jpg</url>
		<title>Channel 9 - Visual Studio Debugger Tips &amp; Tricks</title>
		<link></link>
	</image>
	<description>The Visual Studio Debugger provides a slew of features that make the task of debugging both easier and more efficient. Learn about time-saving tips and tricks for all versions of the Visual Studio Debugger, including the new debugger features in Visual
 Studio 2010. Hear about the new mixed-mode debugging feature, the breakpoints window enhancements, the new WPF visualizers, and a number of other features. Also learn about thread debugging enhancements, new features for making stepping into properties easier,
 and more. Join us as we crack open the toolbox and walk through some of the debugger&#39;s best practices.


John Cunningham
John has been in the business of debuggers and diagnostic tools for around 15 years. He cut his teeth on debuggers for Windows 16 and 32bit, SunOS and Solaris. After a brief stint doing embedded debuggers at Wind River Systems, John
 joined Microsoft during the Visual Studio .Net product cycle. He has worked as a developer and lead on native and managed debuggers. John was part of the TeamSystem team from Day -30, working on the VS profiler and code coverage. Since then John has worked
 on starting the project for the application flight recorder as well as continuing to develop debugging and profiling technologies. John dreams in CodeView records. There is no cure.

</description>
	<link></link>
	<language>en</language>
	<pubDate>Wed, 22 May 2013 16:13:02 GMT</pubDate>
	<lastBuildDate>Wed, 22 May 2013 16:13:02 GMT</lastBuildDate>
	<generator>Rev9</generator>
	<item>
		<title>Re: Visual Studio Debugger Tips &amp; Tricks</title>
		<description>
			<![CDATA[Data breakpoints is something I definitely miss.&nbsp; Where you have properties in your own code it is easy enough to set a breakpoint in a setter.&nbsp; But where the code isn't your own (think slot in an array or entry in a&nbsp;List&lt;T&gt;), it sure would be nice to
 be able to set a breakpoint on write.<p>posted by hillr</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/pdc2008/TL59#c633611841790000000</link>
		<pubDate>Sun, 02 Nov 2008 00:56:19 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/pdc2008/TL59#c633611841790000000</guid>
		<dc:creator>hillr</dc:creator>
	</item>
	<item>
		<title>Re: Visual Studio Debugger Tips &amp; Tricks</title>
		<description>
			<![CDATA[I hear you.&nbsp; I've wanted to build since V1 of the CLR.&nbsp; We actually put a lot of effort into trying to build that feature for VS2010, but alas we couldn't come up with a good way to make it work.&nbsp; Fundamentally, we are constrained by what the hardware
 will give us here (4 slots in the DR registers) to watch memory writes (and technically reads and executes).&nbsp; Every time we tried to figure out &quot;how would we provide an experience that people wouldn't find just weird&quot;, we came up short.&nbsp;
<br>
<br>
You can use a conditional breakpoint and use an expression with &quot;has changed&quot;, but it is not nearly as performant as a databp, and it is not the same thing (the DRs fire no matter if you are writing the same value back).<br>
<br>
Anyway - hope you enjoyed the talk,<br>
<br>
John<p>posted by JoC</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/pdc2008/TL59#c633616972720000000</link>
		<pubDate>Fri, 07 Nov 2008 23:27:52 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/pdc2008/TL59#c633616972720000000</guid>
		<dc:creator>JoC</dc:creator>
	</item>
	<item>
		<title>Re: Visual Studio Debugger Tips &amp; Tricks</title>
		<description>
			<![CDATA[John,<br>
&nbsp; I enjoyed the talk, but I also wished you'd been able to get it in. I'm a native programmer switching to .Net.<br>
<br>
&nbsp; I'm not sure why they'd be any more 'weird' in .Net than they are under Native.<br>
<br>
&nbsp; As a games programmer, I've had several problems that I've had to troubleshoot in release mode because it takes too long to run things in debug mode.&nbsp;I assume that for .Net, I'd have to attach to the process after it starts to avoid running a debug build.
 I assume that a release build would inline the accessor, to the only&nbsp;optins available are hardware breakpoints and&nbsp;print statements <img src='http://ecn.channel9.msdn.com/o9/content/images/emoticons/emotion-6.gif' alt='Sad' /><br>
<br>
&nbsp; I've found them fantastically useful in debugging things like buffer overruns in native code. Even though that class of bugs isn't supposed to be there, I suspect that there is a new class of bugs related to multi-threading that are coming at us. Data breakpoints
 seem like an obvious way (to me) to troubleshoot these types of issues.<br>
<br>
Ralph<br>
<p>posted by Ralph Trickey</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/pdc2008/TL59#c633642863220000000</link>
		<pubDate>Sun, 07 Dec 2008 22:38:42 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/pdc2008/TL59#c633642863220000000</guid>
		<dc:creator>Ralph Trickey</dc:creator>
	</item>
	<item>
		<title>Re: Visual Studio Debugger Tips &amp; Tricks</title>
		<description>
			<![CDATA[This certainly won't work for all instances but for a List you could instead use the System.Collection.ObjectModel.Collection&lt;T&gt;.&nbsp; This has events you can subscribe to when you add and remove items to the collection and it would provide you what you were
 looking for in this particular instance.<br>
<p>posted by sbehnke</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/pdc2008/TL59#c633651493330000000</link>
		<pubDate>Wed, 17 Dec 2008 22:22:13 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/pdc2008/TL59#c633651493330000000</guid>
		<dc:creator>sbehnke</dc:creator>
	</item>
	<item>
		<title>Re: Visual Studio Debugger Tips &amp; Tricks</title>
		<description>
			<![CDATA[
<p>Thanks, nice lecture!</p>
<p>Also i would like to share an Add-in for visual studio that makes it easy to attaching to process&nbsp;<a href="http://lazy.codeplex.com/">lazy.codeplex.com/</a></p>
<p>posted by pablog</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/pdc2008/TL59#c634000925160000000</link>
		<pubDate>Tue, 26 Jan 2010 08:48:36 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/pdc2008/TL59#c634000925160000000</guid>
		<dc:creator>pablog</dc:creator>
	</item>
	<item>
		<title>Re: Visual Studio Debugger Tips &amp; Tricks</title>
		<description>
			<![CDATA[
<p>Nice tips let me just share that for debugger security you must be able to trust what you are debbugin, I think this is the most careful step for debuggin, there are many trheats and consequences involved. As Ralph tricky mentionede it takes too long to
 run things in debug mode</p>
<p>&nbsp;</p>
<p>posted by Rebeasty</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/pdc2008/TL59#c634118861530000000</link>
		<pubDate>Fri, 11 Jun 2010 20:49:13 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/pdc2008/TL59#c634118861530000000</guid>
		<dc:creator>Rebeasty</dc:creator>
	</item>
</channel>
</rss>