Databases
StackOverflow2013
Postsdbo
POWatiN hangs on "about:blank" for multiple concurrent IE8 instances
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWatiN hangs on "about:blank" for multiple concurrent IE8 instances
    primarykey
    data
    text
    <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>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USahazzah
    1. USahazzah
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. POWatiN hangs on "about:blank" for multiple concurrent IE8 instances
      1. USPalaSataJa
      1. VTFavorite
    2. VO
      singulars
      1. POWatiN hangs on "about:blank" for multiple concurrent IE8 instances
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POWatiN hangs on "about:blank" for multiple concurrent IE8 instances
      1. This table or related slice is empty.
      1. VTUpMod
    1. COSame problem occurs using IE9.
      singulars
      1. POWatiN hangs on "about:blank" for multiple concurrent IE8 instances
      1. USahazzah
    2. COAlthough this didn't solve my issue it certainly saved me a lot of time trying to find out what was going on.
      singulars
      1. POWatiN hangs on "about:blank" for multiple concurrent IE8 instances
      1. USGrubsnik
    3. COGlad I saved you some time.
      singulars
      1. POWatiN hangs on "about:blank" for multiple concurrent IE8 instances
      1. USahazzah
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload