October 21, 2018
Hot Topics:

How To: Getting Diagnostic Data in your Windows Azure Application

  • August 8, 2011
  • By Vipul Patel
  • Send Email »
  • More Articles »


Windows Azure applications run in the cloud, so unlike on-premise applications, the ability to troubleshoot hotspots in your cloud application is no longer as simple as attaching a debugger to the troubling application. Since Azure applications run on servers hosted on Microsoft server farms, traditional troubleshooting methods will not work.

However, Windows Azure does provide the functionality needed to gather diagnostic data. The complete list of diagnostics data which can be collected by Windows Azure Diagnostics is shown in the table below:

Diagnostic Data Type

Collected by default

Windows Azure logs


IIS logs


Windows Azure Diagnostic infrastructure logs


Failed requests


Windows Event logs


Performance counters


Crash dumps


Custom logs


There are basically 3 main steps to enable the gathering of diagnostic data in your Windows Azure application.

Step 1- Import Diagnostics module in service definition

Let's start by opening the service definition file of a Windows Azure project and adding code to import the Diagnostic module.

Double click on your servicedefinition.csdef file in your Visual Studio Project.

Image 1

By default, the debug module is imported when you create a project in Visual Studio. So, you should see the highlighted XML tags in your service definition file.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureDiagnosticDataDemo" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole1">
      <Site name="Web">
          <Binding name="Endpoint1" endpointName="Endpoint1" />
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
      <Import moduleName="Diagnostics" />
  <WorkerRole name="WorkerRole1">
      <Import moduleName="Diagnostics" />

Step 2- Specify diagnostic connection string

The second step to enable the capturing of diagnostic data in your application is to specify the diagnostic connection string that Windows Azure application will use.

The connection string is used by Windows Azure to identify the credentials to use to store the diagnostic information. The connection string can be specified in the service configuration file by setting a value for Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString. During development, you can specify UseDevelopmentStorage=true.

You can open up serviceconfiguration.cscfg and check that by default, Visual Studio sets it to use development storage.

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="WindowsAzureDiagnosticDataDemo" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" osVersion="*">
  <Role name="WebRole1">
    <Instances count="1" />
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
  <Role name="WorkerRole1">
    <Instances count="1" />
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />

Step 3- Specify custom configuration settings for diagnostic data to be captured

In this step, you can specify any custom data you want to capture. For example, say, you were interested in capturing the data. If you are interested in knowing the processing time used by your application, you can specify this as a custom diagnostic data to be captured by your application.

Let us see how we can add code in our application to gather this custom data.

In our WebRole class, modify the OnStart method to as under.

public override bool OnStart()
            // For information on handling configuration changes
            // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.

                DiagnosticMonitorConfiguration dmConfig = DiagnosticMonitor.GetDefaultInitialConfiguration();
                    new PerformanceCounterConfiguration()
                        CounterSpecifier = @"\Processor(_Total)\% Processor Time",
                        SampleRate = TimeSpan.FromSeconds(30)


                DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", dmConfig);
            catch (Exception e)
                Trace.WriteLine("Error setting diagnotic monitor configuration");
            return base.OnStart();

The method to show the configuration settings is defined as.

public void DisplayConfiguration(DiagnosticMonitorConfiguration dmConfig)
            int count = dmConfig.PerformanceCounters.DataSources.Count;
            for (int i = 0; i < count; i++)


You can see that in the OnStart method, we get the default instance of DIagnoticMonitorConfiguration. We then process to add a custom performance counter “Processor Time”.

Once we add the perf counter to the diagnostic configuration we call the Start method on DiagnosticMonitor class and specify the configuration.

This will ensure that for the WebRole Class, we will get the default diagnostic data, as well as performance counter “Processor time”.

As you can see, DiagnosticMonitorConfiguration class is quite flexible and allows adding any custom data that an application developer desires.

If you are having trouble following along with the code, you can download the code sample from here.


In this article, we learned how we can gather diagnostic data in our Windows Azure applications. I hope you have found this information useful.

About the author

Vipul Patel is a Software Engineer currently working at Microsoft Corporation. He is currently working in the Microsoft Lync team and has worked in the .NET team earlier in the Base Class libraries and the Debugging and Profiling team. He can be reached at vipul_d_patel@hotmail.com

Originally published on https://www.developer.com.

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that developer.com may send you developer offers via email, phone and text message, as well as email offers about other products and services that developer believes may be of interest to you. developer will process your information in accordance with the Quinstreet Privacy Policy.


Thanks for your registration, follow us on our social networks to keep up-to-date