ASP.NET Debugging : ASP.NET Tip

ASP.NET Tip: Understanding the caching of data in SOS

Tom — Wed, 08 Oct 2008 13:00:00 GMT

The sos that comes with the debugger, in the clr10 directory, has a lot of additional features and speed improvements for .NET 1.x troubleshooting. One of the main ways it does this is by caching the data that is gathered from !DumpHeap -stat.

This is something important to remember if something happens where the command is run, but then something happens so that the cache isn't fully correct. For example, if you are opening a dump on a remote share and some network issue happens, the cache will only be a partial cache. If you try to run any commands that depend on that cache, they will only give partial output since the cache isn't complete.

The only way to resolve this is to unload the debugger extension (SOS) and reload it. Then the cache will be recreated.

One other point of note along these lines. If you are debugging a live process, it does not cache the data. This is because normally you will run a command, let the process run some, and then run it again. You don't want stale data when you re-run the commands.

One side-note, if you run !DumpHeap -stat a second time against a live process, you will see an additional column of output. This is showing you the change from the last time the command was run. This can be helpful to quickly see how much things have changed.

ASP.NET Tips: Careful Use of Static's

Tom — Thu, 18 Sep 2008 13:00:23 GMT

Not sure how many people realize it, but when you start dealing with multiple users access a system (in this case a web server), you have to be very careful what you store in static's (global variables). This is because all the users will have access to this data and so if you create a page, you could allow them to see data that they shouldn't.

The main place this comes into play is with SQL data. We recommend that you cache data from the database so you don't have to query for it on each request. But if that data is sensitive, then you need to make sure you do not store it in cache or some other global.

Improving Time-Critical Code written in C

Tom — Tue, 02 Sep 2008 13:00:33 GMT

Writing web pages is very similar to writing any other type of code. You have to understand how it is going to be used and where you need to really make things run as quickly as possible.

There are a number of tips on this blog already that deal with managed code and ways to optimize it. But one of the things that we don't look at as often are other areas of code that we are dependant on. For example, if you P/Invoke a native function, whatever it is doing, is something that you need to be aware of. Because there is a lot of native functionality that is still available to us, I wanted to remind everyone of some of the tips you can use when dealing with C/C++ code.

A great place to start is with: Tips for Improving Time-Critical Code. While most of these things don't apply to .NET based code, they are all very important when working with native code. Another useful thing to be aware of is what the compiler can do for you. For example, take a look at Optimizing Your Code with Visual C++.

Feel free to add your own tips or pointers here. I'd like to get a good collection going and then I can share that out as well.

ASP.NET Tip: Keep hidden files hidden

Tom — Tue, 26 Aug 2008 13:00:00 GMT

I have seen a few cases of this so I wanted to let everyone know. If you install the FrontPage Server Extensions (FPSE) on a web server, it will install some configuration files in a directory under your web site called _vti_cnf. This folder contains a bunch of files that FPSE use to update files and perform the various tasks that it needs to do.

The problem comes if that _vti_cnf folder is not marked hidden. If something keeps that from happening, you can get a few different errors because of it. The reason is that the aspnet_compiler.exe will try to compile these files since the folder isn't hidden. There is a web.config file in there that will cause an error like:

Invalid token 'Text' at root level of document.
XML document must contain a root level element.
Data at the root level is invalid. Line 1, position 1.

As long as this folder is hidden, the compiler will just skip over it and everything will be fine.

So the main thing to remember is that if you install FPSE and suddenly start getting errors, checking if that folder is marked hidden is a great place to start.

ASP.NET Tip: ASP.NET MSDN Site

Tom — Wed, 20 Aug 2008 13:00:00 GMT

Have you checked out the MSDN site for ASP.NET lately? It is full of useful information. You can find it at the ASP.NET Developer Center. My favorite things to check out are the “How Do I” videos. They can be really helpful and can get you started on a specific topic. Check them out, “How Do I” videos – ASP.NET.

