Error: "Vuser failed to initialize extension vbascriptext.dll" when replaying a VB or COM script

The user receives the following error while replaying a VB or DCOM script:

"Vuser failed to initialize extension vbascriptext.dll."

Solution

 Troubleshooting vbascriptext.dll error

1. Make sure that VBA is installed properly :
    a. Install the VBA drivers by going to Start -> Programs -> LoadRunner -> Tools -> VBA Setup.
    b. Complete the install and reboot the machine.
    c. Run your script again.

Note: If you are using older versions of LoadRunner ( before LoadRunner7.5) please contact Customer Support for the VBA setup install.

2. VBA compiler has a limitation of up to 39 characters of the file name. Since Mercury adds additional characters to the script name, it must be 21 characters or less.

3. If the problem persist, try to run your script though the VBA IDE once. To do so:
    a. Bring up your script in VuGen.
    b. Go to Vuser -> Run-time settings -> VBA.
    c. Enable "Debug script through VBA IDE (VuGen only)."
    d. When you run the script, VB IDE should be launched. If not, it means VBA driver was not installed (properly). You might need to reinstall your VBA setup.

4. If step (3) brings you to the line 'Dim objectHelper As New LoadRunnerVbs.ObjectFactory', it is an indication that LoadRunner helper object is not registered. You can manually register lrapihlpr.dll and lrapivbs.dll under the \bin directory. After that, "LoadRunner Protocol Replay Helper" will be checked by default in the Run-Time Settings -> VBA option.

5. Make sure that you are using the VB function correctly. For example, LoadRunner function should be referenced as 'lr.' instead of 'lr_'
    Example: lr.save_string "param_value", "param_name"

6.Check the security-properties of the \bin\vba6_setup\vba6.msi file and make sure 'Everyone' have full permissions on it. Uninstall the VB Addin by right-clicking on vba6.msi file and selecting 'uninstall' and re-install the Add-in.

Note:
1. You might need to reboot your machine after making these changes.
2. For running script on a remote machine, please make sure that you installed the components for the application on all load generator machines.  

Monitoring Weblogic using LR

Check in the controller available graphs for Weblogic (JMX) type. If it is not present then do the customization to display it:

1. edit the file (open with a wordpad)
"HP\LoadRunner\dat\onilne_graphs\online_resource_graphs.rmd"

2. Look for [WebLogicJMX]

3. Change: EnableInUi=1

Then do the following steps to access the monitors:

a) Download weblogic.jar from server and put it in \classes

b) Remove jmxri.jar from \classes (keep a backup somewhere)

c) Install Java on controller and update the \dat\monitors\WebLogicMon.ini to point to installed java

JVM="C:\Program Files\Java\j2re1.4.2_18\bin\javaw.exe"

JavaVersion=1.4.2_18

Then restart your controller and add the measurements to your weblogic graph.

If you are not able to add the machine and getting a host can't be found error, then do the following steps:

********************************************************

Make sure that the host name and IP can be resolved:

From Command Prompt (Start -> Run -> type in cmd.exe):
1. ping with the machine name and take down the returned IP address.
Example: ping
2. ping with the IP address returned from (a) with -a option.
Example: ping -a 111.111.111.111.

If you have problem on getting the expected information, things you can try includes:

1. Update the host file.
You can try to add the name and the IP address of the WebLogic Server host machine into the hosts file
a. Go to c:\winnt\system32\drivers\etc\
b. Edit hosts in word editor
c. Add the hostname and IP address to the last line.
Example:
127.0.0.1 localhost


After the above changes, try to add the WebLogic monitor again. Please note that you may need to kill the javaw.exe process before adding the monitor. To do so
1. Bring up the Task Manager ( Cntrl-Alt-Delete -> Task manager )
2. Switch to the 'Process' tab.
3. Search for javaw.exe and end the process.

********************************************************

Note: Please note that Weblogic (JMX) monitoring can only be used till weblogic version 9.X. For higher version you need to install sitescope and get the data.

How to convert a C-Web Vuser script to a Java Vuser script

Converting a C Vuser to a Java Vuser requires sed.exe and lrconvertweb.sed

For LoadRunner 8.0 and above
1. Record your Web Vuser using standard HTML/HTTP recording.

Note:
a. Be aware that Java Vusers use different parameter braces; Web uses "{ }" and Java Vusers use "<>," which can cause some problems with converted users. Edit the script or the options appropriately.
b. Make sure that the Java environment is setup properly by running an empty Java Script first.

2. Replay your Web Vuser. When it replays correctly, cut and paste the entire script into a text document.

Example:
C:\temp\web.txt

