In order to track what was the Intelligence Server doing before the crash we can use two methods:
Threads are who is doing the task. Every PU has one or more threads and every thread can execute any task. However, a thread can execute only one task at a time. Therefore, if you have a thread executing a SQL query, once the query is completed, the thread can be re-assigned to run a document execution for example.
In order to find out the thread ID we would need the Dss log. Open the DSSError log files (including the back up files) and search "***** Start of Info Dump *****" to find the first MCM denial in the log files, and then check what's cause the MCM denial. The only way we can find out what caused that execution is to initially review the thread ID before the Dump. As each thread can only do one task at a time. Therefore, searching for all instances of the thread ID, should give us at least an overview what that thread was used for.
We may find that the thread was being used for other tasks. This means that the next step would be to look for "Contract Request Succeeded" (or "Contract Request Failed" messages, it depends on what we want to find), and look for the "Handle" ID. The handle ID is the unique identifier for each memory contract request which are part of the same job execution. This will give you an overview of the memory usage of at least one specific job. Be aware that this is a very time-consuming method and we need to be sure what you are trying to look for.
If we want to find out which object / user is responsible for the memory request above, we will need to use historical stats and query the IS_REPORT_STATS and / or IS_DOCUMENT_STATS tables for the time frame referenced in the logs (searching for the handle ID will give us a time range. We can also use EM, if we want to build a report instead or running SQL. In the 10.11 and 11.x releases, we can get the user ID, Session ID and Object ID that is causing an individual request in the DSSErrors.log.
KB442302
