top of page

Troubleshooting guide for problems with LoadRunner Web Recording


Troubleshooting guide for problems with LoadRunner Web Recording

1 Reply

Many different things can affect the Web recorder. Among the things that you can check includes the following:

1. Make sure that the client application is communicating with a server. LoadRunner’s Web recorder records Web applications by intercepting the calls between the client and the server. If you bring up a static HTML file from your local file system, the Web recorder will not be able to record any events.

2. Make sure that the client is communicating with the server via HTTP or HTTPS protocol. Else, the Web recorder will not be able to capture any traffic. If there are any other protocols involved (e.g., Java, NCA, etc.), you will need to use the recorder for that protocol. Consult your developer if you need help to identify the protocol used by the application.

3. To capture the HTTP communication generated by non-HTML elements like JavaScript, XML, and Applets, use one of the following recording options: • HTML Recording, with the “Non HTML-generated elements” option set to “Record within the current script step” • HTML Recording, with the “Non HTML-generated elements” option set to “Record in separate steps using concurrent groups” • URL Recording If you are using the Multiple Protocol recorder, go to Tools -> “Regenerate Vuser” to regenerate the script with the above option you chose.

4. LoadRunner’s regular Web (HTTP/HTML) recorder only records client-server activities. Client side activities will not be recorded. For example: • Click in the pop-up “Security Information” window. • Click on the “Back,” “Forward,” or “Cancel” window of the browser. • Client-side JavaScript/ VBScript validations

Note: This can be handled with the new Web-GUI level recording such as PeopleSoft 8 and Oracle 11i that comes with LoadRunner 8.

5. Make sure that the machine are you are trying to use to record the application does not have parasites. To verify, you can check it from Doxdesk.com – Find Unsolicited Commercial Software. One of the most common parasites known to cause a problem on LoadRunner’s Web recorder is Huntbar.

6. Some other applications, such as antivirus, antispywares, Crypto software, VPN’s, firewall, and so on may interfere with the recorder. In case of problems, always look to see what is installed on the machine and try to disable software that looks like it is interfering with socket level data.

7. If the process that generates the Web request can only be started by another process, use the Multiple Protocol Web recorder. For example, if you need to run a Java program that later initiates another process that will generate the HTTP(S) protocol, use the Multiple Protocol Web recorder.

8. When the Multiple Protocol Web recorder cannot record the first lunching process (e.g., it is a service) or if the process lunches another service using COM (CoCreateInstance), enable the “Track processes created as COM local servers” in the recording option under the General: Script node.

9. If you are using the Multiple Protocol Web recorder, the recorder works in a way where it uses the Port Mapping settings to direct traffic via a specific server:port . If there are no events recorded, double-check on this port mapping setting: a. Go to Tools -> Recording Options -> Network: Port Mapping. b. Make sure that you include HTTP for the “Network-level server address mappings for.”

10. Sometimes, you will encounter cases where the Web recorder (Single and Multi) records some initial login steps but nothing else after that, even though it is still using the HTTP protocol. This can happen if the application is dependent on the cache in some way. By default, LoadRunner recording will disable the cache. To set LoadRunner not to interfere with the cache setting, change the following in registry: a. Go to Start -> Run, and enter regedit to open the registry editor. b. Navigate to HKEY_CURRENT_USER\Software\Mercury Interactive\LoadRunner\Protocols\HTTP\Analyzer c. Set AddNoCacheHeaderToHtml=0. d. Set DisableBrowserCaching_1 =0. 11. Sometimes, you will encounter cases when the WebRecorder will hang at the step for the NTLM credential pop up. To disable the NTLM credential pop at end of recording if the application uses NTLM authentication, change the following in registry a. Go to Start -> Run, and enter regedit to open the registry editor. b. Navigate to HKEY_CURRENT_USER\Software\Mercury Interactive\LoadRunner\Protocols\HTTP\Analyzer c. Set DisableNTLMDialogHooking=1 (default is 0)

Note: You will need to use the web_set_user function explicitly in the script after above changes.

12. The following are limitations of the Single Protocol Web recorder. If any of the following is causing a problem, you are recommended to switch to use the Multiple Protocol Web recorder to record.

Note: All the issues below can be resolved with Multiple Protocol Web recorder.

a. While recording, the Single Protocol Web recorder will redirect the client requests to a local proxy, at localhost:7777. For such, make sure that you have the permission to change the LAN settings of the machine. To verify: i. Open Internet Explorer and go to Tools -> Internet Options -> Connections -> LAN Settings. ii. Make sure that you can modify the entries here.

b. For the Single Protocol recorder, you need to disable “Automatically detect settings” and ‘Use automatic configuration script” before you start the recording. i. Open Internet Explorer and go to Tools -> Internet Options -> Connections -> LAN Settings. ii. Make sure the following two options are not selected: • Automatically detect settings • Use automatic configuration script

Note: The “Use automatic configuration script” option is fully supported with LoadRunner 7.6 and above.

c. The Single Protocol Web recorder obtains the proxy setting from the HKEY_CURRENT_USER registry hive. Verify the following to make sure that it is set up correctly: i. Go to Start -> Run, and enter regedit to open the registry editor. ii. Navigate to HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\InternetSettings. iii. Verify the non-default key, ProxySettingsPerUser. If the ProxySettingsPerUser value exists and has a value data of 0 (zero), set it to 1. It is okay if you do not have that registry key. As long as ProxySettingsPerUser is not set to one, proxy settings will be obtained from the HKEY_CURRENT_USER registry hive


bottom of page