A number of poorly written IE BHO's crash IE if ChromeFrame is the currently ...

chrome_frame/bho.cc

Index: chrome_frame/bho.cc
===================================================================
--- chrome_frame/bho.cc	(revision 74374)
+++ chrome_frame/bho.cc	(working copy)
@@ -11,8 +11,9 @@
 #include "base/path_service.h"
 #include "base/string_util.h"
 #include "base/stringprintf.h"
+#include "base/threading/platform_thread.h"
 #include "base/win/scoped_bstr.h"
-#include "chrome_tab.h" // NOLINT
+#include "chrome_frame/buggy_bho_handling.h"
 #include "chrome_frame/crash_reporting/crash_metrics.h"
 #include "chrome_frame/extra_system_apis.h"
 #include "chrome_frame/html_utils.h"
@@ -23,6 +24,7 @@
 #include "chrome_frame/urlmon_moniker.h"
 #include "chrome_frame/utils.h"
 #include "chrome_frame/vtable_patch_manager.h"
+#include "chrome_tab.h"  // NOLINT
 
 static const int kIBrowserServiceOnHttpEquivIndex = 30;
 
@@ -134,10 +136,12 @@
     // our active document/activex instances to query referrer and other
     // information for a URL.
     AddRef();
-    RegisterThreadInstance();
+    RegisterThreadInstance(web_browser2);

[tommi (sloooow) - chröme, 2011/02/11 14:49:02]

Maybe instead of registering a pointer to IWebBrowser2, we should store a vector
of Bho's?  The Bho already has a pointer to the web browser via the site.

     MetricsService::Start();
   } else {
     UnregisterThreadInstance();

[tommi (sloooow) - chröme, 2011/02/11 14:49:02]

Hmm... there's no matching DispEventUnadvise to the DispEventAdvise above...  Is
our Bho ever fully released?

[ananta, 2011/02/11 18:55:07]

Nice catch. Fixed.

+    buggy_bho::BuggyBhoHandler::ClearBuggyObjectsForThread(
+        base::PlatformThread::CurrentId());
     Release();
   }