LoadRunner and IE8

Had this small problem today and I believe it would be interesting to share the solution. I was “forced” to update to Internet Explorer 8 (IE8) and for my surprise, VuGen crashes when trying to record anything with it.

My first thought was to check for patches. No patches, LoadRunner was already on version 9.52 (9.50 + 9.51 patch + 9.52 patch). Checking some forum posts I’ve found that the issue can be caused by the “Disable Execute Bit” (DEP) functionality. So how to disable it??

You have to open the boot.ini file (C:\boot.ini) and add the following string to your boot line:


Usually it will become something like that:

multi(0)disk(0)rdisk(0)partition(1)\WINNT=”Microsoft Windows” /noexecute=alwaysoff /fastdetect

I’m not sure if the same solution can be applied to Windows Vista or 7. Also I don’t know if older LoadRunner versions are affected too, but this worked for me. :-)

How to Change the TimeOut on LoadRunner

I’m seeing a lot of searches for Timeout issues landing on the blog these days.

This is a very common issue when executing a scenario, meaning basically that the server has not responded in a specified amount of time. LoadRunner defaults to 120 seconds on all Web based protocols (HTTP, WebServices, Click & Script), but this can be easily changed using a command on the begging of the script, web_set_timeout.

The command have only two parameters, the operation and the new value. The operation can be one of these three:

  • CONNECT: To establish the connection to the Web server.
  • RECEIVE: Time–out on the next “portion” of server response to arrive.
  • STEP: Time–out on each VuGen step.

Usually the one we see expiring the most is STEP, for obvious reasons. The error message should look something like “Step Download Timeout”.

The second parameter is the new value, expressed in seconds. So if we want to set up a new value for STEP we have to insert this code in the beginning of our action:


Being 240 seconds our new value.

Usually I change the timeout value of all three operations, just to be sure:


Simple, isn’t it??

We just have to be careful when changing this configuration, because the default value is already too high for most user actions.

From my point of view, this should only be used in two cases:

  • When we really expect a transaction to be slow, like a large report or file upload, something that the users already expect to be slow;
  • Also when we need to troubleshoot a slow transaction, meaning, waiting for a longer period to get the response.

That’s it!!