Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Sometimes a simple IE Page wont be loaded in scheduled test script



I already created a Ticket for this issue on ES Agent Recorder Team (SUPDCRUM-17921). We came to the conclusion that our issue is not bases on how we scripted.
We have the problem that when the scheduled script for a really simple Test of the availability of a website runs, it fails because IE never loads anything neither goes to 'site not found' or another error page. It just trys to load endlessly. But the website is fully available and the robot is connected to the network. We checked DNS, IE settings and it seems alright.
We have some traces of the network analyzer attached (Nr. 1 and 2 from 2 differnt agents, Nr 3 from one of the same but with direct connect to the IP) and hope you have an idea what could cause this issue and maybe help us with it.
Kind Regards



Hi Mathys,

DNS is apparently not the culprit in your case, but the last
report gives several errors that could be of interest: no response error and proxy
authentication error. I would assume that something about security policies or
Internet Explorer configuration may be impeding your tests.

wondering what happens when you try to run the test manually, i.e. try to open
the page in Internet Explorer, does it improve on a second attempt? Does it
work any better when you open the same page in a different browser such as
Firefox or Chrome?

Try to
disable Compatibility View also for intranet sites: Tools > Compatibility View
Settings, and if it’s acceptable, disable Protected Mode/Enhanced Protected
Mode, since it may block some of the scripts from downloading.




Can you confirm the highlighted field is NOT selected for your Agent Manager? If it is, could you try deselecting it and see if that clears it up?

This field was ideed checked in our agent manager. I unchecked it now.

Mathys M, Can you let us know if that helped? Thanks.

Make sure you publish after the change.


Hi Mathys,

What you describe is likely an IE hang. IE hang happens in some
cases when IE is being run under the ESM Recorder, and the exact reasons for
the hang are not always known.With that
said, I can offer you two solutions, one sometimes helps in just a pretty
narrow case, the other in my experience always brings good results, but
requires a significant rigorous effort.

I also like to clarify that IE hangs do
not happen with most HTML applications, so these recommendations are only for monitoring applications that
do expose IE hangs when run under the Recorder.


This one might help if the problem happens only during loading the application’s first page, but after
that IE works fine. This solution
usually helps when the Web application requires loading a lot of additional
modules (plug-ins, custom fonts, etc.), but, as I mentioned earlier, this
solution might not help, since you cannot know if you experience exactly this
problem. I still like to mention it since
it’s easier to implement than another approach.

The idea
here is to:

  • Start
    IE with loading the page but without checking IE’s ready state before starting
    the first transaction.
  • Wait
    for some time that would guarantee that page is loaded.
  • Start
    a transaction.
  • Force
    reloading page without cache by sending {Ctrl {F5}}.
  • Wait
    for a condition that would indicate that the page has been displayed.
  • Finish
    the transaction.

code might look approximately like this:

LaunchToPage "http…", False
Sleep 15 ' assume that it is guaranteed that IE starts and loads the page within
15 seconds

StartTrace "Transaction1"

IEWindow("Internet Explorer MainWindow").Type "{Ctrl {F5}}"

WaitFor…StopTimerAndTrace "Transaction1"

some elements of the second approach might help too.


approach is based on avoiding scripting elements that are known from experience
to cause IE hangs. Such areas include:

  • Interrogating
    IE ready state. Check the signatures of
    the Framework functions you are using, many of them have a parameter to avoid waiting
    for IE to be redy, which eliminates such checks, like the second parameter in
    LaunchToPage finction in the approach above.
  • Using
    the Recorder text capture functionality. This includes Framework functions like WaitForText, and Recorder
    functionality, like .CaptuteText .TextExists properties, screen events, text
  • Using
    HTML controls. This means all methods whose
    names start with HTML and all objects whose names start with THTML should
    not be used.

To avoid the
areas listed above you should:

  • Always
    reference an IE frame window (please see if you need explanation of what "frame window" means); if you have only one, then IEWindow("Internet
    Explorer MainWindow") is all you need.
  • When
    you need to wait for synchronization or time measurements, rely on OCR and image
    recognition-based functions. You may
    also use selecting text and putting it onto the clipboard and monitoring the title of the IE
    frame window. The Framework contains
    quite a few examples on using such wait functions.

Once again,
this approach proved to deliver when IE hangs become a problem. It requires more effort for script
development. One of the reasons for that
that is, well.., you cannot use Recorder’s recording functionality. This is why I’d recommend it only when IE hangs
are indeed is a problem.

Please post
any questions regarding the approaches above. This, of course, includes doubts if specific Framework or Recorder
functionality would be appropriate for the approach 2.

Thank you,


Thanks for this detailed answer. Its very appreciated. The first solution sounds good, but iam not sure if the hangs can always be cleared with an Reload trough F5. We already made some trys with approach 2 but how we script doesnt seem to effect the hangs. BR

Hi Mathys,

Once again, the first approach has limited area where it can be successfully used. The second approach will always work as long as you apply it rigorously. It involves significant effort, though.

Thank you,