Some of you might be wondering what is the use of a profiler. I am a good programmer and my application is running without any trouble. Why shall I use the profiler?

Think of a scenario where you have developed an application which is going to be deployed on a production server and several hundred of users are going to use it. How can you verify that the application will be working perfectly as expected?

Take another scenario where some of the users are complaining about the application slow performance. How can you identify and correct the performance bottleneck? Which function is causing the issue? Which line to correct?

Visual Studio profiler is an answer for such scenarios. To know more about profiler you may need to read the MSDN link.

This walkthrough is an effort to present some important features of the profiler, introduced in Visual Studio 2010, which can help the developers/testers improve application performance. 

Brief Summary of features:

• No need to setup environment variables for "Attach Profiler to Process".
• Start Performance Analysis easily.
• Profiling In Progress - do simple operations while profiling is done.
• Profiler Summary Page - get an overview of the results.
• Function Details View - peep into the code and get function level details with the profiler.
• Profiler Guidance Rule - remove bottleneck by analyzing the code and get expert advice.

Attach Profiler to Process:

You can now attach profiler to an already running managed application. With earlier version, there was a need to setup environment variables correctly. This is not a requirement in Visual Studio 2010.

• Run the managed application.
• Attach the process. (Analyze>Profiler>Attach).  
• Select the process from the "Attach Profiler to Process" dialog box. 

You can also select the CLR target version for the managed process.

• When you are done, detach it.

[You can also use the /ATTACH:PID option with the vsperfcmd command]

Start Performance Analysis

With this new option, you can start profiling the application with minimal effort. Here are the steps to start a performance analysis session from the UI:

1. Open a solution in Visual Studio 2010.

2. Click Debug>Start Performance Analysis :

3. Select the Profiling method :

4. Select the project and launch the profiler along with the application :

Alternatively, you can also use the keyboard shortcut key ALT+F2 to run the profiler. This will invoke the performance wizard.

Profiling in progress

Profiling the application can take a long time and during this period a spin control is displayed.

Here you get the option to stop profiling. This may be needed if the application has already reached at the stage which needs to be examined.

Profiler Summary Page

The report can be viewed in different forms. The default view is "Summary View".

The profiler summary page makes it easy to analyze the performance of the application. It contains the following important sections which helps diagnose the performance bottlenecks in the application. Profiling a simple VC# console application which contains a nested for-loop provides the following summary page:

The heading of the report lists how many samples were collected during the profiler session. In this example, there are 355 samples collected.

Highlight a region in the graph and click the link "Filter by selection".

Right to the view selection box, there is a filter toolbar which contains different filtering options. Alternatively, filter criteria can be set by manually typing the timestamp values.

"Show Filter" is the first button which shows the filter criteria selection box. You can execute, import and export the reports also.

Once the criteria are specified, use the "Execute Filter" (second button) to show the data based on the specified timeline.

The filter can be reset by clicking the option in the Clear Report Filter in the Notifications section.

Hot Path

The summary page also shows the call path that is most expensive.

Functions doing most individual work

This section lists all the expensive functions in the order of their exclusive samples collected during the profiling.

Function Details

Clicking the function will direct to the respective Function Details. Following is the function detail window for WriteLine(string) function.

The blue-boxes are click-able. Clicking the function will open-up the function code view:

Profile Guidance Rule

Profile-guidance rules help to provide guidance to improve performance of the application.  Go to Tools>Options>Performance Tools>Rules. These rules can be configured depending on the need.

In the example, clicking the View Guidance under the Notifications section shows the following warning:

Summary

It is worth investing time running Visual Studio 2010 Profiler to ensure high productivity and improved performance.

a. Events and Call Information

b. Recordings - iTrace file

c. Capturing Events

d. Specify modules

e. Intellitrace Window

f. Navigation Bar

g. Running the trace file

3. Tips

4. Summary

1. Introduction

Most developers are familiar with Visual Studio debugger. Up to Visual Studio 2008, you have an option to have a snapshot of the process. Those versions didn't give you the ability to go back and check other events and methods which might be responsible for the current state of the application. If you miss a single step, you need to restart debugging. Breakpoints/traces  monitor the state of application but at times, it becomes very difficult to capture all information within the debugger.