Note: There is a known limitation on the number of lines the sed utility can process. If you have a large file, break down the script to smaller chucks, with 1000 lines each. Then, convert each of the segments to Java

3. Make sure that \bin is in your system's PATH enviroment. Then open command line and switch to \dat directory. Enter the following command:

sed -f web_to_java.sed [script_file] > [destination]

Example:
sed -f web_to_java.sed c:\temp\web.txt > c:\temp\java.txt

4. Open the C:\temp\java.txt file, and copy the entire contents into your Java Vuser's Action section when it is appropriate for your application. If you are placing the generated Web Java script into a Java-Template user, you will need to Modify the public int action() line to look like public int action() throws Throwable, otherwise the user may not run. Recorded Java users (i.e., RMI/Corba) should already have this change.

5. You should now be able to parameterize the script and use it to correlate with the combined Java Vuser.

6. After converting the script to Java, you may need to set some Web related Run-Time Setting. Since 'Internet Protocol' section is missing in Java-Related template, you can do the following to add the Run-Time Settings:
a. Close VuGen
b. Navigate to the c. Edit the relavant .lrp (General-Java.lrp for Java template) file using a word editor.
d. Locate the [Vugen] section.
e. For the data for CFG_TAB_DLL=, add a comma (,) and add LRWRunTimeSettingsUI.dll to it.

Error: "failed to create agent channel " during Citrix recording with Citrix

During Citrix Recording or Replay with Citrix Client 10, the user encounters the following error: "failed to create agent channel".

Solution:

Open a notepad and copy paste the following entries to it:

**********************

Windows Registry Editor Version 5.00


[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Third Party\CustomVC]

"VirtualChannels"=""

[HKEY_CURRENT_USER\SOFTWARE\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Third Party\CustomVC]

"VirtualChannels"=""

************************************

save the notepad on desktop as a .reg file (like "citrix.reg")
Then close the notepad and go to desktop and double-click the file you saved.
It will add the entry to your registry. After that re-login to your windows session and record the application again.
You will be able to record now...

How to monitor Unix resources from controller

There is no need for any LoadRunner installation to be on a Unix/Linux Machine to be monitored.
However, the machine must have the default RSTAT daemon installed and running. The controller establishes a UDP socket connection with the UNIX machine. It first communicates with port 111 on the Unix machine and this port is then mapped to the dynamic port on which the rstatd is working. The controller then queries rstatd and all communication takes place through this established UDP socket connection.

Starting the rstatd process in Unix

To monitor UNIX resources, you must configure the rstatd daemon. Note that the rstatd daemon might already be configured, because when a machine receives an rstatd request, the inetd on that machine activates the rstatd automatically.

To verify whether the rstatd daemon is already configured:
The rup command reports various machine statistics, including rstatd configuration. Run the following command to view the machine statistics:
>rup host
A remote host will only respond if it is running the rstatd daemon. If you do not receive a response, or if you receive an error message, the rstatd daemon is not configured.

