ExecutionManager
ExecutionManager is responsible for actually running the workflows and the set of modules that are loaded and unloaded for each one. Depending on the workflow, ExecutionManager decides whether to run it in an existing or new MonitoringHost process. Depending on isolation level and the credentials the workflow needs to run under, ExecutionManager uses its internal manager, called HostManager, which is responsible for starting/managing an existing or new MonitoringHost process.
If there is any error in either of the modules used by a workflow, ExecutionManager unloads the entire workflow. The same goes for multiple workflow failures inside of a MonitoringHost process. If multiple workflows fail, ExecutionManager might decide to stop the entire MonitoringHost process, thus affecting/stopping any other workflows running under the same process, even if they were successful.
To reduce the footprint and overhead of workflow processing, ExecutionManager implements a technique known as module cookdown for identical modules from separate workflows. This means that if a module with the same input data was already loaded into some running workflow, ExecutionManager uses this existing module instead of loading a new instance of it.
EventID=4000
Severity=Error Message=A monitoring host is unresponsive or has crashed. The status code for the host failure was %1
EventID=4001
Severity=Error Message=ESE failure trying to remove module state. The status code for the failure was %1