The problem becomes more serious and time-consuming if you need to share your findings with others. What happens if the problem can't be reproduced on your colleague's machine?

In Visual Studio 2010 Ultimate Edition, there is a new feature called Intellitrace (also known as Historical Debugging).

Historical Debugging or Intellitrace

With Intellitrace, you can record the debug session and also save the application state for future reference. It enhances your live debugging experience. You can go back while debugging to check the events/local variables & call-stack.

2. How it works

a. Events and Call Information

Here is the options window:

You can get this Window by selecting Tools>Options. By default, Intellitrace is enabled.

If enabled, you can either set it to the default "Events only" level or set it to "Events and call information".

b. Recordings - iTrace file

Visual Studio saves a file called tracelog (.iTrace) for each debugging session. The name of the log file is unique and contains the date-timestamp for future reference. You can specify the location of the tracelog file and also control the maximum size of the file.

The iTrace filenames are self explanatory. For example the following file is saved on my machine:

I tried two debugging sessions on a simple WinForms application and thus there are two iTrace files generated.

Typical file format is:

<application_name> _<YYMMDD_HHMMSS>.iTrace

[As you can see the application name is followed by the vshost here. You may need to disable vshost to get the iTrace for the application not running under vshost. Visual Studio hosting process can be disabled by unchecking Project>Project_name Properties>Debug>Enable Debuggers>Enable Visual Studio Hosting Process.]

c. Capturing Events

You can capture following categories of events:

i. ADO.Net

ii. ASP.Net

iii. Console

iv. Data Binding

v. Environment Variable

vi. File

vii. Gesture

viii. Lazy Initialization

ix. Registry

x. Service Model

xi. Threading

xii. Tracing

xiii. User Prompt

xiv. WorkFlow

xv. XML

You can select them by menu Tools>Options>Intellitrace>Intellitrace Events. Under each category, there is a list of events that can be opted individually.

d.    Specify Modules

You can also specify the modules for which you need to record events, methods & parameters.

Either you can make an exclusion list or, an inclusion list whichever is smaller. This gives a lot of flexibility in instrumentation. For example, if you don't want to capture details about the module presentationcore.dll, you can include in the exclusion list so that its methods and their parameter details are not captured. This helps in reducing the size of the tracelog file and also filters useful information needed for debugging.

e.    Intellitrace Window

For this example, IntelliTrace is enabled. Create a simple Winforms application and start debugging. You will find that a new window appears called "Intellitrace". [If not visible, you may need to click the Intellitrace TAB in the pane.]

Familiarity with the Intellitrace Window:

There are two Views:

