If you look in the System group, you might see a warning similar to the following:

Source: W3SVC

Type: Warning

Description:

A process serving application pool 'OutSystemsApplications' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '1234'. The data field contains the error number

Cause

This events mean that you experienced a worker process crash. This means that a severe error in one of your applications has caused the worker process (w3wp) to crash. This means that somewhere in your application(s) there is logic that is crashing.

When using OutSystems to develop your applications, the most common causes for this are: infinite loops somewhere in your logic and misbehaved integration (extensions).

Resolution

To solve this type of errors, you first need to identify where it is occurring. Since this problem can occur anywhere in your logic, the process should follow this line of though:

In a top-bottom approach, identify where (eSpace) it is ocurring;

Determine usage patterns of that eSpace that trigger the behavior;

Inspect the logic.

To start with this, a good approach is to search for a candidate eSpace or set of eSpaces. If you can trivially replicate the crash (e.g. navigating in your application, after a given sequence of clicks, always causes the problem) see the logic in the eSpace of this last click before the crash, and go back to the beginning.

If the crash is more random, you will need to first detect where it is occurring. Some guidelines for this:

Try stopping the Scheduler Service and leave it like that for some hours. If the crash stops occurring, that means that the problem is with a timer in one of your applications, and now you have narrowed it;

Create a new application pool in IIS and put one (or a set of) eSpaces there. When the next crash occurs, check the System group in Event Log for the warning mentioned in Causes: if you now see the name of your newly created application pool instead of OutSystemsApplications, it means that you have found the guilty eSpace, and can start digging from there.

As a last resort, you may want to use DebugDiag and attach it to the w3wp.exe and get a stack of the crash, but most of the times the above procedure will allow you to identify the problem. We frequently get reports for this sort of problems at Support, and I am yet to see one that is not caused by a simple infinite loop in the eSpace logic.

Further considerations

The above troubleshoot is also useful for identifying infinite loops in your logic that, instead of a worker process crash, cause 100% cpu usage. In that case, when isolating the eSpaces in a separate application pool, simply forcefully kill the w3wp.exe that is using 100% CPU and check the Event Log to see which application pool it was serving.

When we need to get to the part of actually dumping the Worker Process memory, this post by Tess Fernandez provides a pretty good overview of how to obtain the crash and do an initial analysis.

This is very useful if after isolating the problem (to confirm the actual stack of the error) or if your attempts to isolate the error are inconclusive.
The information you will obtain is very similar to what you get in a stack trace in the Error log. Particularly, the bottom lines should identify the eSpace where the request is running - therefore telling you which eSpace to move to the separate pool.

You have to analyze the crash dump to determine the cause of the IIS Worker process crash. Olny by analyzing the crash point stack, you can assert if the error comes from the system, platform or application.

Upgrading the espace to version 9, means upgrading an environment to version 9. Although the Platform will upgrade the espace, it's possible that it might find some patterns that hit on identified breaking changes.