none
WebBrowser in a Windows Service stops firing events after some time RRS feed

  • Question

  • Hi.

    I have a Windows service to collect some data from a web site. On certain time basis (every hour, for instance) it creates a new AppDomain for retrieval task, then starts STA thread where it creates a WebBrowser control, subscribes to its events, navigates to initial page and runs message loop with Application.Run() for event processing. Also it creates a timer to stop message loop in case of timeout. When all processing is done, message loop is stopped (from DocumentCompleted event handler with Application.Exit() call), and AppDomain is unloaded.

    This runs fine for some time (WebBrowser fires Navigating event, then Navigated, then DocumentCompleted etc.), but on some iteration it just stops working: Navigating event is fired once for initial Navigate() call, but Navigated and DocumentCompleted are never fired anymore until service process is restarted, and processing just aborts on timeout.

    I'm running on Windows Server 2008 with IE9. Any ideas?


    Tuesday, March 19, 2013 10:22 AM

Answers

  • Joel, I'm running in a windows service, so I just cannot start it in Visual Studio. But having debugger attached doesn't matter: no exceptions are produced at all. All the processing is done in a separate AppDomain, and in a single STA thread spawned by a service. There's no point in my code where a race condition can occur.

    Anyway, I've ended up with a separate worker process started from a service, with redirected pipes. I'm using StdErr for logging purposes, StdIn to pass input data, and StdOut to get output from a worker process. This seems to works rock-solid for a whole day already.

    • Marked as answer by Alex Skalozub Wednesday, April 3, 2013 3:34 AM
    Thursday, March 21, 2013 6:11 PM

All replies

  • I normally use wire shark to determine if there is any networking issues and to isolate the problems.  With wireshark you can get all the HTTP error messages and the low level TCP ACK/NACK, retries, and close messages to determine exaclty where the problem is occuring.  Right now I can't tell if the problem is in your code or something occuring on the server end of the connecton.

    jdweng

    Tuesday, March 19, 2013 11:22 AM
  • Hi Alex,

    I would like to suggest you do not use windows control in a windows service, try httpwebrequest: http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.aspx  and 

    http://msdn.microsoft.com/en-us/library/system.net.httpwebresponse.aspx  

    And for more about these class, you can try this forum: http://social.msdn.microsoft.com/Forums/en-US/wcf 

    Thank you.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, March 20, 2013 2:25 PM
    Moderator
  • Joel, thanks for your suggestion. But that would be too obvious – unfortunately it is not a network issue. I've tried to use Wireshark, and when the problem occurs, WebBrowser doesn't bother sending any network packets to that destination anymore.

    Mike, I'm well aware that WinInet is not designed for services, but I simply have no choice. The site I'm accessing heavily uses JavaScript and AJAX to gather and build contents, so HttpWebRequest is no use here.

    I've also tried to use Awesomium.NET, but it silently crashes on initialization when running from a service (running from console app is fine though).

    I'm afraid I'm running out of options :( The only thing left is to run a separate process solely for site access, but it would require me to make all service features (logging, task management etc.) available for out-of-process usage.

    Wednesday, March 20, 2013 8:08 PM
  • A webbrowser won't send data if the connection has been closed.  You are too quickly deciding the problem is coming from you application (or inside the pc) before you have fully eliminated the possiblilty that the problem may be on the network end.  I would check the connection status by using Netstat -a.  I would also verify that no TCP close message was sent (by either side of the connection) and verify that all TCP packets had ACK (no NACK or retries).  Also check the Datagrams of the HTTP to make sure there are no error messages.

    jdweng

    Wednesday, March 20, 2013 9:33 PM
  • The network end is fine – I'm able to access it from browser. And though it is HTTPS, I can see that after failure there are no new packets at all matching server address and port.

    Also if it happended just sometimes, I'd think it is a network problem. But it never happens before "iteration X" (when it stops working), and happens every time afterwards.

    I've rewritten my code a bit, removing all Application.DoEvents() calls. Now it was running without issues for 4 hours, but now it failed again.

    I think the problem is somewhere inside IE libraries. Unlike assemblies, native dlls are loaded per process, not per AppDomain, so I suppose running in different threads may corrupt some internal state, which is not restored after AppDomain load/unload. The only solid solution I see now is running a separate process.

    Wednesday, March 20, 2013 11:51 PM
  • I don't think creating a different thread is going to reolve the problem and make it more difficult to communicate between the threads.  I would go back and look and the last set of changes you made to see if any of the changes would cause a lock-up of the code.  It is more likely that you have a race condition in your code.  I still think the comm data from wireshark will lead to the solution.  Finding out under what conditions the problem occurs wil isoltate where in the code the problem is occuring.

    Does the problem happen both when you run your application in VS and when you run it in stand alone mode?  If it happens in VS simply use the menu Break All to find where the code has stopped.

    Are you using Sync Reads or Sync Reads?


    jdweng

    Thursday, March 21, 2013 9:24 AM
  • Joel, I'm running in a windows service, so I just cannot start it in Visual Studio. But having debugger attached doesn't matter: no exceptions are produced at all. All the processing is done in a separate AppDomain, and in a single STA thread spawned by a service. There's no point in my code where a race condition can occur.

    Anyway, I've ended up with a separate worker process started from a service, with redirected pipes. I'm using StdErr for logging purposes, StdIn to pass input data, and StdOut to get output from a worker process. This seems to works rock-solid for a whole day already.

    • Marked as answer by Alex Skalozub Wednesday, April 3, 2013 3:34 AM
    Thursday, March 21, 2013 6:11 PM