I’ suggest checking back to that site from time to time to look for updates. There are a lot of useful things that show up on that page, including some interesting blog postings and all kinds of updates around ASP.NET.

Another interesting link is to the forum talking about ASP.NET Futures. This is really cool stuff if you haven’t heard about it, stuff like:

ASP.NET AJAX Extensions
Dynamic Data Controls
Silverlight Controls for ASP.NET
ASP.NET Dynamic Language Support
Search and Diagnostics Application Services

Hope you find those sites helpful.

ASP.NET Tips: Loading a DLL out of the bin directory

Tom — Mon, 21 Jul 2008 13:00:00 GMT

Question

A customer has created a web project which references a class library project. When deployed to the local machine the web/classes all work fine. When deployed to a ‘shared’ IIS site, the class DLLs exist in the /bin folder, but the web page generates an error:

can’t find file “Documents and settings/….”

when trying to access the class DLL.

Is there a special setup to make the web pages look in its /bin folder?

Answer

There isn’t usually anything needed in order to make this scenario work. But if it isn’t working for you, there are two choices here. If you are in ASP.NET, most likely the cause is that you don’t have the following entry in the machine.config prior to 2.0 and the root web.config file (in the same folder as machine.config) for 2.0 and later:

<compilation>
  <assemblies>
    <add assembly="*"/>
  </assemblies>
</compilation>

The other way to do this, if you aren’t using ASP.NET, is to add the bin directory to your path for the application. The way this is accomplished is with the probing element:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="bin;bin2" />
    </assemblyBinding>
  </runtime>
</configuration>

This is documented here: <probing> Element

There has been a situation where neither of these worked. We are still researching that situation and I will update this post when we have another solution.

ASP.NET Tips: Using Process Explorer to help with high CPU

Tom — Tue, 24 Jun 2008 13:00:00 GMT

I am not sure how many people are familiar with the great tools that Mark and the Sysinternals folks have created, but this is one that is a must for monitoring the performance of your machine. It is called Process Explorer. With it, you can see what is taking up your CPU time in real time as well as which process has what handles or DLL’s open.

This tool can be used with ASP.NET to keep a quick eye on the performance of your web server. You can add it to your startup folder so it always starts and you can watch things progress in your server and make sure things don’t get out of control. For a great video on using this tool, check out: The case of the Unexplained. You can also check out Mark’s blog for many examples that use Process Explorer. This tool has saved me a lot of time in tracking down performance issues and a lot of the time, you can use it instead of needed to attach a debugger or look at a dump.

I would highly suggest watching the video or checking out Mark’s blog for more details and to see if you can apply the same things to your environment.

ASP.NET and Performance

Tom — Mon, 23 Jun 2008 21:29:34 GMT

I wanted to talk about monitoring performance in ASP.NET for a bit. I have already posted a few postings that talk around this issue, namely:

But there are some other things to keep in mind. The best place to look for information on how to watch the performance of an ASP.NET Application is in the “Improving .NET Application Performance” guide on MSDN. Specifically Chapter 15 – Measuring .NET Application Performance. There are a lot of other very useful pieces of information in this. So I would suggest you review any Chapter that applies to your application.

If you want to get a description of all the counters, check out: Performance Counters for ASP.NET and Memory Performance Counters

As for how to capture the perfmon data (perfmon is the tool that we use to capture the performance information), take a look at my various posts around the different situations. This goes through what counters are important in each situation:

ASP.NET Tips- What to gather to troubleshoot

The main ones to keep an eye on are the memory counters (to watch if memory is staying under control or becoming unbounded) and the ones around the ThreadPool (Queuing, Request Execution Time, etc) to make sure things aren’t getting queued up or blocked in some manner.

ASP.NET Tips: What to gather to troubleshoot

Tom — Wed, 21 May 2008 18:38:59 GMT

