“Cannot connect to machine <machine name>”

When adding Windows Resource measurement on the LoadRunner Controller, the add was unsuccessful and returns a “Cannot  connect to machine…” error with a bunch of suggestions to keep you busy…   Before you move on in this article, do take a look at two articles, namely, “How-to configure Windows System Resource monitoring” and Document ID: KM304905: Error: “Monitor name: Windows Resources. Cannot connect to machine…” on the configurations required.  Apply them first before moving on.

If error persists after configuring the Windows Resource from the two documents, the next step that you do is to validate the necessary setup from perfmon.  What must be working are, (a) perfmon is running on the target machine and (b) TCP 139 must be opened for the communication on a two-way communication. Some steps here are repetition of the configuration as mentioned above, however, it’s advisable to re-validate the setup:

[1] Validate network setup

• Launch command prompt
• Ping from the command prompt, Run > cmd the SUT from the Controller.  Command as followed: ping <target_machine>.  If the Ping test fail, it’s straight-forward on the following few possibilities: (a) target machine is not up, (b) firewalls or target machine is preventing network pings.
• Telnet from the command prompt, Run > cmd the SUT from the Controller on port 139. Command as followed: telnet <target_machine> 139.  The expected result that if the connectivity is ok on TCP 139, the command prompt will turn full black.  If it fails, it will return “Connecting To <target_machine>…Could not open connection to the host, on port 13
  9: Connect failed” which can be a likely caused of firewall misconfiguration at the (a) network level (e.g. disallow/block ports or IP filtering on firewall) or at the target machine level (e.g. ZoneAlarm or Windows Security).

[2] Validate target machine setup (NTFS)

• At the target machine, launch perfmon.
• Ensure perfmon is running.  If perfmon is not running, it can be caused by corruption of perfmon which may require re-installation of perfmon (Windows OS).
• Now, launch perfmon from the Controller, and connect from Controller’s perfmon to target_machine in “Select counters from computer:”.  If it connects, then you will be able to retrieve the counters.  If not, which response with “Unable to connect to machine”, you will need to ensure the following to be configured.
• In the target_machine, launch the Services.msc from Run.  Ensure the following services are started: Network DDE DSDM, Network DDE and Remote Registry.  Usually they are turned off due to hardening policy.
• Launch regedit from Run.  Naviigate to the following registry keys and ensure that READ access is granted to them:
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Perflib
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg
• Disable Simple File Sharing.  Launch Folder Explorer in target_machine > > Tools > Folder Options > View > at the bottom of “View all settings”, disable “Use simple file sharing (Recommended)”.
• Launch Folder Explorer and type %SYSTEMROOT% in the address bar.  Navigate to %SYSTEMROOT%\System32.  Allow READ access for all users on two files, namely, Perfc009.dat and Perfh009.dat.  (NOTE: Ensure the user being granted the READ rights is the one being used for monitoring from Controller.  If not, do create an additional account for it.)
• Now, go back to Controller’s perfmon and connect to the target_machine again in “Select counters from computer”.  You should be able to see the counters from the target machine.
• Now, go back to Controller and connect to the target_machine which should have resolve the problem.

• Document ID 31731: Troubleshooting guide for VuGen (not stable/crashes/freezes/GPF)
• Document ID 12532: Troubleshooting guide for Controller ( not stable/crashes/freezes/GPF )

There are a couple of solutions in both documents, but we would recommend trying out the following that usually resolves the problem.

• Login as administrator and perform the work with that account.
• Run the batch file.
• Reinitializing the .ini file or the document term it as “recreate the initialization file”.

Take note on the terminology of the administrator here, it is the default administrator account on the Windows operating system without any changes to it’s roles or privileges. If the environment you worked in have default images, or amended administrator account, you may need to use a machine that is “clean” to test out and run Vugen or Controller. On top of the given list from the official vendor, we’ve experiences that certain situations may cause the Vugen and Controller to behave abnormally as well.

Do you have another Mercury/HP product running on the same machine such as QTP or WinRunner? They may conflict with Vugen and Controller when placed together on the same machine. As such, it is advisable to install only LoadRunner components on the machine while other products are to be installed separately.

In addition, you can use Process Explorer (as recommended by the document) to find out if there are conflict with the processes. The link is broken in the document as Sysinternals have been acquired by Microsoft in July 2006. Click Process Explorer to be directed to the actual website.

Do you have DEP enabled in your machine? DEP (Data Execution Prevention) is part of the Windows XP SP2 feature and extends to Windows 2003 and the Vista versions. For more information of DEP, refer to the following resources:

• A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003
• Data Execution Prevention by Wikipedia
• Data Execution Prevention by Marc Liron

To resolve this problem, you have to disable DEP. This is as described in Document ID 41489: No events recorded in VuGen when trying to record an application on Windows 2003 SP1 or Windows XP SP2.

What are the technology/protocol used by the application? Specified to Vugen recording, the third possibility that causes the problem is the type of application that you are working with. Example, if the application runs on RCP (Rich Client Platform) or applets but communicates in HTTP. For this, you’ve to identify the actual protocol being transmitted and find workarounds to it. In the example of HTTP, you can refer to a previous article, “Quick-and-Dirty Recording Techniques for Web (HTTP/HTML)” for more information.

If all else fails, the best suggestion is to get a “clean” machine, login with the default local administrator and perform a re-installation of LoadRunner. Remember, the definition of “clean” means that the machine operating system is not based on a clone image. Well, we’ve to say that this is not the entire list that the community is experiencing and therefore, if you have a problem relating to the crashing or abnormal behavior, please share with us and we will append to this list accordingly.

Error -10343: Communication error: Failed to connect to remote host [server name: ]. (sys error message – ) [MsgId: MERR-10343]

