KM840444 – Using the Web HTTP/HTML protocol in LoadRunner 9.51 or 9.52, after recording the business process the body portion is missing in the web_custom_request when the script is generated. No error message is displayed in the log files, either during record or replay.
For example, with LR 9.50 the recording of an HTTP POST request to a SAP server generates the following web_custom_request code:
web_custom_request("runtime_2", "URL=http://hostname.domain.org:50000/xxx/yyy/zzzzz", "Method=POST", "Resource=0", "RecContentType=text/html", "Referer=URL=http://hostname.domain.org:50000/xxx/yyy/zzzzz", "Snapshot=t28.inf", "Mode=HTTP", "Body=<body content>", LAST);
After updating to LoadRunner 9.51. (SP1) or 9.52 (SP2), recording the same business process generates the following code:
"web_custom_request("runtime_2", "URL=http://hostname.domain.org:50000/xxx/yyy/zzzzz", "Method=POST", "Resource=0", "RecContentType=text/html", "Referer=URL=http://hostname.domain.org:50000/xxx/yyy/zzzzz", "Snapshot=t16.inf", "Mode=HTTP", LAST);
An internal defect was introduced into the LoadRunner Web HTTP/HTML recording engine at release 9.51 (SP1) onwards.
In some cases the problem may be avoided by choosing a different recording option. If the VuGen -> Recording Options -> General is set to URL mode, try removing the URL Advanced option Use web_custom_request only if this option has been set.
The fix for this problem is built on LoadRunner 9.52 and is available in patch LR95P108 on the support site. The patch must only be applied to LoadRunner 9.52.
KM829038 – ‘Error -27717: Invalid NTLM type 2 message: “NTLM”‘ is displayed when trying to replay a script against an HTTPS web site using the “Use automatic configuration script” option. This is a LoadRunner limitation. Vusers cannot access HTTPS resources through NTLM proxy, obtained from the proxy auto-configuration file (pac).
Specifying the proxy server details in the Run-time settings instead of the pac file.
KM887311 – During the replay of Ajax Click & Script (C&S) the following message appears:
This function onDOMContentLoaded is not supported by Internet Explorer (IE) 6.0 so LoadRunner C&S solution cannot be used here. Try to use the HTTP/HTML protocol
KM825596 – When recording a script using the Flex protocol, occasionally the RTMP calls may be recorded in the incorrect order in the script.
The following is the order of the events as we recorded them:
HTTP requestt (amf) ->
TCP recv (RTMP) <-
TCP send (RTMP) ->
HTTP response (amf) <-
The problem is that in HTTP level (amf call) we refer to the request+response as 1 item (since we generate one step for both), while in TCP level (RTMP) recv and send are independent steps.
You can refer to it as a different level of resolution, different levels of API.
Since HTTP resolution is lower, we have to create the one web step in one of the possible locations – before the recv or after the send.
Our policy is to generate according to the timing of the last event (which is the timing of the response) and not according to the timing of the first event (request sent).
Of course none of these two policies is perfect, and each one of them may fail in different cases.
This is considered a limitation.
KM838715 – The duplicate AMF calls appear in the recording log as well as in the generated code. Capture level is currently set to Socket and WinInet.
Create a new script, make sure under Recording Options –> Network –> PortMapping –> Capture level is set to WinInet (only)
KM832504 – After capturing a Flex script that has Flex_AMF calls and Flex_RTMP calls… When viewing an RTMP call in the tree view the replay request and response are often incorrect. After looking in the replay log we can see the calls are being replayed correctly but they are being displayed incorrectly in the tree view (only the replay in tree view is incorrect). Sometimes it shows the previous or next Flex_AMF call in the tree view in place of the Flex_RTMP call.
This issue has been identified as a bug by R&D in LR 9.51 adn LR 9.52. R&D issued a new flexreplay.dll which resolved the issue and will be included in the next Service Pack.
KM851819 – Black screenshots appear during recording/replay when using Citrix Presentation server 4.0 and 4.5.
To correct this:
Go to the Citrix server
Select Start Menu > Settings > Control Panel > Administrative Tools > Terminal Services Configuration > Server Settings > Licensing
Change the setting Per User or Per Device to the alternative setting (i.e. If it is set to Per User, change it to Per Device and vice versa.)
NOTE: This limitation is documented in the LoadRunner “readme.htm” release notes for LoadRunner 9.5 SP1 and 9.5 SP2.
KM855459 – The solution to this problem is to use the documented workaround:
Workaround: When recording, set the window size equal to the local screen resolution. When replaying/load testing, set the VuGen or Load Generator’s screen resolution to equal the resolution used when the script was recorded. To verify the recorded resolution, view the Window property in the<Script Folder>\default.cfg file.
KM860635 – Controller fails to display the graph measurements when sitescope version 10.0 is added as a monitor engine.Specifying a monitored machine name using a fully qualified domain name or IP address, the Controller will fail to display the default graph measurements.
This is a limitation in LoadRunner 9.52. Instead of providing fully qualified domain name or IP address, specify only the actual machine name (without any domain suffix)
KM860995 – There are two ways a SAML token can be created with the web services protocol: If a Security Token Service (STS) is used, i.e. the client asks for the SAML token from the STS (request 1) and then sends it to the server (request 2). If this is the case, create the token using federation scenario. Manage services -> Protocol and security -> new scenario -> WCF – WSFederationHttpBinding
If no Security Token Service (STS) is involved. If the client generates the SAML assertion by itself and also signs it by itself then use ws_sign_saml_assertion() method.
KM865534 – LR9.5 controller crashes on Vista when an action is done on “Add Group” or “Add Vusers” button.
A patch is available for this on the support site. It replaces the scripttree.ocx file.
KM870596 – When it is necessary to upgrade Loadrunner (LR) from version 8.10 and below to version 9.5, user should be aware that there might be not only some loss of information, but also the risk to get unexpected behaviour in Loadrunner.
In these cases it is always recommended to create new scripts and run them according the new functionality of the newer versions.
LoadRunner’s behaviour in order to present results has substantially been modified.
In order to update LoadRunner’s scripts and results files it is advisable to try an as smooth as possible upgrade of the software.
Since only version 9.0 and above is supported, this upgrade has not been tested, but given the different features newer versions implement, there is a high risk some data will be lost during the upgrade process.
Using old results files may turn into a bad functionality of LR 9.5.
KM823684 – After installing SP2, a similar entry to the one below may be seen in the replay log:
Web Turbo Replay of LoadRunner 9.50 SP1 for WINXP; WebReplay96 build 7049 (Sep 23 2009 17:14:02)
When selecting Help -> About HP Virtual User Generator the following is seen as well:
About HP Virtual User Generator
displays 18.104.22.168 for all componenets.
The entry in the replay log (Web Turbo Replay of LoadRunner 9.50 SP1 for WINXP; WebReplay96 build 7049 (Sep 23 2009 17:14:02) ) may be seen because SP2 was developed as a patch to be applied on top of SP1 and because of this there may be cases where LR 9.50 SP1 is shown in the replay log. This can be ignored as SP2 was successfully installed.
KM821875 – When using HP LoadRunner 9.52 (that is LoadRunner 9.5 with both SP1 and SP2 applied) to analyse a results file, the following error message is displayed:
“Errors have occurred while analyzing this result. Do you want to view the error log?”
This may occur when the LoadRunner platform locale (Regional Options – Standards and formats) is set to a non “English” value e.g. “German (Germany)”. The resulting error log may contain entries as follows:
Analysis Error log: <dd.mm.yyyy hh:mm:ss>
SQL Error: Insert into VuserEvent_meter select * FROM [Text; database=C:\DOCUME~1\<username>\LOCALS~1\Temp\].130209606VuserEvent_meter.txt; ADO :(Could not update; currently locked.):
Furthermore closing and re-opening the Analysis component results in a popup being displayed with the text:
“Unable to format numbers. Thousands and decimal separators are equal: “.”
If the locale is set to “English” opening the Analysis component will not result with this popup being displayed.
Incorrect delimiters may also be observed in the analysis report for numeric values.
Non English locale settings such as delimiters are incorrectly handled by the LoadRunner Analysis component.
A patch is available to address this issue in LoadRunner 9.52 on the support web site.
Did you enjoy this article? Help spread the word by sharing:
Engage in the conversation and leave a comment:
About Scott Moore (153 articles)
With over 20 years of IT experience with various platforms and technologies, Scott has tested some of the largest applications and infrastructures in the world. He is a Certified Instructor and Certified Product Consultant in HP’s LoadRunner and Performance Center products. He currently holds HP certifications for ASE, ASC, and CI. A thought leader in the APM space, he speaks regularly at IT conferences and events