So now that I am done with all the individual posts, I thought I would wrap them all together. So here are all of the posts that I created on gathering information when you are having a problem.

Please keep in mind that these are geared towards the type of information you would be sending to Microsoft Support. So if you are troubleshooting something yourself, you have have some better methods, such as Tracing or Logging.

So without further ado, here is the complete list:

Hope that these are useful to everyone and hope that you can put these to use. If you think there is a situation that I haven’t covered, please let me know and I will add it also.

ASP.NET Tips: What to gather to troubleshoot - part 6 - Recycle due to memoryLimit

Tom — Tue, 20 May 2008 19:03:04 GMT

Here is another situation that you may come across and what to do in order to gather information about it.

The following steps will configure DebugDiag to automatically capture a memory dump of the ASPNET_WP.exe process recycling when it exceeds the memoryLimit. This only applies to the ASPNET_WP.exe process, so if using w3wp.exe, this doesn't apply. The following event is logged when this occurs:

aspnet_wp.exe xxx was recycled because memory 
consumption exceeded 60% of available RAM

Before the issue occurs

A. Download DebugDiag:
====================

Install the Debug Diagnostic tool
The default installation location for the package is C:\Program Files\DebugDiag. It can be changed.
Make sure any other monitoring and debugging tools are not running.

B. Create a Performance Monitor log:
====================================

Expand Performance Logs and Alerts
Right Click on Counter Logs
Choose New Log Settings...
Enter a descriptive name
Note the log file location for later (or go to the Log Files tab and change the location)
Click the Add button
Click the All Counters and All Instances radio buttons
Select the following from the Performance Object dropdown, being sure to Add each one as you select it:
- Process
- Thread
- Processor
- Memory
- .NET CLR Data
- .NET CLR Exceptions
- .NET CLR Interop
- .NET CLR Jit
- .NET CLR Loading
- .NET CLR LocksAndThreads
- .NET CLR Memory
- .NET CLR Networking
- .NET CLR Remoting
- .NET CLR Security
- ASP.NET
- ASP.NET Applications
Click Close
Click OK

For the ASP.NET counters, select the version that you are wanting to monitor. Ex. For 1.1 framework, select ASP.NET v1.1.4322 and ASP.NET Applications v1.1.4322.

Note: For more information on Performance monitor, see KB 248345

C. Configure server for the High Memory Event
==================================

Add the following registry keys. These were added to the .NET Framework so that a breakpoint exception will be thrown when the process recycles due to the above event.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET
DWord: DebugOnHighMem
Value: 1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET
DWord: UnderDebugger
Value: 0

C. Configure DebugDiag
===================

Configure DebugDiag to capture the memory dump when the BreakPoint Exception is thrown and when the process stops.

Open DebugDiag
On the Rules tab, click Add Rule
Select Crash and click Next
Select All IIS Processes and click Next
Click Advanced Exception Configuration
Click Add Exception
Select Breakpoint Exception, change Action Type to Full UserDump
Click OK
Click Save and Close
Click Advanced Breakpoint Configuration
Click Add Breakpoint
Type KERNEL32!ExitProcess and change Action Type to Full UserDump
Click OK
Click Save and Close
Click Next through the rest of the wizard

Inject LeakTrack.dll to capture native leak information:

Click the Processes tab
Right-click the ASPNET_WP.exe process, select Monitor for leaks

After the issue occurs

The memory dump will automatically get captured.

A. Stop the Performance Monitor log
===================================

In Performance Monitor:

Right click on your log that is now listed under Counter Logs
Choose Stop Log

ASP.NET Tips: What to gather to troubleshoot - part 5 - OutOfMemoryException

Tom — Mon, 19 May 2008 17:49:41 GMT

So we already talked about what to gather when you are experiencing high memory. But what if you are actually getting a System.OutOfMemoryException? Here is how you capture a dump at the time you are running out of memory.