Error -29989: Process “lr_bridge.exe” was not created on remote host “” ,reason – communication error. [MsgId: MERR-29989]

Lately, while I was verifying the upgrade of my LoadRunner versions from 8.1 to 9, I encountered a connectivity problem with the Controllers and Load Generators but well, it’s been resolved… Anyway, just to share with you like a case study on the steps I took to troubleshoot the problem.

Initially I went to the support website in hope to find some information with these generic errors but they weren’t helpful in my context. I’m not implying that they are useless but it wasn’t applicable to me at that point of time. You can look through it too first:

Document ID 25162 – Common connectivity problems between Controller and Generator
Document ID 11905 – How-to and troubleshooting guide for setting up a Windows machine as a Load Generator

To give you a background information, I’ve got 4 machines, one Controller and 3 Load Generators (LG). Let’s name them in the following manner for the ease of illustration:

1. Controller – CONTROLLER
2. Load Generators – LG1, LG2 and LG3

The OS installed for all machines were Window XP and firewall programs were installed in them, namely ZoneAlarm and Sygate.

The following steps were taken:

1. Ping from CONTROLLER to LG1, LG2 and LG3 – No problem
2. Ping from LG1, LG2 and LG3 to CONTROLLER – No problem
3. Telnet port 54345 from CONTROLLER to LG1, LG2 and LG3 – No problem
4. Telnet port 54345 from LG1, LG2 and LG3 to CONTROLLER – No problem
5. Turn off Windows XP firewall for all machines – Done
6. Allowed firewall access for incoming and outgoing traffic – Done
7. Install LoadRunner full suite on LG1 and connect to all other machines via the Controller program – All machines connected except unsuccessful connection to CONTROLLER.

This is clear that communication in terms of network port from ALL machines were successful. Except CONTROLLER where port establishment from the LoadRunner program on CONTROLLER was unsuccessful which signifies that the problem could be caused at the application-level.

8. Tried launching the Sygate on the CONTROLLER – Unsuccessful; Sygate not launched.

After trying all the above, my assumption is that Sygate is corrupted with the LoadRunner, disallowing the it to communicate to the agents on the LG. I’m left with two options.

a. Uninstall Sygate.
b. Format the entire machine and start anew with nothing on it.

I went ahead with [a] before doing the ultimatum [b]. And well, it solves the whole thing! (of course, I installed a new copy of Sygate to get things back to normal too.) Anyway, summary of this troubleshooting, it was caused by a corrupted firewall program which may affect you too so do take note in future!

What are the possibilities in Vugen?

1. The application that you are replaying against is not running.

Simple? But it does happen, as such, when it fails on replay, take some time and try logging into the application manually and perform the business processes.

2. There were changes to the application

There were changes to the application in aspect that had affected the script. For a 3-tier architecture, anything could have changed such as the following:

a. Presentation layer: where links or button are removed,
b. Application layer: where methods are changed or removed,
c. Database layer: where calls or tables are changed or removed.
d. Architecture level: where proxies or load balancers are changed or
removed.

As such, verify with the application and infrastructure team if there were any changes made. You may have to re-script or amend the script accordingly to the changes.

3. There are dynamic values that needs to be correlated.

This is common in applications. They are usually in the form of Session IDs or returned values based on parameterization. You have two options here:

• Use the auto-correlation feature to detect any dynamic values (which I don’t usually use) or,
• Perform manual correlation by recording two scripts of the same business process. From the two scripts, compare the recording logs and the APIs that had been generated for the differences. If you are new to manual correlation, I would recommend you to go through Document ID 11806 – What is correlation and how is it done from the support website to get a better understanding.

4. The parameterization may be causing the problem

The parameterization may be causing the problem in the following manner:

• Insufficient records: ensure that you have sufficient records for the replay, especially in iterations.
• Incorrect records: verify with the application or database team that you are holding on the valid values to be passed in as parameters. Parameterization may also result in different set of data being returned by the server as mentioned previously in (3). If that happens, correlate the value accordingly.

For (1) to (4), it’s recommended to turn on Full Extended Log (all options enabled: Advanced Trace, Parameter Subsitution, Data Returned From Server) in the Runtime Settings (Vugen) to verify the data that is been transmitted between the server and the client (script). Through this, you can find out what and where that could have gone wrong in the replay.

What are the possibilities in Controller?

5. Does it happen at the start of the scenario execution?

We are focusing on the script only and leaving out the load testing setups. If the script/vuser fail at the start of the execution, verify the script again in Vugen, and if it still fails; it’s a script problem where you have to re-work from the previous point (1) to (4).

6. Does it fail on a particular Load Generator (LG)?

This maybe caused by inconsistent LG across the load testing environment. As such, ensure the following in order for the script to run properly (but not limited to the list):

• Folder directories that the script may be accessing to (particularly for file upload and download business processes).
• Java settings like JVM and CLASSPATHs that can affect Java LoadRunner scripts.
• All LGs have the same version as the Controller (e.g. LR9.0 across all LGs in the load testing environment).

7. Does it happen at the middle of the scenario execution?

If it is the case, it maybe caused by anything but unlikely script problems (since the script/vuser have already started running successfully at the start of the run in (5). When this happens, the Application Under Test (AUT) maybe under load and unable to process all requests from the scripts/vusers and therefore returning errors to them. You can verify this with the following.

• Manually log into your AUT again and verify if it is still running or experiencing any lags.
• Reduce the amount of vusers being generated in the scenario and re-run the test. If a reduced amount results in a error-free or non-script related errors, you are sure that the AUT is under load.

The above should be sufficient for you to troubleshoot script/vuser problems in Vugen and Controller. However, take note that it may not be limited to those and it will be advisable to carefully work the problem step-by-step to eliminate and possibilities.