I. Events View - In this view, captured events are shown. You can filter the categories of events from the drop down combo-box on the left side displayed in the figure as "All Categories". Similarly, you can concentrate on some specific threads as well (selected by the next combo-box shown as "All Threads".

II. Methods View - displays only when method logging is enabled(i.e. when "Events and call information" is selected.

This Intellitrace window shows us the default events that are captured. For example, two events are shown below:

I am currently at a breakpoint which is showing as the yellow arrow button. If the first button is clicked, the debugger reaches the main function and the side bar (navigation bar) shows an arrow sign with a clock:

You can see the Call Stack, locals and exceptions by clicking the options available with each captured event in Intellitrace window.

f.     Navigation Bar

When the exception is selected in the Intellitrace view, Navigation Bar becomes visible.

If you click Set Debugger Context button, the debugger will set the context to the current event.        

As you can see, there are step out, go to previous call, step in, go to next call, and go to live mode buttons available.

g.    Running the trace file

Now suppose you are given a project with the trace log to reproduce a bug. How do you run the file and reproduce the issue?

i. Open the tracelog file in Visual Studio. [Use the menu option File>Open and select the iTrace file.]

ii. In Visual Studio , You will see Intellitrace summary page like this :

This graph contains the timestamp of the entire debug session along with the thread lists. If you expand, you will find all the threads listed:

If you double-click any thread, the debugging session will start for that thread. You need to match the symbols and align the source to get the full advantage.

3. Tips

a. Navigation gutter not shown

The navigation bar or gutter is visible if you select the check box "Tools >Options>Intellitrace>Advanced>Display the navigation gutter" while in debug mode.

b. No source available

You need to make sure that the source code for the modules is available. If not, you will get the following error:

c. Intellitrace does not support Remote Debugging

So what happens if you attach the debugger to a remote process? You will not get Intellitrace support.

d. Intellitrace does not support debugging C++ Unmanaged/Mixed-Mode code

Currently, Intellitrace doesn't have the functionality to get a trace log for unmanaged code.

4. Summary

In short, Intellitrace will drastically change the debugging experience and help reduce the time reproducing bugs in our application. Let's start using it and enjoy.

!!!Happy Debugging!!!

When we run the application outside the debugger, it runs fine, launches the debugger and works normally.

 Now what happens when we run the application inside the debugger? Per MSDN documentation, nothing should happen when this line is executed.

System.Diagnostics.Debugger.Launch()                        

This seems to be quite logical. When a process is already attached with the debugger, how can you attach another one? Similar is the case with the remote debugging.

Now the question may arise, which one gets precedence? Whoever arrives first. Alright now how can we know what is happening in background? Interestingly, if try to attach a debugger to a process which has already invoked a debugger through Debugger.Launch() then we would get the message :

"Unable to attach to the process. A debugger is already attached."

 On the other way, if a debugger is already running a process and encounters Debugger.Launch(), it will silently ignore it.

1. The following command-line will spawn procmon in Quiet mode(will not ask for any filter. It will collect all information). The procmon will start in the minimized window and also save the log in the file(abc.PML):
procmon /Quiet /Minimized /BackingFile abc.PML
2. Once you are done you can issue the following command to stop the procmon :
procmon /Terminate
3. Now you can open the abc.PML file and check if there is any activity that is causing the issue.

You can even schedule two tasks to start/stop procmon at the specified time.

Observation
If you are able to setup breakpoints in the code and hit them but are unable to step-Into or Step-Through then there are chances that this attribute is added in your code.

How to get it worked
In most of the cases you can comment-out the lines of code for this attribute.

1.    Introduction.

Remote debugging is one of the most interesting features of Visual Studio and it has been greatly simplified in Visual Studio 2005. The purpose of this article is to discuss the basic functionality, configuration details, and troubleshooting steps required for a successful remote debugging session.

Why we need remote debugging?

Troubleshooting an application on development environment is not a preferred choice. Especially when we have deployed an application on a production server where Visual Studio is not installed. It becomes more difficult when there is something system specific. In such situations, Remote debugging is a solution.

2.    Remote Debugging components.

Before we start let’s try to understand what are the important components which play an important role in remote debugging.

Basically remote debugging works in a client-server architecture model. On the local machine there is devenv.exe (Visual Studio) and on the remote machine, the required component is msvsmon.exe( Visual studio remote debugging monitor).

Besides them there are several other components as well. Here is an article which gives a detailed list of Remote debugging components. Both managed and native debugging is supported.

These components are installed on the machine where Visual Studio 2005 is installed. And can be safely copied or shared to the remote machine.

These components are located at the following location:

Install path \Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\x86

Install path \Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\x64

Install path \Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\ia64

Sharing the components is the preferred choice.

For a successful communication between the local and remote machine, there are several ports under the hood that needs to be opened. If there is any firewall between the two systems then it needs to be configured.

3.    DCOM configuration

Remote access permissions for anonymous logon need to be setup on the machine where Visual Studio is installed. This can be done by using DCOM configuration tool (dcomcnfg.exe )

4.    Firewall Settings and security (Ports and permissions)

DCOM RPC uses TCP 135 and IPSec uses UDP 500 and UDP 4500. These ports must be opened on both the machines.

Moreover permissions needs to be set for file and print sharing and adding msvsmon(on remote machine) and devenv.exe(on the local machine) to the exception list in the firewall settings.  Here is an article which explains the steps.

5.    Workgroup or Domain - how machines are connected?

There are different network scenarios. Depending upon which we needs to check the network authentication and communication issues. Remote Debugging Across Domains .

6.    Managed or Unmanaged code (Is debugging mixed code possible)

Remote debugging is supported for both the managed and unmanaged code. However mixed code debugging or debugging managed and unmanaged code at the same time may not be stable. It is advisable to disable it How to: Enable Debugging of Unmanaged Code.

7.    User Rights

In order to have a successful communication, the user account on the local machine must map to the user account on the remote machine and vice-versa. The safest way is to check that both the users are the members of the administrator/Debugger group and have the same username and password. However, this is not compulsory.

8.    Authentication mode and No authentication – A threat to security?

Remote debugging in Visual Studio 2005 is supported in both the Authentication mode and no-Authentication mode. However no-authentication mode supports only the native code debugging.

No-authentication mode is faster but unsecured.

How to: Set Up Windows Authentication Mode 

How to: Set Up "No Authentication" Mode   

9.    Two remote Debugging scenarios

Remote debugging can be performed in two ways:

a.     To start a process from local machine, see Remote Debugging of a Project Built Locally 

b.    To attach to a process already running on remote machine, see How to: Select a Remote Machine

====================================

We can genererate PDB(Program Data Base) files for RELEASE build also.

Set “Project->Project Properties->Configuration Properties->Linker->Debugging->Generate Debug Info” to “Yes”.

Once you select this option, the next option “Generate Program Database File” will show the default path and name for the PDB file. If you build your solution it will generate <Targetname>.PDB file. This file will contain the debug info for the binary.

For generating the PDB in C#

=======================

Set “Project Properties -> Build -> Advanced…->Output -> Debug Info” to “PDB-only” or “Full”.

What are the two types of .PDB files?

==============================

There are two types of PDB files. One generated by the compiler named as VCx0.PDB(e.g. vc80.pdb), and another the <Targetname>.PDB.

The VCx0.PDB file is generated by the compiler and it is related to the .OBJ file. It contains the type information only.

The <Targetname>.PDB files are generated by the linker and it is related with the target executable or the DLL. This file contains the complete debug info. When we are debugging, we need this ‘.pdb’ file for aligning to the symbols. The timestamp of the target file and the PDB should match.

Problem Description
================

When you try to debug a simple windows application in Visual Studio 2005, you get the following error :

----------------------------------
Microsoft Visual Studio
----------------------------------
Unable to start program '<application_name>'.A debugger dll, msdbg2.dll, is not correctly installed. Please repair your Visual Studio installation via 'Add or Remove Programs' in control panel.

If the problem persists, you can manually register msdbg2.dll from the command prompt with 'regsvr32 "%CommonProgramFiles%\Microsoft Shared\VS7Debug\msdbg.dll"'.
----------------------------------
OK  
----------------------------------

Diagnostic
=======

We can use Debugger Diagnostic Tool to find out any error about this :

This Tool is available here.

In order to simulate the problem, i tried to rename the msdbg2.dll file on my system and then run the DebuggerDiagnostic tool. The output that i get on my system is the following :

C:\Documents and Settings\prabhatt\My Documents\MSDN\Debugger Diagnostics>DebuggerDiagnostics.exe

Begin 'CheckMDMImage()'
mdm.exe: version '7.10.3077' with hash '{6607858A-7B579EC3-E062DAB3-BF891368-CBF1CB9C}'.
Result of 'CheckMDMImage()' is '00000000'

Begin 'CheckMSDBG2Image()'
Could not calculate hash for 'msdbg2.dll' - 0x80070002
Result of 'CheckMSDBG2Image()' is '80070002'

...

Begin 'CoCreateMachineDebugManager(&spMachine)'
Result of 'CoCreateMachineDebugManager(&spMachine)' is '8007007e'

Analysing the report
===============

We found that the following portion is reporting some error :

Begin 'CheckMSDBG2Image()'
Could not calculate hash for 'msdbg2.dll' - 0x80070002
Result of 'CheckMSDBG2Image()' is '80070002'

It states that it is unable to calculate the HASH value of the msdbg2.dll. Which indicates that there might be some problem with this DLL.

Root Cause
=======

There are three causes of this issue :-
1. The dll is not present physically at the specified path.
2. The dll is corrupted due to some unknown reason.
3. The dll is not the original one that comes with Visual Studio.

Conflict/Corrupt or missing msdbg2.dll
=======================

Once we identify that there are some issues with this dll, lets start identifying what might be the reason.

1. Manually search for the file in the directory C:\Program Files\Common Files\Microsoft Shared\VS7Debug

Is the file present there? If no we need to install the file there and register it properly.

There are several public sites from where we can download, install and register it. Since these sites might not be safe. I would recommend you to try installing the files from the installation disks of Visual Studio that you have.

2. If the file is physically present there, then it might be corrupted. So go ahead and install the new file from the installation disk and register it.

3. One interesting thing is that Office XP installation and Office XP update KB833858 also contain the same file msdbg2.dll. So if by any chance, if this file is installed by accident to the directory(C:\Program Files\Common Files\Microsoft Shared\VS7Debug) then also we may get this issue. We can verify this by checking the version, the file that comes with Visual Studio 2005 has the version 8.0.50727.42. On the other hand the file that comes with Office XP update (KB833858) has the version 7.0.9466.0. If this is the case unregister the dll. Install the original one and register it.

How to Unregister a dll
==============

1. Start->Run->cmd.
2. At a command prompt, type the following command:
regsvr32 /u <path_of_msdbg2.dll>\msdbg2.dll 

How to Register a dll
=============

1. Start->Run->cmd.
2. At a command prompt, type the following command:
regsvr32 <path_of_msdbg2.dll>\msdbg2.dll 

Lets first start with a basic understanding of IntelliSense Support in Visual C++

What is the issue?

1. Intellisense doesn’t work at all.
2. Intellisense is very slow(Giving Updating Intellisense… in status bar)
3. Intellisense fails causing Visual Studio to exit or Hang forever.
4. Intellisense doesn’t work for a part of the solution.

1. Verifying Intellisense issue (or Disabling Intellisense)

There are chances that we are misinterpreting some issues with Intellisense. We can verify this by disabling Intellisense in VC++. There is a file called feacp.dll in <VS8INSTALL>\VC\vcpackages folder. Renaming this file will disable Intellisense feature.

After disabling, if we can work with the IDE without any other issue then we can say for sure that Intellisense is causing the problem.

2. Is there any corrupt file(s)

If you are having some intellisense issues related with Project References, then you may also need to check the version of both the feacp.dll and vcpkg.dll files.

Here is a related KB article which links to the latest version of fix for this issue :

The intention to point to this article here is to get an understanding that these files are responsible for intellisense issues.

3. Updating Intellisense – IDE hangs

This is a very common issue with intellisense and it may occur due to a variety of reasons. There are two scenarios, either the intellisense returns after a long time or it doesn’t return at all.
The recommended way is to check for NCB corruption and also getting the ACPLOG.

4. NCB file corruption

In some circumstances, NCB file becomes corrupted and thus the PARSER is unable to proceed resulting HANGS. Sometimes by deleting the NCB, the problem is resolved. But it may be a temporary workaround. The permanent solution is to find out which part of our code is causing failure.

5. ACPlog

We can generate a log file to findout the reasons behind the failure of parser. The ACPLOG can be generated from the Visual Studio IDE by adding the following option :
 
/acplog:<file_name_with_complete_path>

If we build the solution, it will generate the log in the specified file. This is an ordinary text file which we can open in Notepad and can identify which part of our code is causing the parser to behave abnormally.

6. Intellisense and XML documentation

Intellisense is also helpful in generating XML code comments. For example if we press three slashes(///), it will automatically add the code comments and may also try to include the elements very similar to the way we add variable in our code.

Supplying XML Code Comments

I have encountered a case in which Intellisense was not responding after adding CDATA to XML documentation.

When customer complaints about the XML documentation code comments then it might be due to the Intellisense feature.

7. Intellisense and network build 

Building a project/solution over network is unsupported. It may encounter Intellisense issue.

8. Is there any add-ins that the customer is using?

Removing the add-in might resolve the issue.

9. Opening a project when intellisense is busy?

If Intellisense is in the middle of updating and if you open a different project by File->Recent projects, the IDE hangs and never comes back. 
It is suggested to wait for Intellisense to finish its work.

10. Is there any antivirus installed?

Try disabling the antivirus. There might be some conflict.

11. Running Visual Studio in safemode.

The safemode option in Visual Studio(Start->Run->devenv /safemode) ensures that no additional third party add-ins are loaded when VS starts. This helps us to isolate Visual Studio conflicts with other third party applications/addins.

/SafeMode (devenv.exe)

 12. Is it a bug?

Last but not the least, it would be a good idea to check List of bugs that are fixed in Visual Studio 2005 Service Pack 1

Most of the known issues with Intellisense are going to be fixed very soon. You can contact Microsoft Support to get a hotfix.

Some good links

 Troubleshooting IntelliSense in C++ Projects 

 When IntelliSense Is Unavailable

 Testing the IntelliSense engine

Problem Description
================

When you try to debug a simple windows application in Visual Studio 2005, you get the following error :

----------------------------------
Microsoft Visual Studio
----------------------------------
Unable to start program '<application_name>'.A debugger dll, msdbg2.dll, is not correctly installed. Please repair your Visual Studio installation via 'Add or Remove Programs' in control panel.

If the problem persists, you can manually register msdbg2.dll from the command prompt with 'regsvr32 "%CommonProgramFiles%\Microsoft Shared\VS7Debug\msdbg.dll"'.
----------------------------------
OK  
----------------------------------

Diagnostic
=======

We can use Debugger Diagnostic Tool to find out any error about this :

This Tool is available at :

http://download.microsoft.com/download/a/6/f/a6f1de85-7284-4c97-9ddd-6f18000f5848/DebuggerDiagnostics.msi

In order to simulate the problem, i tried to rename the msdbg2.dll file on my system and then run the DebuggerDiagnostic tool. The output that i get on my system is the following :

C:\Documents and Settings\prabhatt\My Documents\MSDN\Debugger Diagnostics>DebuggerDiagnostics.exe

Begin 'CheckMDMImage()'
mdm.exe: version '7.10.3077' with hash '{6607858A-7B579EC3-E062DAB3-BF891368-CBF1CB9C}'.
Result of 'CheckMDMImage()' is '00000000'

Begin 'CheckMSDBG2Image()'
Could not calculate hash for 'msdbg2.dll' - 0x80070002
Result of 'CheckMSDBG2Image()' is '80070002'

...

Begin 'CoCreateMachineDebugManager(&spMachine)'
Result of 'CoCreateMachineDebugManager(&spMachine)' is '8007007e'

Analysing the report
===============

We found that the following portion is reporting some error :

Begin 'CheckMSDBG2Image()'
Could not calculate hash for 'msdbg2.dll' - 0x80070002
Result of 'CheckMSDBG2Image()' is '80070002'

It states that it is unable to calculate the HASH value of the msdbg2.dll. Which indicates that there might be some problem with this DLL.

Root Cause
=======

There are three causes of this issue :-
1. The dll is not present physically at the specified path.
2. The dll is corrupted due to some unknown reason.
3. The dll is not the original one that comes with Visual Studio.

Conflict/Corrupt or missing msdbg2.dll
=======================

Once we identify that there are some issues with this dll, lets start identifying what might be the reason.

1. Manually search for the file in the directory C:\Program Files\Common Files\Microsoft Shared\VS7Debug

Is the file present there? If no we need to install the file there and register it properly.

There are several public sites from where we can download, install and register it. Since these sites might not be safe. I would recommend you to try installing the files from the installation disks of Visual Studio that you have.

2. If the file is physically present there, then it might be corrupted. So go ahead and install the new file from the installation disk and register it.

3. One interesting thing is that Office XP installation and Office XP update KB833858 also contain the same file msdbg2.dll. So if by any chance, if this file is installed by accident to the directory(C:\Program Files\Common Files\Microsoft Shared\VS7Debug) then also we may get this issue. We can verify this by checking the version, the file that comes with Visual Studio 2005 has the version 8.0.50727.42. On the other hand the file that comes with Office XP update (KB833858) has the version 7.0.9466.0. If this is the case unregister the dll. Install the original one and register it.

How to Unregister a dll
==============

1. Start->Run->cmd.
2. At a command prompt, type the following command:
regsvr32 /u <path_of_msdbg2.dll>\msdbg2.dll 

How to Register a dll
=============

1. Start->Run->cmd.
2. At a command prompt, type the following command:
regsvr32 <path_of_msdbg2.dll>\msdbg2.dll