The following steps will configure DebugDiag to automatically capture the memory dump when the System.OutOfMemoryException occurs.

Before the issue occurs

A. Download DebugDiag:
====================

Install the Debug Diagnostic tool
The default installation location for the package is C:\Program Files\DebugDiag. It can be changed.
Make sure any other monitoring and debugging tools are not running.

B. Create a Performance Monitor log:
====================================

Expand Performance Logs and Alerts
Right Click on Counter Logs
Choose New Log Settings...
Enter a descriptive name
Note the log file location for later (or go to the Log Files tab and change the location)
Click the Add button
Click the All Counters and All Instances radio buttons
Select the following from the Performance Object dropdown, being sure to Add each one as you select it:
- Process
- Thread
- Processor
- Memory
- .NET CLR Data
- .NET CLR Exceptions
- .NET CLR Interop
- .NET CLR Jit
- .NET CLR Loading
- .NET CLR LocksAndThreads
- .NET CLR Memory
- .NET CLR Networking
- .NET CLR Remoting
- .NET CLR Security
- ASP.NET
- ASP.NET Applications
Click Close
Click OK

For the ASP.NET counters, select the version that you are wanting to monitor. Ex. For 1.1 framework, select ASP.NET v1.1.4322 and ASP.NET Applications v1.1.4322.

Note: For more information on Performance monitor, see KB 248345

C. Configure server to capture OutOfMemoryException
===========================================

Add the following registry key. This was added to the .NET Framework so that a breakpoint exception will be thrown when an OutOfMemory condition occurs. This is documented in the following article:

820745 Failfast occurs when you experience an "out of memory" condition

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\
DWord: GCFailFastOnOOM
Value: 2

D. Configure DebugDiag
===================

Configure DebugDiag to capture the memory dump when the BreakPoint Exception is thrown and when the process stops.

Open DebugDiag
On the Rules tab, click Add Rule
Select Crash and click Next
Select All IIS Processes and click Next
Click Advanced Exception Configuration
Click Add Exception
Select Breakpoint Exception, change Action Type to Full UserDump
Click OK
Click Save and Close
Click Advanced Breakpoint Configuration
Click Add Breakpoint
Type KERNEL32!ExitProcess and change Action Type to Full UserDump
Click OK
Click Save and Close
Click Next through the rest of the wizard

Inject LeakTrack.dll to capture native leak information:

Click the Processes tab
Right-click the ASPNET_WP.exe process (or w3wp.exe if running in IIS 6), select Monitor for leaks

After the issue occurs

The memory dump will automatically get captured when the OutOfMemoryException is thrown.

A. Stop the Performance Monitor log
===================================

In Performance Monitor:

Right click on your log that is now listed under Counter Logs
Choose Stop Log

ASP.NET Tips: What to gather to troubleshoot - part 3a - Crash revisited

Tom — Thu, 15 May 2008 18:11:23 GMT

