<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Balint&#039;s Blog &#187; microsoft visual studio 2005 crash debug code window</title>
	<atom:link href="http://blog.spench.net/tag/microsoft-visual-studio-2005-crash-debug-code-window/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.spench.net</link>
	<description>balint at spench fullstop-decimalpoint-dot net</description>
	<lastBuildDate>Sun, 20 Jul 2025 18:53:20 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Microsoft Visual Studio 2005 crashes when typing into a code window while debugging</title>
		<link>http://blog.spench.net/2009/07/16/microsoft-visual-studio-2005-crashes-when-typing-into-a-code-window-while-debugging/</link>
		<comments>http://blog.spench.net/2009/07/16/microsoft-visual-studio-2005-crashes-when-typing-into-a-code-window-while-debugging/#comments</comments>
		<pubDate>Wed, 15 Jul 2009 13:04:18 +0000</pubDate>
		<dc:creator>balint</dc:creator>
				<category><![CDATA[Tips & Tricks]]></category>
		<category><![CDATA[microsoft visual studio 2005 crash debug code window]]></category>

		<guid isPermaLink="false">http://blog.spench.net/2009/07/16/microsoft-visual-studio-2005-crashes-when-typing-into-a-code-window-while-debugging/</guid>
		<description><![CDATA[When debugging my VC++ projects, I routinely make use of &#8216;Edit &#038; Continue&#8217; by modifying code in the Visual Studio environment while stepping through the compiled code. Recently I found that typing into a code window would cause Visual Studio to become unresponsive for a long period. Checking Task Manager, I found that WerFault had [...]]]></description>
			<content:encoded><![CDATA[<p>When debugging my VC++ projects, I routinely make use of &#8216;Edit &#038; Continue&#8217; by modifying code in the Visual Studio environment while stepping through the compiled code. Recently I found that typing into a code window would cause Visual Studio to become unresponsive for a long period. Checking Task Manager, I found that WerFault had kicked in and was generating a minidump for DevEnv.exe &#8211; Visual Studio was clearly not happy. The unusual thing was that Visual Studio would not immediately terminate after the minidump finished. Instead, it would continue running. However, if I would now close the debugee (my own application), attempt to continue execution with modified source code (which would activate Edit &#038; Continue), or manually stop the debugger, Visual Studio would crash.</p>
<p>After a very thorough search (looking at Visual Studio&#8217;s stack trace using symbols from the Microsoft Symbol Store, seeing exceptions thrown from HeapFree and IDebugEncLineMap, un-installing various plugins such as AnkhSVN, and duplicating the tests on another machine), I could not identify the cause. Thinking about any configuration changes I had made in the last months, I tried removing the all additional Include &#038; Library paths I had ever added to the VC++ directory options. These can be found (on Vista) in:</p>
<p><code>C:\Users\User Name\AppData\Local\Microsoft\Visual Studio\8.0\VCComponents.dat</code></p>
<p>Voila! No more crashes! As it turned out, I had added so many extra Include/Library directories (each with a long path) that some portion of the debugger would crash when reproducing the steps described above. Perhaps this is a buffer overflow? I had a look through the patch listing on Microsoft Connect, but found nothing matching this problem.</p>
<p>Now, I wanted to have my cake and eat it too: I resolved this issue, while keeping all of my configured Include/Library directories, by creating a hard-link (or NTFS reparse point) to the base of my SDK directory (under which all of the Include/Library directories reside) further up the directory chain, in effect shortening the path lengths.</p>
<p>For example, here are two Include directories:<br />
<code>C:\Documents and Settings\User Name\My Documents\Visual Studio 2005\Projects\_SDK\Some Code\include<br />
C:\Documents and Settings\User Name\My Documents\Visual Studio 2005\Projects\_SDK\Other Code\include</code></p>
<p>Lots of these will crash Visual Studio.<br />
They both share the parent: <code>C:\Documents and Settings\User Name\My Documents\Visual Studio 2005\Projects\_SDK</code></p>
<p>So create a reparse point at: <code>C:\Dev\SDK</code> And make it point to the parent above.</p>
<p>So now in Visual Studio, you can change the original Include directories to:<br />
<code>C:\Dev\SDK\Some Code\include<br />
C:\Dev\SDK\Other Code\include</code></p>
<p>In total, they are of a much shorter length and fall under the mysterious buffer limit, thereby avoiding the dreaded crash scenario.</p>
<p>NTFS soft/hard-links can be made using the command-line tools at the bottom of <a href="http://www.flexhex.com/docs/articles/hard-links.phtml">this</a> handy page.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.spench.net/2009/07/16/microsoft-visual-studio-2005-crashes-when-typing-into-a-code-window-while-debugging/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
