title: WatiN hangs on "about:blank" for multiple concurrent IE8 instances
body: <p>I’m trying to test several web sites using the latest version of WatiN.</p>
  
  <p>If a try to run several tests simultaneously, WatiN will eventually throw an exception “<strong>Timeout while Internet Explorer busy</strong>”. This occurs because Internet Explorer eventually gets “stuck” trying to connect to “<strong>about:blank</strong>”.</p>
  
  <p>Runtime environment:</p>
  
  <ul>
  <li>Windows 7 Professional</li>
  <li>Internet Explorer 8 (Version 8.0.7600.16385)</li>
  <li>WatiN (Version 2.1.0.1196)</li>
  </ul>
  
  <p>I have distilled the problem to the following bare-bones c# console program. To recreate the problem, create a new c# .NET 3.5 console program from Visual Studio, add a reference to WatiN.Core.dll, compile, then run. After about 10 seconds on my machine, IE hangs on "about:blank", and eventually WatiN times out and generates an exception.</p>
  
  <p>Increasing the WatiN timeouts only delays the problem.</p>
  
  <p>Has anyone else seen this problem? Can you reproduce the problem using my example program? Any solutions?</p>
  
  <p><strong>[Code]</strong></p>
  
  <pre><code>namespace IEBugUsingWatiN
  {
      using System;
      using System.Collections.Generic;
      using System.Threading;
      using WatiN.Core;
  
      class Program
      {
          const int MAX_THREADS = 7;
          volatile static bool _stopAll = false;
  
          static void Main( string[] args )
          {
              Console.WriteLine( "Initializing WatiN." );
  
              var watinSettings = WatiN.Core.Settings.Instance;
  
              watinSettings.AutoCloseDialogs = false;
              watinSettings.AutoMoveMousePointerToTopLeft = false;
              watinSettings.AutoStartDialogWatcher = false;
              watinSettings.HighLightElement = false;
              watinSettings.SleepTime = 200;
              watinSettings.WaitUntilExistsTimeOut = 15;
  
              Console.WriteLine( "Creating threads." );
  
              List&lt;Thread&gt; threads = new List&lt;Thread&gt;();
  
              for ( int numThreads = 0 ; numThreads &lt; MAX_THREADS ; ++numThreads )
              {
                  var thread = new Thread( ThreadFunc );
                  thread.IsBackground = true;
                  thread.SetApartmentState( ApartmentState.STA );
                  thread.Start();
                  threads.Add( thread );
              }
  
              Console.WriteLine( "Press Enter key to end tests..." );
              Console.ReadLine();
  
              _stopAll = true;
  
              Console.WriteLine( "Waiting for all threads to end..." );
  
              foreach ( var thread in threads )
              {
                  thread.Join();
              }
  
              Console.WriteLine( "Done." );
          }
  
          static void ThreadFunc()
          {
              while ( !_stopAll )
              {
                  WatiN.Core.IE ie = null;
  
                  try
                  {
                      ie = new WatiN.Core.IE();
                      ie.GoTo( "http://www.hertz.com" );
                  }
                  catch ( System.Exception ex )
                  {
                      _stopAll = true;
                      Console.WriteLine( "EXCEPTION: {0}", ex.Message );
                  }
  
                  if ( null != ie )
                  {
                      ie.Close();
                      ie = null;
                  }
  
                  Thread.Sleep( TimeSpan.FromSeconds( 1 ) );
              }
          }
      }
  }
  </code></pre>
  
  <p><strong>[Update]</strong></p>
  
  <p>Microsoft has confirmed that this is a known bug. To make a long story short, IE (specifically, <strong>wininet.dll</strong>) leaks connections under certain circumstances. The only suggested workaround is to explicitly kill all Internet Explorer process instances after running a Test. A "fix" is not likely since this has been an issue for YEARS, and they are afraid of breaking compatibility with existing applications.</p>
  
  <p>FYI, here is what Microsoft has to say:</p>
  
  <blockquote>
    <p>The best workaround would probably to
    kill and restart IE at some interval
    during your test run automation.  You
    can restart IE at some regular
    interval or have some kind of
    detection logic in your code.  When
    you get into this situation IE won’t
    be able to make any request out so I
    would expect the application to
    receive a <strong>BeforeNavigate</strong> event (if
    you sink this event) set up a timer
    and by the time the timer fires check
    to see if you ever get a
    <strong>DocumentComplete</strong> event for the URL (which you probably won’t).  This is a
    good indication that you run into the
    problem so you can proceed to kill and
    restart the IE process at this point.</p>
    
    <p>...this approach is not addressing the
    root cause of wininet connection loss
    but at the same time there aren’t any
    practical approach within your control
    to do this.  Just to provide some
    perspective on how you get into this
    situation…</p>
    
    <p>Whenever there are ActiveX components
    (such as msxml making an AJAX request)
    making an HTTP request and the Tab
    window hosting that component is
    closed before the response is
    received, there is a chance IE will
    lose that wininet connection if the
    ActiveX does not abort the call.  This
    is exactly what happened in the hertz
    scenario.  The page has script running
    to issue an AJAX request.  IE window
    is then closed before the response
    comes back.  Upon part of tearing down
    the page, IE calls into the ActiveX
    (MSXML in this case) to notify the
    control upon shutting down.  The
    control can then abort that connection
    upon being destroyed.  MSXML does not
    abort the connection here leading to
    the leak.  The issue is deeply rooted
    in IE’s design architecture and how it
    interacts with 3rd party components. 
    Because of this you will most likely
    encounter this issue on web sites that
    have AJAX requests.  Over the years
    there are multiple bugs opened against
    this issue but all those bugs were
    rejected due to high application
    compat risk.  Part of the difficulty
    in providing a fix is that IE does not
    always know that the ActiveX is the
    one making a connection.</p>
    
    <p>Wininet does not expose any mechanism
    for a 3rd party control to reset or
    clean up the wininet connection loss. 
    By default IE6/7 has 2 connections per
    server while IE8 has 6 so this
    behavior is probably less visible in
    IE8.  There is a registry key
    documented here
    <a href="http://support.microsoft.com/kb/183110" rel="nofollow">http://support.microsoft.com/kb/183110</a>
    you can try to increase the number of
    available connections.  However this
    is only delaying the problem.  This is
    why I mentioned the only supportable
    way to reset the wininet state is to
    restart the IE process.</p>
  </blockquote>