In the previous post around capturing a dump for a crash, we were talking about using DebugDiag. But what if we can't use this tool. There are various reasons for this, maybe we don't want to have it installed on the server, or maybe we are trying to capture a 64-bit process (which DebugDiag doesn't yet work against).

In either of these cases, the best option is to use adplus. This is a tool that comes with the debugger package. But the question is, how do you capture the correct dump? If you look at the help for adplus, you will notice that it has a -crash switch. So you may be tempted to just attach to the process using that switch. The problem is that this will most likely catch a 1st chance process shutdown dump. These dumps consist of a single thread and everything else in the process is gone. Often times, .NET is unloaded already. A dump at this point doesn't tell us anything. So we need to catch it sooner.

ADPLUS Config File

Adplus has the ability to run with all of it's settings being loaded from a config file. In this case, what we want to do is catch the process with it is calling either TerminateProcess or ExitProcess. At this point, nothing is shut down yet and we can see what happened. So how do we set this up? Well, we can use a config file. So just create a text file with the following lines in it and save it as Adplus_Crash.cfg:

<ADPlus>      <!--
      Configuring ADPlus to log, list the stack and create full dump
     when kernel32!ExitProcess is called
     To define an output directory uncomment the line in the Settings section
       changing the directory to the one you want to use
     -->
   <Settings>
       <RunMode> CRASH </RunMode>
   <SympathPlus> SRV*c:\symbol_cache*http://msdl.microsoft.com/download/symbols;c:\symbols_os</SympathPlus>
       <!-- <OutputDir> c:\Dumps </OutputDir>  -->
   </Settings>
    <!-- defining breakpoints -->
    <Breakpoints>
       <NewBP>
           <Address> kernel32!ExitProcess </Address>
           <Actions> Log;Stacks;FullDump  </Actions>
       <ReturnAction> Q </ReturnAction>
       </NewBP>
       <NewBP>
           <Address> kernel32!TerminateProcess </Address>
           <Actions> Log;Stacks;FullDump  </Actions>
       <ReturnAction> Q </ReturnAction>
       </NewBP>
    </Breakpoints>
     <Exceptions>
         <!-- options act on all currently defined exceptions -->
        <Option>  NoDumpOnFirstChance  </Option>
     </Exceptions>

</ADPlus>

So how do we go about running adplus with this config file? We simply run:

adplus -c "c:\Adplus_Crash.cfg" -iis

That is all we need to do in order to capture the dump and get valid data.

ASP.NET Tips: What to gather to troubleshoot - part 4 - Deadlocks

Tom — Wed, 14 May 2008 18:35:09 GMT

There are two ways to gather data in a Deadlock situation. If you are using Windows 2003 or later (IIS 6.0 or later), then follow the steps in the KB 828222

If you are using an older version of IIS, then follow the steps below:

Before the issue occurs

A. Download DebugDiag:
======================

Install the Debug Diagnostic tool
The default installation location for the package is C:\Program Files\DebugDiag. It can be changed.
Make sure any other monitoring and debugging tools are not running.

B. Create a Performance Monitor log:
====================================

Expand Performance Logs and Alerts
Right Click on Counter Logs
Choose New Log Settings...
Enter a descriptive name
Note the log file location for later (or go to the Log Files tab and change the location)
Click the Add button
Click the All Counters and All Instances radio buttons
Select the following from the Performance Object dropdown, being sure to Add each one as you select it:
- Process
- Thread
- Processor
- Memory
- .NET CLR Data
- .NET CLR Exceptions
- .NET CLR Interop
- .NET CLR Jit
- .NET CLR Loading
- .NET CLR LocksAndThreads
- .NET CLR Memory
- .NET CLR Networking
- .NET CLR Remoting
- .NET CLR Security
- ASP.NET
- ASP.NET Applications
Click Close
Click OK

For the ASP.NET counters, select the version that you are wanting to monitor. Ex. For 1.1 framework, select ASP.NET v1.1.4322 and ASP.NET Applications v1.1.4322.

Note: For more information on Performance monitor, see KB 248345

C. Running the 1.0 version of the framework?====================================

If you are running the 1.0 version of the framework you need to do the following before continuing:

Install .Net framework 1.0 SP2 (Skip this step if you are running .Net Framework 1.1)

SP2 of .Net framework 1.0 can be downloaded from: http://msdn.microsoft.com/netframework/downloads/sp/download.asp
Install the hotfix 329956. This fix resolves an issue of the process recycling due to a false deadlock.

D. Configure server to capture Deadlock
================================

Add the following registry key. This was added to the .NET Framework so that a breakpoint exception will be thrown when the deadlock occurs. This is documented in the following article:

325947 Event ID 1003 with ASP.NET Deadlock

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET
DWord: DebugOnDeadlock
Value: 2

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET
DWord: UnderDebugger
Value: 0

E. Configure DebugDiag
===================

Configure DebugDiag to capture the memory dump when the BreakPoint Exception is thrown and when the process stops.

Open DebugDiag
On the Rules tab, click Add Rule
Select Crash and click Next
Select All IIS Processes and click Next
Click Advanced Exception Configuration
Click Add Exception
Select Breakpoint Exception, change Action Type to Full UserDump
Click OK
Click Save and Close
Click Advanced Breakpoint Configuration
Click Add Breakpoint
Select KERNEL32!ExitProcess and change Action Type to Full UserDump
Click OK
Click Save and Close
Click Next through the rest of the wizard

After the issue occurs

The memory dump will automatically get captured when the Deadlock occurs.

A. Stop the Performance Monitor log
===================================

In Performance Monitor:

Right click on your log that is now listed under Counter Logs
Choose Stop Log

ASP.NET Tips: What to gather to troubleshoot – part 3 – Crash

Tom — Tue, 06 May 2008 18:39:51 GMT

Defining an IIS Crash

A Crash in IIS occurs when an IIS process (INETINFO.EXE, DLLHOST.EXE, W3WP.EXE) terminates unexpectedly. A Crash typically happens when there is an Unhandled Exception caused by an Access Violation, Stack Overflow, etc. In these situations, the operating system catches the exception and terminates the process.

Dr. Watson is the default debugger to monitor for process failures in Windows. It can generate a Dump File and a Log File to document a failure in a process. Run drwtsn32 from Start -> Run to view the settings and file location. You can then look at the drwtsn32.log and user.dmp files.

To troubleshoot, we attach a debugger to the process and catch the exception before the operating system.

Troubleshooting Steps

1. Install the Debug Diagnostic tool

http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1286

The default install path is C:\Program Files\DebugDiag and can be changed during the installation.

2. Check Leave Running When Idle (IIS5, IIS5.1) with the following steps:

a) Open Component Services (Start -> Programs -> Administrative Tools -> Component Services)

