Internet Explorer Browser process crash during start of Agent Desktop RRS feed

  • Question

  • Hello all,

    I'm facing a strange problem with Agent Desktop. Every now and then the browser process of my Hosted Web Applications in Agent Desktop crashes. "An unhandled win32 exception occured in iexplore.exe" is the only error message i get.

    This happens irregular and is not reproducable - about 1 out of 10 tries leads to a browser crash. In most cases this happens during the start of Agent Desktop making it unusable (rarely when the Agent Desktop is running). In this case the Hosted Applications are greyed out and no web page is displayed. Agent Desktop must be restarted to fix it. Sometimes this problem occurs 3 times in a row, so that you only get a working Agent Desktop on the 4th start. The problem occurs on different machines (Windows Server 2003 as well as on Windows XP).

    Within my Agent Desktop there are 2 Hosted Web Applications with a Web Application Adapter assembly for each Hosted App. The assemblies "just" generate Urls and load the page in Agent Desktop (Browser.Navigate()).

    Here is a screenshot, how it looks like, when the browser process crashes.

    The screenshot is taken on a machine, where Visual Studio is installed (it offers me a JIT debugger). On a machine, where no Visual Studio is installed it looks a little bit different.

    Has anyone experience this kind of problem?

    With kind regards,
    Wednesday, July 29, 2009 6:29 AM

All replies

  • What Version if IE,  what Version of CCF?

    Matt B.
    Friday, July 31, 2009 4:47 PM
  • Hallo Matt,

    IE 7, CCF 2009 (no SP1).

    With kind regards,
    Sunday, August 2, 2009 4:18 PM
  • Hello Ronny
    We had a similar problem.
    It sounds like a timing issue. You are trying to automate IE while its busy loading. 
    How do you Navigate to the URL in your Web Adapter?

    Tuesday, August 4, 2009 10:41 AM
  • Hello Craig,

    that is also my guess: some kind of timing issue:

    I have developed a Web Application adapter assembly (derived from class WebApplicationAdapter) for integrating/automating a Microsoft Dynamics CRM 4.0 page into AgentDesktop. We have implemented a multi-tenancy capability into our CCF solution, which means that each user gets a different CRM site displayed depending on to which tenant he belongs to. And that's exactly what the web application adapter does:

    - It queries a web service to determin, to which tenant the current user belongs to

    - Then it queries the CRM metadata service to get the object type code for a custom entity (Since we have multiple CRM organizations - one for each tenant - with the same customization, the object type code of a custom entity might differ from organization to organization)

    - Then it generates the appropriate CRM Url and navigates to it

    For the CRM Hosted application I've configured about 6 different actions, like "OpenContact" or "CreateIncident". Each of these actions should display a different CRM page ("OpenContact" should display an existing contact in CRM, where "CreateIncident" should display an empty incident form for inserting a new record). In the Web Application Adapter I've overriden the DoAction method to implement the logic.

    public override bool DoAction(HostedWebApplication.WebAction action, ref string data)
        switch (action.Name)
            case ("Default"):
            case ("OpenContact"):
            case ("CreateIncident"):

    For the "OpenContact" action the corresponding method looks like this:

    private void openContact()
        string customerID = this.currentContext["CustomerID"];
        string url = this.CrmUrl;
        if (string.IsNullOrEmpty(customerID))
            url = crmBaseUrl + "/_static/contact_not_found.htm";
            url += "/sfa/contacts/edit.aspx?id={" + customerID + "}";

    At the beginning of each action method I call a method named waitForBrowserToComplete(), which is a recommendation I've found in a different forum to ensure, that the browser process is ready to handle my request.

    private void waitForBrowserToComplete()
        int ctr = 0;
        while ((Browser.ReadyState != WebBrowserReadyState.Complete) && (ctr < 10))

    I've implemented this method, because I had other problems before, that were caused, because the browser was not ready. How do you handle the "Wait-for-Browser-to-be-ready" thing?

    Besides this web application adapter assembly for CRM, there is a second one, that integrates/automates a Sharepoint site into AgentDesktop using almost the same procedure (query web service due to multi-tenancy capability, generate url and navigate).

    I've also tried the "Use new browser process" option in each Hosted Application, but it doesn't resolve the problem.

    With kind regards,


    Wednesday, August 5, 2009 10:52 AM
  • Hi Ronny

    Firstly, there is more than one approach to automating the hosted web applications. 
    We use DataDrivenAdapters for most of our automations.

    When you use the WebApplicationAdapter, CCF calls the adapter before doing any of its own actions. This allows you to change/prevent the default behaviour of the automations.
    The DoAction method has a return value of true/false. If you return true, it means that the automation will continue, ie it will try to navigate to the URL If you return false, it will stop the automation.
    In your code above, you have left out the return part of the DoAction, so I am not sure what you return. 
    If you return true, the base classes will try navigate as well, potentially navigating straight after you have navigated.
    Lets assume that you return false, in which case, after your DoAction work, it stops processing other work. 
    One of the things that I have found is that doing complex automation on the default action seems to be problematic as IE is till being loaded and events are being attached. 
    What we often do, is start the hosted web application and at a later stage, even straight after the hosted application loads, we fire another action to the hosted web application which actually does the real work, in your case, you could fire the OpenContact action which does the same as the default action.

    One of the other things you can try is to override the BeforeNavigate event of the WebApplicationAdapter. This gives you the oppertunity to override most of the parameters just before it navigate IE. In this technique, you can store the action name in the DoAction method and in the BeforeNavigate you can do your OpenContact logic based on the ActionName. You also dont need to actually do the navigation (wait for the browser to be ready), all you need to do is set the URL in the event. You can also override Headers and PostData before they are sent.

    Hope this helps abit
    Wednesday, August 5, 2009 1:05 PM
  • Hello Craig,

    thanks for all the valuable hints.

    We have decided to use WebApplicationAdapter instead of DataDrivenAdapter. On our first approach we have used DataDrivenAdapters, but they didn't fit our needs. DataDrivenAdapters are implemented as Workflows and they are performed noticably slower than WebApplicationAdapters.

    I return nothing explicitly in the DoActions method, so I think "false" is returned by default.

    I will try to change the code considering your hints and give you a reply.

    Friday, August 7, 2009 7:40 AM
  • I offer a few suggestions on how to deal with this here:

    On CRM.
    The metadata service is pretty Heavy and can really hurt your perf if your calling ot for the same data over and over again.. if your going to reuse that sort of data consistently, consider using a cache on the desktop ( in a hidden hosted control for example ) to hold on to that stuff. 

    We are adding some new features in an upcoming QFE for CCF that will make cache objects and “anchor controls” much easier do.  (ETA on that QFE is “soon©” )

    Thursday, August 13, 2009 1:37 AM
  • Hey Ronny.

    The IE crash happens because when you try to run CCF Desktop, there is a possibility that the IE process is still running in the background due to the fact that you may have closed down the desktop without it killing the relevant processes. Usually happens when running in i.e. Visual Studio debugging mode and instead of closing it down properly you just press Stop Debugging.

    Try looking at the processes running after closing CCF Desktop. If you see in Windows Task Manager -> Processes something like iexplore.exe running. There might be more than 1 process running at the same time. One of those processes will be still connected to CCF.

    If this keeps happening even while closing down CCF Desktop properly, you might need to override IE's close event and call it in CCF's Desktop Closing event.

    Friday, November 27, 2009 11:28 AM