LoadRunner VuGen: Fixing Corrupted Winsock Libraries

I was trying out the new Protocol Advisor in LoadRunner 9.5 this week, and I found it was not working as advertised. It wasn’t even recommending WEB as a protocol choice for recording a simple web script. Not good. The only thing it did recommend to me properly was RDP. If a person cannot figure out they are using RDP when they launch an RDP window, they probably should not be using LoadRunner. 🙂 I decided to dig a bit deeper and found I had discovered a bigger problem.

On my past several engagements, I had been using the clients LoadRunner lab machines to script and run test. Any time I have had to script with my own laptop, it was used for web/http recording. When LoadRunner 9.0 came out, I remember having an issue where I was able to capture events during recording as shown on the recording bar, but after stopping the recording, there were no recorded steps (and no code) in my script. One of the tell tale signs of a problem was this line in the recording log after each recording:

NOT PROXIED! (REASON: Unable to connect to remote server: rc = -1, le = 0)

Hold it! What does a PROXY have to do with this, you might ask? I am not using a PROXY, I have a direct connection to the Internet, so what is that all about? Let’s not get too far off on a rabbit trail here. VUGen has to “hook” into an application in order to parse all that data (traffic) and then analyze it and turn it into recorded steps (or code) for you. Vugen becomes an in-memory PROXY in order to do this. It has nothing to do with your Internet connection settings or whether you use a proxy or not. It is part of the “secret sauce” to VUGen, so let’s leave it at that. This error only makes sense when you put it into context that the “remote server” it cannot connect to is the winsock DLL’s. If any other LoadRunner guru’s want to check me on that and get back with me with more details, I am happy to post them here, but that is the simplest explanation I can come up with.

Back to when my problem began: to get past my initial issue back in version 9.0, I went into the VUGen recording options for Network/Port Mapping and set the top option from the default “Socket Level Data” to “Socket Level and Wininet Level Data”.

This made web scripting work long enough for me to get my script done and I moved on, basically because I did not want to have to troubleshoot the issue any deeper at the time. What did this setting change do? Socket level data captures data by trapping on the socket level only, using the Windows winsock libraries. When this option is used (the default), the port mappings listed apply if you set them. Wininet recording captures data using hooks on the WinINet.dll API used by Internet Explorer. Port mappings are not relevant for this level. Luckily I have only had to use Internet Explorer on my own laptop for the longest time for HTTP-based recordings. When you select BOTH, it captured through both mechanisms, and socket level sends data only if it determines that it did not originate from the WinINet dll file. Basically, I was very lucky I did not have to troubleshoot this in a critical situation and had time to do some research.

Since the Protocol Advisor uses Winsock only to capture data to determine which protocols to recommend, it’s not going to work if you have issues with Winsock recording in VUGen. It is the same mechanism after all. The first thing I had to do was prove this problem was limited to my machine. My friend Stuart Moncrieff at JDS in Australia confirmed it was working for him. I checked another machine in our company that had the same laptop image as me, and it worked there. OK, so it’s just me. Now what? The next thing is to check what good and bad Winsock libraries look like, and for that, we need to go to Microsoft. I checked out this URL on the Help and Support web site:

http://support.microsoft.com/?kbid=811259

Wow – all my answers in one place! Since I did not have the Support Tools from the XP install disk on my laptop, I decided to use the manual method to check stuff (method 2).

Click Start, click Run, type Msinfo32, and then click OK.
Expand Components, expand Network, and then click Protocol.
You will have ten sections under Protocol.
The section headings will include the following names if the Winsock2 key is undamaged:

• MSAFD Tcpip [TCP/IP]
• MSAFD Tcpip [UDP/IP]
• RSVP UDP Service Provider
• RSVP TCP Service Provider
• MSAFD NetBIOS [\Device\NetBT_Tcpip…
• MSAFD NetBIOS [\Device\NetBT_Tcpip…

If the names are anything different from those in this list, the Winsock2 key is corrupted, or you have a third-party add-on, such as proxy software, installed.

“If you have a third-party add-on installed, the name of the add-on will replace the letters “MSAFD” in the list. “

This last statement was the key. I followed the instructions and looked up my own and found the first line was:

BMI over [MSAFD Tcpip [TCP/IP]]

This indicates that I have a corrupted key, third party software, or a trojan/virus. Uh oh!

After doing a little research, I traced the BMI over to my Sprint Wireless Internet card that use when I go to clients. It never occured to me that it might place a wrapper over my Winsock libraries. VUGen might not like that. It also reinforces the fact that your LoadRunner lab should remain clean of all extra utilities and software that are not absolutely needed so you don’t run into conflicts like this. Since I am a consultant and do not always know if the client will grant me Internet connectivity from my laptop, the wireless Internet card is a neccesary evil. I remember the first time I installed the software I had a bit of trouble and that was about the time I loaded up LoadRunner 9.0 – it’s all starting to make sense now. This is why uninstalling and reinstalling, and upgrading to version 9.1 and 9.5 wouldn’t correct the problem.

At first I tried to simply uninstall the Sprint client application, rebooting and retrying, but that didn’t work. I downloaded the “Guided Help” application from the MS URL above. It automatically makes all the changes, while visually walking you through them, and it has full undo in case you decide that was the wrong thing to do. I basically reinstalled the Winsock driver on my main network connections (the LAN).

After another cautious reboot, I launched Vugen, and everything works fine. I set the recording options back to Winsock data, and was able to record HTTP, FTP, and WINSOCK scripts just fine. The Protocol Advisor now works just like it is supposed to. I was able to reinstall my Sprint client application and retry everything, and it still works. It did not modify the Winsock libraries either. I believe an older version of that client application did that, and the latest version does not, which is why I had so many problems installing it when I first got the card. I’m really happy to get LoadRunner working right, but disappointed that I unknowingly masked a deeper issue by changing settings in VUGen without fully thinking about what those settings do. Sometimes we blame issues with recording and hooking on LoadRunner, when we need to fully examine the LoadRunner lab environment we are using and be aware of everything that is installed on our machines, including anything that comes with a machine image for desktops, laptops, and servers in our company.

Here is more information about Wininet:

http://msdn.microsoft.com/en-us/library/aa383630(VS.85).aspx

and Winsock:

http://msdn.microsoft.com/en-us/library/ms740673.aspx

I want to give a special thanks to Moshe Kraus, the developer of the Protocol Advisor for responding to me over a weekend. I take back all the bad words I said about it when I was trying to get it to work last week. I am preparing for a webinar to demonstrate this functionality soon, and now I can do so without a hitch. I hope this information helps some of you experiencing the same issue.

Scott