b) Expand Component Services, expand Computers, expand My Computer, and expand COM+ Applications

c) For any custom packages or web sites/directories:

i) Right-click and choose Properties

ii) Go to the Advanced Tab

iii) Check Leave Running when Idle

iv) Click OK

3. Uncheck Debug Exception Catching (IIS5 and IIS5.1) with the following steps:

a) Open the MMC for IIS

b) Right-click the computer name and click Properties

c) Click the Edit button for the Master WWW properties

d) Go to the Home Directory tab

e) Click the Configuration button towards the bottom

f) Go to the Process Options tab and uncheck Enable Debug Exception Catching

g) Click OK

4. Disable Health Monitoring (IIS6) with the following steps:

a) Open the MMC for IIS and expand Application Pools

b) Right-click the Application Pool and click Properties

c) Recycling tab: Uncheck all Recycle worker process settings

d) Performance tab: Uncheck Shutdown worker processes after being idle for

e) Health tab: Uncheck Enable rapid-fail protection and Enable pinging

f) Click OK

5. Restart IIS

6. Create a Crash Rule with the following steps:

IIS5

a) Open DebugDiag (Start -> Programs –> Debug Diagnostics Tool 1.1)

b) Select Crash and click Next

c) Select the desired Target Type and click Next

d) Click Breakpoints…

e) Click Add Breakpoint…

f) For Breakpoint Expression, select ComSvcs!ComSvcsExceptionFilter

g) For Action Type, select Full Userdump and click OK

h) Click Save and Close and click Next

i) Click Next for Rule Name. The Userdump Location can be changed here.

j) Select Activate the rule now and click Finish

IIS6

a) Open DebugDiag (Start -> Programs -> Debug Diagnostics Tool 1.1)

b) Select Crash and click Next

c) Select the desired Target Type and click Next

d) Click Next in Advanced Configuration (Optional)

e) Click Next for Rule Name. The Userdump Location can be changed here.

f) Select Activate the rule now and click Finish

