If broken it is, fix it you should

A while ago I was looking for an easy way to explain developers how to find and fix memory leaks. During my research I’ve found this really interesting blog by a Microsoft Engineer, Tess Ferrandez.

She is constantly posting new tips and guides on .NET development and troubleshooting. I really like the “.NET Debugging Labs”, step by step guides on how to fix common issues, such as Memory Leaks, CPU Hangs, Crashes and so on.

If broken it is, fix it you should:

Installing HP Diagnostics Probe for ASP.NET Applications

Another very useful tip shared by Odorico:


  • Just install the provided file, “HP .NET Probe.msi”, which is probably under the “Diagnostics_Probes” folder;
  • Inform the name of server where the Diagnostic is was installed;
  • Keep the other settings as default.

Remember to reset IIS to get the changes (enable/disable probe) in place:
Go to  ’Start > Run’  “iisreset”

Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted

You will be able to Enable and Disable the probe in the application server. By default, after installation, probe is enabled.

If the application you intend to monitor is not detected by the Probe, or if new applications are deployed in the server, you can Rescan ASP .NET Application. A new application point will be created for any new application in the server.


Probe will be installed in the folder C:\MercuryDiagnostics\.NET Probe

Configuration and application points settings will be find in etc folder (C:\MercuryDiagnostics\.NET Probe\etc)

File C:\MercuryDiagnostics\.NET Probe\etc\probe_config.xml contains the main configurations. You will be able to add more detailed monitoring information by editing this file.

The main changes you should do are:

  • Monitoring Heap: Add to “process enablealldomains” the tag “monitorheap=”true”
  • Monitoring IIS and memory information: Add the Iis and Lwmd file points

Example file:

<?xml version="1.0" encoding="utf-8" ?>
- <probeconfig>
<id probeid="" probegroup="Default" />
<credentials username="" password="" />
- <profiler authenticate="">
<authentication username="" password="" />
<diagnosticsserver url="http://localhost:2006/commander" />
<mediator host="localhost" port="2612" metricport="2006" />
<webserver start="35000" end="35100" />
<modes pro="true" />
- <instrumentation>
<logging level="" />
<lwmd enabled="true" sample="1m" autobaseline="1h" growth="10" size="10" />
- <process enablealldomains="true" name="ASP.NET" monitorheap="true">
<logging level="" />
<points file="ASP.NET.points" />
<points file="ADO.points" />
<points file="Iis.points" />
<points file="Lwmd.points" />

- <appdomain enabled="false" name="1923244809/Default">
<points file="1923244809-Default.points" />

If it is necessary to add monitoring level under some specific classes and/or methods you just need to configure the <application_instance>.points file:

;Uncomment and modify this section to capture calls to your business logic
;class                   = !Namespace_Qualifed_Class_Name_Of_Your_Code.*
;method                  = !.*

;signature               =
;scope                   =
;ignoreScope             =
;layer                   = 1923244809/Default

Fields class and method will contain the namespace for the classes and method would contain the specific methods to monitor. CAUTION: Avoid monitoring of all methods (.*). That would be very intrusive and the probe tends to impact server performance.


When you open the profiler (during installation it will be showed the port number the service will run) you will see the following screen:

You will also be able to know the Probe’s application port for each IIS application, by checking this information in probe_config.xml file.

<webserver start="35000" end="35200" />

The webserver start and end shows the port ranges for the probe. The first application point will be running in the port 35000, the second one in the port 35001 and so on.

In our example we have only one application installed in IIS, so we just access URL:



Heap Tab

You can see the application Heap. In this example application presents a memory leak. You can see Gen 2 and Large heap increasing very fast and they are not releasing meaningful portion of memory. Even after the test has been finished, we noticed a significant portion of memory remains allocated.

A rank with the most memory consumer classes is showed. For instance String, Byte[], and Collectors, such as Dictionaries.

Collections Tab

The collectors tab shows how collections grow along the test. For the application example, we have a significant increase in collections allocated in the class CommunityServer.Controls.TagCloud.get_DataSource().

How can I save and share the reports?

You can save a monitoring snapshot by click in Snapshot button. It will be created a XML file containing all information we had collect at that time.

NOTE: Snapshots can create huge XML files. So a good practice is to compact the file before sharing it!

IMPORTANT: The probe is intrusive. It collects a lot of metrics from the application. Thus, don’t forget to disable the probe after you have finished your tests. It will be necessary to reset IIS once again.

Using WSDL files to Create WebService Scripts

Hello Folks,

Today I’m here to show you how to use one of the easiest scripting protocols on LoadRunner, WebService. Being simple doesn’t mean that the protocol it’s not powerful. A lot of large enterprise applications and web portals use WebServices on the back office processes.

There are several ways of scripting this king of application, but today I’ll show how to use .NET WSDL files to create a simple script. Instead of pasting several images on the post I thought it would be more productive to record a screen cast. So here it is, the first video guide of this blog:

The steps are very simple, not much to be done!

  1. Create a new single protocol script using the Web Service protocol.
  2. Click on the “Manage Services” button on the top left corner.
  3. Click on the “Import” button.
  4. Select URL and then paste your WSDL file URL Remember that it should include the “?WSDL” string at the end.
  5. Click on the “Import” button and then OK.
  6. Back to the script view, click on the “Add Service Call” button.
  7. Select the service you just added on the “Service” drop down list.
  8. Select the call you want to add on the “Operation” drop down list.
  9. At this point, you will see a list of parameters (Input and Output) on the middle box.
  10. The Input parameters are the parameters you will use on your request. On the opposite way, Output parameters are the parameters returned by the server.
  11. Some input parameters are required and some are optional. You will notice the difference on the “Include argument in call” checkbox.
  12. The required parameters have this checkbox disabled.
  13. With this checkbox you can add optional parameters to the request.
  14. You can also set the values you’ll be sending by filling the “Value” text box.
  15. You can save the returned parameters by selecting the desired parameter under “Output Arguments” and selecting the “Save returned value in parameter” checkbox.
  16. Once you’re done with the arguments selection, click on the OK button. This will add the request to the script.
  17. Once the code is created, you can replace parameters, add static arguments and all sorts of things that can only be done in LoadRunner.
  18. Returned values will be saved on the selected parameters to be used later, in case you have more than once call per script (sequential steps).

That’s It! On the next guide I plan to show you how to create WebService scripts using application trace files.

See you next time!