APP: Performance Issue (specific to a process)


Description: An application performance issue is generally defined as an application or process performing below expectations. This can be due to high CPU usage, high memory usage or slow performance. This topic is specifically for an application or process with a performance issue, and not the overall operating system.


Scoping the Issue:  First, determine the exact symptom you are experiencing. Is the application causing higher CPU usage than expected, performing data operations slowly or using too much memory?

If the application is using high CPU, try to determine if this is a constant situation or only when the application is doing something specific. Capturing a Performance Monitor log while the application is running might shed some light on the problem, and will most likely be asked for by the Microsoft engineer. You can also use a tool like Process Explorer to see real-time information on what a specific process is doing. This can be accomplished by running Process Explorer and viewing the Threads tab for the process in question. Keep in mind that you must configure debug symbols for this to work.

If the application is not performing up to expectations, but is not using high CPU or out of memory, the issue is most likely due to some sort of coding issue. If the process runs more slowly on a certain operating system, then the vendor of the application should be contacted to determine which part of their code path is performing below par. They can then work with our Developer Support group to determine if they are using the appropriate functions or methods in their code. Collecting a Performance Monitor log may assist in determining if there is an underlying problem causing this, such as network slowness or disk latency issues.

If it is determined that the application is performing slowly due to excessive memory usage, it is possible that the application is experiencing a memory leak or causing excessive paging due to load. Capturing Performance Monitor data, while the issue is occurring may be useful in these instances.

Data Gathering:  In all instances, collecting either MPS Reports with the General, Internet and Networking, Business Networks and Server Components diagnostics, or a Performance-oriented MSDT manifest must be done.  Additional data required will most likely involve a Performance Monitor log during an instance of the problem, and any application-specific error logs.  In some instances we may require dump files to be collected.

Troubleshooting / Resolution:  After you have gathered the data, there are some things to check:

  • MPS Reports:

    • Review the Event Logs for relevant events occurring at the time of the issue

    • You should also check the Event Logs and Windows Update logs to see if there were any application updates or patches that preceded the unexpected behavior – there may be a correlation

  • Process Explorer: If you have the opportunity to do so, it may be worth using Process Explorer to examine what an unresponsive application is doing while it is in-state

  • Dump File Analysis:  If you are experienced at looking at dump files, there are some things that you can look for, such as threads using high CPU, long-running threads or memory usage within the process

Finally – where the application in question is either a custom in-house application or a third-party (non-Microsoft) application, you should always engage either your developer or the application vendor for assistance.  The reason for this is that we do not have access to the application’s source code or symbols – so our debug analysis may be incomplete.  If the application is an in-house application (for example a .NET application) you should open a case with our developer support group for assistance.