Symptom

When navigating in your OutSystems application, suddenly your browsers begin an endless request, until it eventually times out on the browser side (connection closed).

When you access your OutSystems server and check the Event log, in the Application group, you see an error similar to the following:

Source: .NET Runtime 2.0 Error

Type: Error

Description:

Faulting application w3wp.exe, version 6.0.3790.3959, stamp 45d6968e, faulting module kernel32.dll, version 5.2.3790.4480, stamp 49c51f0a, debug? 0, fault address 0x0000bef7.

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.

Feel free to post your remarks or corrections to what is said above.