Notice the Status is Active. The Userdump Count will increase each time a dump file is created.

7. Analyze the Dump by selecting the Advanced Analysis tab and clicking Add Data Files. When the .dmp is added, select the Crash/Hang Analyzers script and click Start Analysis. When finished, a report (.mht) will be created in C:\Program Files\DebugDiag\Reports and displayed in Internet Explorer with the results and recommendations. If using custom DLL’s, the Symbol path (Tools menu -> Options and Settings -> Symbol Search Path) to the custom PDB files can be added.

8. Compress the Data using DebugDiag (Tools menu -> Create Increment Cabinet File) and analyze this file.

ASP.NET Tips: What to gather to troubleshoot – part 2 – High Memory

Tom — Mon, 05 May 2008 16:28:54 GMT

Identifying a Memory leak

A Memory Leak in an IIS process (INETINFO.EXE, DLLHOST.EXE, W3WP.EXE) occurs when Memory Usage in Task Manager continues to consume more than 50% of the physical RAM until running out of system memory or until the process stops functioning.

On heavily-used sites, a continuous growth in memory over the first 24 hours of use is normal. IIS caches much of its data and the TTL on the cache is 24 hours. Since IIS typically uses 50% of available physical RAM (per IIS Process; not the total of all IIS Processes), use this as a guide to identify a memory problem. The steps below will help troubleshoot a memory leak by gathering a memory dump of the leaking process.

Important Questions

How much RAM is on the machine?
How much RAM does the leaking IIS process take?
How long does it take to reproduce?

Troubleshooting Steps

1. Install the Debug Diagnostic tool

http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1286

The default install path is C:\Program Files\DebugDiag and can be changed during the installation.

2. Set up Performance Monitor Logging before the issue occurs:

a) Open DebugDiag (Start -> Programs –> Debug Diagnostics Tool 1.1)

b) Go to the Tools menu -> Options and Settings

c) Select the Performance Log tab

d) Click "Enable Performance Counter Data Logging"

e) Click OK

Note: The Data Sampling Interval and time to start monitoring is subjective to when the memory leak reproduces. Due to the log size, work with your Support Professional on a solution where we get the information needed while not overwhelming the server.

3. Create a Memory and Handle Leak Rule with the following steps:

a) Open DebugDiag (Start -> Programs -> Debug Diagnostics Tool 1.1)

b) Select "Memory and Handle Leak" and click Next

c) Select the leaking Process and click Next

d) In “Configure Tracking Duration”, a Warm-Up time can be specified but if the issue reproduces immediately, select “Start memory tracking immediately”. For “Tracking Time”, specify the time it will take to reproduce the issue. At the end of the specified time, a dump will be created. Make sure “Auto-create a crash rule” is checked.

e) Click Next

f) Click Finish for "Rule Name". The "Userdump Location" can be changed here.

Notice the Status is Active. The Userdump Count will increase each time a dump file is created.

4. Get the Data Manually if you are not sure when the leak will occur. In DebugDiag, go to the Processes tab, right-click the leaking process and select “Monitor For Leaks”. When the process gets up to 60%-80% of RAM, right-click the leaking process and select "Create Full Userdump”.

5. Stop PerfMon Logging after the dump has finished:

a) Open DebugDiag (Start -> Programs –> Debug Diagnostics Tool 1.1 )

b) Go to the Tools menu -> Options and Settings

c) Select the Performance Log tab

d) Click "Disable Performance Counter Data Logging"

e) Click OK

6. Analyze the Dump by selecting the "Advanced Analysis" tab and clicking "Add Data Files". When the .dmp is added, select the "Memory Pressure Analysis” script and click "Start Analysis". When finished, a report (.mht) will be created in C:\Program Files\DebugDiag\Reports and displayed in Internet Explorer with the results and recommendation. If using custom DLL’s, the Symbol path (Tools menu -> Options and Settings -> Symbol Search Path) to the custom PDB files can be added.