To configure the rstatd daemon:
1 Run the command: su root
2 Go to /etc/inetd.conf and look for the rstatd row (it begins with the word rstatd). If it is commented out (with a #), remove the comment directive, and save the file.
3 From the command line, run:
> kill -1 inet_pid
where inet_pid is the pid of the inetd process. This instructs the inetd to rescan the /etc/inetd.conf file and register all daemons which are uncommented, including the rstatd daemon. 4 Run rup again.
If the command still does not indicate that the rstatd daemon is configured, contact your system administrator.

Which port is rstatd daemon running on:
You can run a UNIX utility called rpcinfo and identify the rstatd's port number. By running
> rpcinfo -p
you will receive a list of all RPC servers registered in the host's portmapper, along with the port number. This

Working with Firewalls in Loadrunner

Working with a firewall means that you can prevent unauthorized access to
or from a private network, on specific port numbers.

In a regular LoadRunner load test scenario (not over a firewall), the
Controller has direct access to the LoadRunner agents running on remote
machines. This enables the Controller to connect directly to those
machines.

When running Vusers or monitoring applications over a firewall, this direct
connection is blocked by the firewall. The connection cannot be established
by the Controller, because it does not have permissions to open the firewall.

LoadRunner solves this problem by using a communication configuration
based on HTTPS or secured TCP/IP. This configuration uses the standard SSL
port on the firewall (port 443).

A LoadRunner agent is installed on load generators running Vusers over a
firewall, and on Monitor Over Firewall machines that monitor the servers
that are located over a firewall. The agent communicates with the MI
Listener machine through port 443 in the firewall.

The MI Listener is a component that serves as router between the Controller
and the LoadRunner agent.

When the LoadRunner agent connects to the MI Listener, the MI Listener
keeps a listing of the connection to the agent using a symbolic name that
the agent passed to it.
When the Controller connects to the MI Listener, it communicates to the
MI Listener through port 50500.

The following diagram is a basic example of a LoadRunner deployment over
a firewall.



Setting Up your System to Use Firewalls: Basic Steps

Setting up your system to use firewalls involves the following stages of
configuration:

Installation and initial configuration
Running Vusers over a firewall

****************************************
Installation and initial configuration
****************************************

To enable over-firewall communication, ensure that you have installed the
following LoadRunner components:

MI Listener
Monitor Over Firewall component
To perform initial configuration of your over-firewall system:
1 Configure your system according to TCP or HTTPS.
2 Modify your firewall settings to enable communication between the
machines on either side of the firewall.
3 Configure the MI Listener.

Configuring the MI Listener

To configure the MI Listener:

1 Open incoming HTTPS service for port 443. The port settings are set by your
system administrator.
2 Stop the LoadRunner agent on the MI Listener machine by right-clicking its
icon in the system tray and selecting Close from the popup menu.
3 Run MI Listener Configuration from
Start > Programs > LoadRunner > Advanced Settings, or run \launch_service\bin\MILsnConfig.exe.



4 Set each option as described in the following table:


5 Click OK to save your changes, Cancel to cancel them, or Use Defaults.
6 Restart the LoadRunner agent by double-clicking the shortcut on the
desktop, or choosing Start > Programs > LoadRunner.
7 Make sure that port 443 is free on the MI Listener machine.

**********************************
Running Vusers over a firewall
**********************************

To set up your system to run Vusers over a firewall:

1 On each load generator machine that will be running over a firewall,
configure the LoadRunner agent to communicate with the MI Listener.
2 Configure the Controller machine to recognize the load generator and MI
Listener machines.

Configuring LoadRunner Agents Over the Firewall

1 Stop the LoadRunner agent by right-clicking its icon in the system tray and
selecting Close.
2 Run Agent Configuration from Start > Programs > LoadRunner > Advanced
Settings, or run \launch_service\bin\AgentConfig.exe.
3 Select the Enable Firewall Agent check box, and then click Settings.



The Agent Configuration dialog box opens.



4 Set each option as described in “Agent Configuration Settings”




5 Click OK to save your changes, or Cancel to cancel them.
6 Restart the LoadRunner agent by double-clicking the shortcut on the
desktop, or select Start > Programs > LoadRunner > LoadRunner Agent
Service/Process.
7 Check the connection status between the LoadRunner agent and the MI
Listener.

Configuring the Controller for Running over a Firewall

1 Run the Controller from
Start > Programs > LoadRunner > Applications > Controller and create a
new scenario, or load an existing one.
2 Click Generators to display the Load Generators window. In the Name field,
enter the symbolic name of the server. This is the same name that you
entered in the Local Machine Key setting in the Agent Configuration.




3 Select the Load Generator, and click Details to display the Load Generator
Information.




4 In the Security tab, enter the MI Listener machine's name in the MI Listener
field. This is the same name that you entered in the MI Listener Name
setting of the Agent Configuration dialog box. In this example, the MI
Listener is bunji.
5 In the Firewall Settings section, select one of the following options:
➤ Enable running Vusers over Firewall. To run Vusers over the firewall.
➤ Enable Monitoring over Firewall. To monitor Vusers over the firewall.
6 Click OK to return to the Load Generators dialog box.
7 Select the load generator and click Connect.

This will do all the setup required to run your test over the firewall...

How to replay Citrix script against a different window size

Go to the script directory in Windows Explorer.

Open the default.cfg file located inside the script directory and change the window= value under the [CITRIX] section to a valid value that can be seen in the recording options (640 x 480, 800 x 600, 1024 x 768,1280 x 1024 and 1600 x 1200).

Please note that if you have any ctrx_sync_on_bitmap functions recorded it will not replay in the new window setting because the hash value will be different.

Creating a Basic Script from Server Traffic (Web-Services)

While dealing with web-services based application(s), sometimes it is not possible to capture the user actions using Vugen. This might be due to application nature or something else. In this case there is an utility to create a basic LR script by using "analyze traffic" feature of web-services based script.

The actions needed for this are as follows:

1. Create a network capture file
2. Open a new web-services script in Vugen and import the WSDL.
3. Use the analyze traffice option to generate the script.

*************************
Create the capture file
*************************
You can obtain a capture file using the command line utility or any existing
capture tool.
There is a utility in Vugen's bin directory called as "lrtcpdump.exe"which can be used to create the network traffic capture file.

To create a capture file on a Windows platform:

1 Choose Start > Run, type cmd and click OK to open a command window.
2 Drag in or enter the full path of the lrtcpdump.exe program located in the
product’s bin directory.
3 Provide a file name for the capture file using the following syntax:
lrtcpdump -f
4 lrtcpdump prompts you to select a network card. If there are multiple
interface cards, it lists all of them. Type in the number of the interface card
(1, 2, 3 etc.) and click Enter.
5 Perform typical actions within your application.
6 Return to the command window and click Enter to end the capture session.

********************************************************
Use the analyze traffice option to generate the script.
********************************************************

1 Choose File > New and click New Single Protocol Script in the left pane.
2 Select the Web Services protocol and click OK.
3 Click the Analyze Traffic button or choose Vuser > Analyze Traffic. The
wizard opens.
4 Add the WSDL file location/URL and select next (optional)
5 On the next page provide the capture file information and click Finish

This will generate your basic web-services script for the action(s) performed. Then you can do your customization (parametrization and correlation) to the script.

Note: Please make sure that while making the capture file, all other TCP application(s) are closed. Only the application under test should be opened.

How can i check the download size of a file during replay

If your application is having a functionality to download a file; and you want to check the size of that file during replay of your script to verify whether the download is happening fine or not.

You must me thinking whether there is any function in LR or not... well there is a function to check exactly the same. The code snippet is mentioned below:

********************
int downloadsize;

web_submit_data(".....");

downloadsize= web_get_int_property(HTTP_INFO_DOWNLOAD_SIZE) ;

*******************

Error: "-26668: Could not update controller sync file" during a load test

Diagnosis:

When running a script under the Controller and "Snapshot on error" is selected or when running in VuGen and the Run-Time Browser is opened, replay needs to write a "sync" file for the application (Vugen/Controller). The file should be called "ctrlsink.dat" and placed in the scenario result directory. The error occurs when the opening of the sync file using fopen(filename, "w") fails.

Solution:

Verify the disk space and permissions

1. Verify if there is enough disk space is available. (Check the environment variable "temp" location, better to have it other than the default user temp location like a temp folder on D-drive or C-drive)
2. Verify if the user has enough permissions to open a file in the specified directory.
3. If specified directory is on a remote machine, check if there was a network/remote machine failure

Note: If you are using LR8.0 or 8.1 make sure you have installed all your feature packs or patches.

How to view the complete error messages in the Analysis session

Solution:

Add "AdditionalGroupBy=Error Message" to ErrorsPerSecond.def and ErrorSummary.def

To display the complete error messages in the Analysis tool, do the following:
1. Close Analysis
2. Go to "LoadRunner Install Dir"\bin\dat.
4. Open ErrorsPerSecond.def using a word editor (notepad/wordpad).
5. Edit the section for "Graph Definitions."
6. Add an "Error Message" value to the AdditionalGroupBy key.

   Example:
   [Graph Definitions]
   AdditionalGroupBy=Error Message

7. Repeat Steps 5 and 6 for ErrorSummary.def.
8. Reload the raw analysis session and Add Error Statistics graph.
9. After the 'Error Statistics' graph is added, right click on the graph and select ' Set Filter/Group By' option.
10. On the Lower pane where it says, 'Group By' select 'Error Message' and it should be availabe in the 'Available Group'
11. On the upper pane where it says 'Filter Condition', under 'Error Message' or 'Error Type' select all or any of the error codes or message to be shown on the graph.
12. This will show the error messages along with the code on the lower half pane where the graph is dsiplayed and it will exported in any reports that are created.

The result collation process fails, is it possible to recover the result data?

Solution:

Try the Collate option (Controller -> Results -> Collate Results)

First, try the Collate option: Controller -> Results -> Collate Results. If this fails, then,
1. On the controller machine, go to Result -> Results setting to verify the result location.
2. Navigate to the result directory on the controller.
3. Locate the file named remote_results.txt and open it in any word editor
4. On remote_results.txt, you will see the location of the .eve file on remote host. For example
   MyHost=c:\temp\brr1\netdir\test\myhost_1.eve
5. Go to that specific host, and copy of the .eve file to the controller machine's result directory.
6. Open the Result file ( .lrr) in Analysis .

If the scenario crashed, or ended prematuerly then set "FullData=1" in the lrr file of the result folder:
1. Open the Result file ( .lrr) in notepad
2. Search for the [Data Collection] section
3. Create/modify the value or FullData to 1
    Example:
    [Data Collection]
    FullData=1

This will help in cases that the result files ( *.eve) contains useful data but the Controller did not manage to write to the lrr that it has the data. FullData will be zero in this case. Setting it to 1 will enable you to view what data was saved.

If the result still failed to come up, it is very likely that the _t_rep.eve file in the controller is not completely generated. In order to save what can be saved, run the scenario again, for a short interval(5 mins) saving the results in a folder different than the old results folder. The _t_rep.eve file and the .lrr file in the new result directory need to be edited. In the _t_rep.eve file there is a line (first one) which maybe something like this:

"28 11 1018300521 2 4627103 22735576 5481115"

The 11 is the event code for start scenario.

The 1018300521 is the start time and it needs to be moved backward to match the beginning of the first load test.

The same must be done for the scenario start time specified in the .lrr file. For example,

[Scenario]
Start_time=1018300521

Put here the same number.

After this replace the binary eve files(.eve or .gzl) from the new load test result with the ones collected from the LoadGenerators resulted from old scenario run. Back up the data folder in the new results directory. Copy the data folder from the old results directory in the new results directory. Now the results can be analyzed.

If the exact time of start of the first load test is not known. Select any start time that will definitely fall before the estimated start time of the original scenario. For eg; say 10000 seconds less than the one in the new load test. Make a few iteration until you find out what exactly was the first event's time.

Note:

The duration of scenario in the new result will not be accurate.

It is advised not to overwrite the old result directory in these cases since it consists of the summary data and the monitoring data created even before collation.

How to execute Analysis with a .lrr or .lra file from command prompt

Solution:

Executing Analysis from the command line

Here is the command line that you need to execute to run Analysis from the command prompt:

"LoadRunner  Install Dir"\bin\analysisui.exe -RESULTPATH "path to .lrr/.lra file" 
You can as use the flag -TEMPLATENAME templatename to specify the template you want to use.

NOTE: templatename should only contain the name of the template to be used. The full path is hard coded in a configuration file. 

How to specify the number of iterations when executing a VuGen script from the command line

Solution:

Use lr_get_attrib_string() to read the command line argument

VuGen has an -infiniteiterations option to specify the script to run infinite times. There is not currently a command line option available to specify the exact number of iterations.

1. In VuGen, select Run-Time Settings -> Additional attributes.
2. Create an argument name (for example, "iter"), and give a default argument value of 2.
3. Use a for loop in the Action item, and repeat the action "iter" number of times.

Example:
Action()
{
   int iterations, i;
   iterations = atoi(lr_get_attrib_string("iter"));

   for (i = 1; i <= iterations; i++)
      lr_output_message("This is a test, iteration is %s", lr_get_attrib_string("iter"));
      return 0;
}

Note:
If you have any parameters declared in the script that are set to change values for each iteration, you may want to change them to each occurence so it takes a different value for each time it runs.

From the command line you can now run the script as

 "LoadRunner install dir" \bin\mmdrv.exe -usr  "path to .usr file" -out "path_to_output_directory" -iter "no_of_iters" 

How to execute/replay a VuGen script from DOS

Executing a VuGen script from the command line

Here is the command line that you need to execute to run a VuGen script from the command prompt:

"LoadRunner install dir" \bin\mmdrv.exe -usr  "path to .usr file"

Note:
In order to get all the other options that go with the command, run mmdrv.exe from the command prompt without any options.

How to run a scenario from the command line

Solution:

Command line arguments for the LoadRunner Controller

Note:
1. Make sure that the Controller is shut down before starting the scheduled task.
2. When running the Controller via the Command Line, Controller will be shut down automatically after the scenario ends.

Command line parameters are parameters that the Controller receives when it is invoked. They are used to instruct the Controller on how to behave. When invoked, the Controller checks all the received parameters and sets its startup environment accordingly. If no parameters are passed, the Controller uses its default settings.

By passing parameters in the command line, you may set the Controller and the scenario's settings without the need to manually define them in the Controller UI. For example, you can instruct the Controller whether to connect to TestDirector on startup by using the ConnectToTD parameter, save the results to a directory other than that defined in the scenario by using the ResultName parameter, or invoke Analysis upon scenario termination with the InvokeAnalysis parameter.

The most common use of the Command Line is done by TestDirector. TestDirector includes a special program called "Test Run Scheduler," which was designed for scheduling the Controller to run scenarios at a specific date and time. It automatically invokes the Controller and runs scenarios. Results are saved in the TestDirector database. To do that, TestDirector must set the scenario's environment by supplying the Controller with specific parameters.

Predefined rules:

• When one or more parameters are not passed, the Controller uses its default settings.
• Results will always be overwritten.
• The Controller will automatically terminate upon scenario termination and the results will be then collated.
• The Controller's settings are loaded from wlrun5.ini located in the Windows directory.
• The following parameters are supported on all Windows 9x and Windows NT platforms.

Switches for LoadRunner/TestDirector integration:

• ConnectToTD - Should the Controller connect to TestDirector on startup (0/1 or ON/OFF).
• TDServer - TestDirector server name. Must be a computer name with TestDirector installed.
• TDDB - Database name. For example, "lrun."
• UserName - User name.
• Password - Password for the user name.
• TestPath - Path to scenario in the TestDirector database. For example, "[TD]\Subject\LoadRunner\Scenario1." If the path includes white spaces, use quotation marks.
• TestId - Test ID (for TestDirector only).
• ResultCleanName - For use with ResultCycle only, for example, "Res1."
• ResultCycle - TestDirector cycle, for example, "LR_60_SP1_247." To define the results path in TestDirector, the Controller must be provided with two parameters: ResultCycle and ResultCleanName.

Run-Time Switches:

• Run - Runs scenario, dumps all output messages into res_dir\output.txt and closes the Controller.
• InvokeAnalysis - InvokeAnalysis will set a flag in the Controller, which will invoke Analysis upon scenario termination (If not used, the scenario value will be taken).

Results Switches (for File System):

• ResultName - Full results path, for example, "C:\Temp\Res_01."
• ResultCleanName - Results name, for example, "Res_01."
• ResultLocation - Results directory. For example, "C:\Temp".
• Note:
  • If the scenario does not specify a results directory and one of the above parameters was not passed, the scenario will not run!
  • The results will always be automatically collated upon scenario termination.
  • The results will always be automatically overwritten.

Command Line Syntax examples:

Wlrun.exe -TestPath C:\Temp\Scenario1.lrs -ResultName C:\Temp\Res1 -Run -InvokeAnalysis

Wlrun.exe -TestPath C:\Temp\Scenario1.lrs -ResultLocation C:\Temp -ResultCleanName Res1 -Run

Wlrun.exe -ConnectToTD on -TDServer localhost -TDDB lrun -UserName yaniv18 -Passwordb#12GcSA -TestPath "[TD]\Subject\Trash for LR/TD Integration\Scenario1" -Run

Wlrun.exe -ConnectToTD 1 -TestPath "[TD]\Subject\Trash for LR/TD Integration\Scenario1" 

How to run a scenario at a specific time

Resolution/Solution:

Use scenario scheduler of Controller or Windows Scheduler

Using Scenario Scheduler of Controller:

1. Open the scenario in the Controller.
2. Go to Design Tab -> Edit Schedule -> Scenario Start time and set the time when you want to start the scenario.
3. You need to click on Start Scenario button so that the Controller can trigger the scenario once the start time comes up.

Using Windows Scheduler:
Scenario Scheduler of Controller is limited to the effect that it can only be sheduled to be run at one time. In order to re-run it the scenario has to be edited again. Instead, you can do the following:

1. You can have the scenario run from command line in a batch file.
2. Then you schedule this batch file to run at different times from the Windows Scheduler. 

Common Errors between Controller and Agents

· Error -10343: Communication error: Failed to connect to remote host

· Error -29989: Process "lr_bridge.exe" was not created on remote host , reason - communication error.

Resolution:

Different problems can cause the above error. Some of the things you can verify include:

1. Make sure that you apply the same LoadRunner version and Service Pack on the Controller and Load Generator machines.

2. Make sure that you can ping the Controller and host machine bidirectionally. You may need to add the IP address and machine name on the host file:

1. Go to the host machine.
2. Navigate to C:\WINNT\system32\drivers\etc\.
3. Open the hosts file in a word editor.
4. At the end of the file, add another line with the IP address and machine name of the Controller machine.

Example:
111.111.111.111 MI_Controller

5. Repeat steps a - d for all the host machines.
6. Repeat steps a - d for the Controller machine, but adding the IP and machine name of the hosts machines.

3. Make sure that the LoadRunner Agent is running either as a process or a service on the remote host machine.

4. Make sure the Controller and host are connected to the network. In some networks, the Microsoft LOOP back IP address 10.10.10.10 is used when a computer is not connected to the network. As a result, the Controller will not be able to detect the host machine. You will need to stop the loop back service, connect to the network, and make sure that the machine has a valid IP address.

5. If there are multiple network cards in the machines. Configure which NIC to be used by the process for communication. See below for some info…

==================================

Multiple NIC can cause communication problems between the Controller and the host

In general, having multiple NICs in a machine could cause a problem with the Controller-Load Generator connectivity.

The reason is that the communication may not always be tagged with the correct interface when sending a reply to a request from the Controller. If a message is sent out from one NIC to a host machine, but that host knows the Controller by the other, then that message will be considered to have come from a different Controller and ignored as a host can only serve one Controller at a time. Likewise, messages sent from a host machine to the Controller on an NIC other than the one the Controller knows, will not be marked as comming from the correct host. This may cause the Controller to think the host is not responding. In cases like this, the communication gets "lost" and will result in time-out errors or similar. Removing extra interfaces resolves the problem.

Other possible solutions involve always using the "primary" interface, which is listed under Network and Dial-Up Connections -> Advanced -> Advanced Settings -> Adapters and Bindings in Windows 2000. This dialog allows you to reorder the network interfaces to change their priority. Always reference the top most adapter when connecting with the LoadRunner Controller.

============================

6. It might as well be possible that some network environment issue might be the cause and the network monitor can be used to diagnose the problem. Make sure that you are using the latest driver and firmware for your network cards and routers. Also try to force the network card to use 100Mbs/Full Duplex instead of the 'Detect automatically the best speed settings'. In case of miscommunication with the router or other network device the automatic settings could be set in an inappropriate way and have huge consecuencies on the network performances.

Error -10344: Communication error: Failed to bind socket. A process on the machine is already bound to the same address.”

Resolution:

The LoadRunner Agent Process is trying to connect through a port that is busy

LoadRunner Agent Process/service starts itself at port 50500 and 54345 (For monitoring/running vuser over firewall, it is port 443). Do a netstat -an on the machine and check to see if 54345 and 50500 are occupied. If these ports are in used when you start the agent, you will get the above error. You will need to shut down the application that is using those ports, so that the ports are freed before restarting LoadRunner agent.

You may also get this error during replay if LoadRunner agent of the host machine is connecting back to the controller using a port that is already bound. By default, this is a dynamic port and LoadRunner agent will automatically try a different port.

· Error -29987: Process "traceroute_server.exe was not created..." when connecting to a remote host

Resolution:

Add the host name and IP address to the Hosts file

Verify that you are able to ping back and forth between the Controller and the Load Generator machines using both host names as well as IP addresses. If the ping in any one case fails:
1. Add the host name and IP address of Load Generator to the Hosts file on the Controller.
2. Add the host name and IP address of the Controller to the Hosts file on the Load Generator.

Note:
The Hosts file is usually under C:\Winnt\system32\driver\etc.

Error -30932: “Failed to open eve file - ”

Resolution:

Delete the old .eve files

Do the following:

1. The Load Generator files may be specified in the Controller options to be shared on a network drive, but they are being saved on a local drive. To check this, in the Controller go to Tools -> Options -> RunTime File Storage and select the "On the current Vuser machine" option.

2. The *.eve file is one which stores transaction times and is coallated at the end of a scenario run. If there are old *.eve file on the host machine it can be a problem. Delete the contents of the C:\temp folder, that will remove any old *.eve files from the machine that were not cleaned up from an earlier scenario run.

3. Shut down Controller. Go to C:\winnt folder. Look for wlrun.* and delete all files that the search returns. Go to \bin folder and run register_controller.bat.

Vuser memory footprints - LR 8.1

Suggested debugging steps when Controller crashes

Make sure that you login as a local administrator

Login to the Controller machine with a local administrator account. Using domain account may cause unexpected behaviors.

Make sure that there are sufficient Disk Space
Make sure that you have enough disk space available on the controller and load generators. During scenario execution, the events are written onto the Load Generator machines and are saved locally until the scenario finished; where results are send back to the Controller. If the machine does not have enough disk space, it can cause problem.

Make Sure that the Temp directory is outside the User’s default Temp directory.

Make sure that there are sufficient memory available

To check available memory on a machine:
Right-click the status bar, and select Task Manager. Select the Performance tab to check the physical memory available. Select the Processes tab to check which processes have high memory consumption in the CPU column.

To free up memory:
• Close any unnecessary processes running on the machine, and try running the scenario again.
• Restart your computer.
• If the problem persists, reduce the number of virtual users that you are running on the same machine.

To enlarge the size of your virtual memory:
1. Click Start -> Settings -> Control Panel -> System.
a. For Windows 2000, select the Advanced tab, and click Performance Options.
b. For Windows NT, select the Performance tab.
2. In the Virtual memory section, click Change.
3. In the Drive list, click the drive that contains the paging file you want to change.
Under Paging file size for selected drive, type a new paging file size in megabytes in the Maximum size (MB) box, and then click Set.

To boost performance, and allow more Virtual Users to run on the load generator machine:
•On Windows 2000 machines, select Start -> Settings -> Control Panel -> System -> Advanced -> Performance Options, and select the Background Services option.
On Windows NT machines, select Start -> Settings -> Control Panel -> System Properties > Application Performance. Set Performance boost to "None."
Check if the size of the output.mdb file in the results folder is more than 2 GB
If the output.mdb file becomes greater than 2GB during a load test, Controller is unable to write into it anymore and cause a crash.


Run the Controller’s batch files to register DLLs

Sometimes, DLLs can become unregistered or the registry can become corrupted to a point where a program's DLLs cannot be found. The purpose of batch files is to reregister them into the system's registry so that the programs can locate them. Use the following steps to do this:

1. Shut down the Controller.
2. Navigate to the \bin directory, and look for the following files:
• register_controller.bat
• set_mon.bat
3. Create a duplicate copy of the file, in the same location.
4. Open up the duplicated file. In it, you should see several entries like the following:
regsvr32 /s webbrwsr.dll
Remove the "/s" from each of these statements, but leave a space between the "regsvr32" and the DLL name.
5. Save the changes.
6. Double click on the batch file to run it. You should get several pop-up messages.


Try to recreate the Controller’s initialization file

Sometimes, the initialization files can become corrupted (e.g. after a crashed). You will have problem in launching or using the Controller after that. Use the following steps to do delete the initialization file so that a new copy will be created:
1. Shut the Controller.
2. Navigate to the C:\Winnt ( or C:\Windows for Windows XP machine )
3. Delete all files that begin with wlrun*. For example,
wlrun.ini, wlrun5.ini, wlrun7.dft, wlrun7.hst, wlrun7.ini


Check the temporary environment variables

Unlike the earlier window’s versions, Window 2000 and Window XP have the default environment set to c:\Document and Settings\\Local Settings\Temp instead of c:\Windows\temp. This long path with a space can cause several problems on LoadRunner. To resolve the issue, change to a directory without empty spaces

Reboot
When programs crash, they leave the system in an unstable state. This can cause many other problems that seem to have no apparent reason for happening or has not happened before. When the system is rebooted, it resets the system into a more stable state. This should be done after any program crashes.
Verify the information in the event viewer
Sometimes, if a program crashes, it does not give any clues for what had happened. By using the Windows event viewer, it may be possible to find some clue as to what happened when the crash occurred. The event viewer can be launched from Start -> Programs -> Administrative Tools -> Event Viewer.


Verify other programs are interfering with Controller

To find out whether hooked DLLs are possibly causing a problem, you can use a third party utility call "Process Explorer." This utility has the ability to view the DLLs loaded by an application. It can be downloaded free of charge from the following link:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

This can be used to see if LoadRunner loaded any other program's DLLs. Use the following steps to do this:
1. Unzip the .zip file, which was downloaded from the above URL, into a directory where you wish to install Process Explorer.
2. Start the Controller.
3. Run the Process Explorer (procexp.exe) from the directory into which you unzipped it (step a).
4. Select wlrun.exe (Controller) from the top section of Process Explorer.
5. The bottom section should be displaying a list of DLLs. If it is showing handles for the application, go to the "View" menu and select "DLLs."

6. Search through the list to see if any other program's DLLs are loaded. Normally, only DLLs from the \bin directory and standard Microsoft directories are loaded. For example, if you see wbhook32.dll (McAfee VirusScan hooking DLL) loaded by LoadRunner, then you would want to shut down the anti-virus software.


Disable anti-virus software
It is known that anti-virus software is intrusive when they are set to look for viruses. However, in searching for viruses, the software can interfere with a program's proper execution. This could cause problems and sometimes crashes. This is why, for debugging purposes, it is recommended to turn off the anti-virus software.

What if the number of events does not increase/nothing gets recorded?

1. The selected protocol might not be correct
2. The action currently recording does not use the protocol that is being specified in the script. The number of events will not increase till it comes across the protocol that is specified.
3. The activities that are taking place are client side and not server side. This will not get recorded.

How to display the total number of Vusers in the scenario instead of just the running Vusers

Displaying the total number of Vusers in the scenario instead of just the running Vusers

There are two files that need modifications.

1. Open VuserStateGraph.def located under \bin\dat.

1. Search for the [AdditionalFilter0] section.
2. Change Values=Run to Values=Quit.
3. Save the file.

2. Open AnalysisSummary.asc located under \bin\dat.

a. Change FieldName=Maximum Running Vusers: to FieldName=Total Running Vusers:.

2. Save the file.

3. Open up the results file (.lrr) again, it will now display the Total Running Vusers as opposed to Maximum Running Vusers.