This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice. This article is not considered official documentation for K2 software and is provided "as is" with no warranties.
There are 2 types of memory dumps that you can take:
- Hang Dump: A hang is when a software program becomes unresponsive. If you open the Windows task manager, the program still displays in the task manager, but doesn't consume high CPU power and doesn’t serve any new pages.
- Crash Dump: A crash is when a software program stops working and then closes. When this occurs, Windows usually creates an entry in the event log to help diagnose the problem.
You may notice that the K2 Service is using a high amount of resources on your environment, and that your CPU and Memory usage are "spiking", which results in poor performance on your environment.
Or, you may notice that your K2 Server stops unexpectedly.
1. Get a copy of Debug Diag 2 Analysis
2. In Debug Diag there are 5 different Analysis Rules
- CrashHangAnalysis - Crash and Hang Analysis with specific reporting for ASP, .net, WCF, IIS and more
- DotNetMemoryAnalysis - Managed Memory Analysis (Beta version)
- MemoryAnalysis - Memory Analysis including Leaktrack and heap info reporting
- PerfAnalysis - Performance analysis for multiple consecutive dumps of the same process
- SharePointAnalysis - Crash and Hang Analysis with specific reporting for SharePoint
For more information regarding these rules please visit the following:
3. For these troubleshooting steps, we will be using: Default Analysis > CrashHangAnalysis:
4. Click on the 'Add Data Files' button and select the Crash or Hang Memory Dump:
5. Click on 'Start Analysis' and let Debug Diag run its Analysis
6. Once completed, an Internet Explorer page will open with a message at the bottom warning about restrictions on the web page - Click on 'Allow blocked content':
The report is saved in your documents, this can be attached to the ticket if a developer needs to further analyze the issue.
7. At the top of the report there are 4 sections (Error / Warning / Information / Notification) - Clicking on any of these will navigate you to the relevant sections:
A process crash is usually indicative of an unhandled exception occurring in a process or code running in a process that actively terminates the process.
Click on the Error section to review the error that caused the crash.
Example of Error:
A process hangs when it stops responding completely or takes a long time to respond. Sometimes this slow response is accompanied by high CPU utilization.
High memory usage: High memory usage or memory leak can cause virtual memory usage in a process to keep growing over time and prevent it from ever returning to normal usage levels. The process can then run out of memory and this can cause it to terminate unexpectedly.
Debugging these issues is a bit tricky, you will have to look through the report to determine which objects are consuming the most resources.
Have a look at the Virtual Memory Summary and Virtual Memory Details:
You can also see the Objects that are using the most memory in the 'Loaded Module Summary' section: