There are situations where recording application using 
protocol Web (HTTP/HTML) encounters problem such as (1) not 
recording events, (2) not launching or (3) crashing. The 
context may deviate however the below list aims to provide 
a quick-and-dirty resolution to the problems. Obviously, 
the quick-and-dirty may work/not work in different 
environment and situations, however it will help you scope 
down the problem in a sequential and logical manner.
 
1.	Use another machine to record 
2.	Use web_custom_request 
3.	Configure Port Mappings using “WinInetlevel data” 
or “Socket level and WinInet level data”. And if necessary, 
define the port and certs. 
4.	Use Older Recording Engine 
5.	Use LoadRunner as Proxy Server on port 7777 for 
Recording (For Older Recording Engine) 
6.	Determine OS Support Status and application type 
7.	Determine the actual protocol and port number using 
Winsock protocol or network sniffing tools (WireShark 
Network Analyzer)
  
I’m leaving out the details at this juncture so that you 
can have an overview steps of what to do when Vugen is not 
recording any HTTP events emitting from your HTTP 
application. I will detailed the steps and reason in the 
subsequent post; so stay tuned!
 
Ok, let’s move to the details on the rationals and steps 
required to get your HTTP application recorded!
 
[1] Use another machine to record
 
Install VuGen on another machine and proceed with 
recording. What we are doing here, is to differ a 
problematic machine to a working one (at a machine-level 
troubleshooting). The existing machine may have problems 
due to a clone image, restricted privileges or previous 
installation of programs (unless you are pretty sure that 
your machine is fully workable with Vugen).
 
[2] Use web_custom_request
 
Use the basic web request methods for communicating to the 
server. This is needed when Vugen (sometimes) is unable to 
recognise the HTTP traffic and compose into web_submit_data 
APIs. Therefore, by instructing VuGen to record using 
web_custom_request only, this will detect all unknown 
communications been used in a HTTP mode to be recorded but 
in a more unreadable or unfriendly web_custom_request 
script.
 
1.1 Create a new Multi-Protocol Web (HTTP/HTML) script; do 
not create a Single Protocol script.
 
1.2 In the recording options, select recording to be URL-
based script (not HTML mode) and select “Use 
web_custom_request only”. Proceed with the recording.
[3] Configure Port Mapping
 
Some applications may use ports that are different from the 
browser. The default HTTP port is 80 by most application 
but this may not be used by the application that you are 
recording against. In such situation, you may need to 
configure Vugento capture the HTTP traffic by mapping the 
ports to the service type. The service type other than HTTP 
are FTP, Socket, etc depending on your application needs. 
In this way, Vugen will become a proxy and capture traffic 
on the defined port. 
 
1.1 In Recording Options ensure that you are already using 
web_custom_request only as stated in the previously.
 
1.2 Go to Port Mappings, remove all registered Entry and 
add New Entry with the known information (such as port 
number and target server). Note that there should not be 
any duplicate port numbers.
 
1.3 If 1.2 didn’t resolve the problem, try using “WinInet 
Level data” for the Capture Level and record the 
application.
 
1.4 If 1.3 didn’t resolve the problem, try using “Socket 
level and WinInet level data” for the Capture Level and 
record the application.
 
1.5 If the above didn’t resolve the problem, edit the port 
mapping entry; change the “Record Type” to “Direct” and 
to “Proxy” if you using SSL. If you know the ciphers used 
and type, you can configure it here.
 
1.6 For SSL, either client-side or server-side, refer 
to “Configuring the Port Mappings” of the Vugen User Guide 
for the detailed information. You will have to provide the 
certificates in either Base64 or PEM format. PEM format can 
be converted with a tool called openssl.exe availablie with 
the installer as well as online search. 
  
[4] Use Older Recording Engine
 
This is to utilize the old recording engine prior version 
8.1. The old version records at the proxy level whereas the 
new engine records on the process level. 
 
[5] Use LoadRunner as Proxy Server for Recording (For Older 
Recording Engine)
 
If [4], didn’t work out right, you have to specifically 
configure LoadRunner as a proxy to record all communication 
via port 7777. Take note that this is in the old recording 
engine.
 
1.1 In Recording Options, under Browser, set the 
application to launch manually with “Manually launch an 
application”
 
1.2 Under Recording Proxy, select “No Proxy”.
 
1.3 On a separate machine (e.g. Machine A), set the Proxy 
to the LoadRunner machine with port 7777. (NOTE: Proxy 
server can be configured on the LR machine itself).
 
1.4 Start recording on LoadRunner machine.
 
1.5 Invoke the application on Machine A.
 
1.6 You should be seeing events counted on the LoadRunner 
machine. It means the target application accesses the LR 
machine and LR is recording it.
 
[6] Determine OS Support Status and application type
 
At this point, you have tried almost everything (and have 
come to theend of the road/solutions). My recommendation is 
to check out with Mercury/HP support, on the support level 
of the target application. Also check them out if they had 
encountered such problems before. 
 
[7] Use Winsock protocol or network sniffing tools
 
Using WinSock protocol, you can determine the actual 
communication method by the client to the server. With this 
evidence, you can bring forward a discussion with your 
client on the unknown communication method. Another good 
tool to use is the WireShark Network Analyzer (formerly 
known as Ethereal Network Analyzer) to identify the 
communication and port being used.