KB0063 - API, App or Job Not Starting

KB0063 - API, App or Job Not Starting

Problem

External processes do not start after upgrades or with the same configuration and script on different machines. Common errors in the log will include:
  1. [ERR] Dashboard process running but not response after 10 seconds. Terminating process.
  2. [WRN] Job process did not respond to handshake in time. Killing process in 5 seconds.
  3. [ERR] API process did not start in 30 seconds.

Root Causes

The root cause of this problem is typically due to external configuration of the system. This can include conflicting modules or multiple versions of the Universal module installed. It's necessary to determine which is the cause before applying a workaround. 

Mismatch Assembly Versions

Due to how assembly versioning works in .NET, it's possible to get mismatches between versions due to how modules load these assemblies. A way to determine if this is the problem, is to enable fusion logging. It will display all assembly binds and any failures. You can enable fusion logging using the following registry keys. You will need to restart the PowerShell Universal server in order for this to take effect. 
  1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
    Add:
    DWORD ForceLog set value to 1
    DWORD LogFailures set value to 1
    DWORD LogResourceBinds set value to 1
    DWORD EnableLog set value to 1
    String LogPath set value to folder for logs (e.g. C:\FusionLog\)
Once enabled, log files we be generated, and any errors will be shown. To resolve this issue, you will need to identify the conflicting module and uninstall it from the system or remove it from the PSModulePath. Consider using a minimal environment to avoid loading the PowerShell Universal assemblies into the process if the module works without issue in a standard PowerShell prompt. Note that minimal environments are only supported for jobs.

Multiple PowerShell Universal Module Versions

Often, users will install the PowerShell Universal module using the Install-Module cmdlet but will not update the module when updating the server. This can cause a mismatch between the PSU server and the PSU module and cause processes to fail to communicate back to the server. There is a health check in recent versions of PowerShell Universal to look for this condition. Two modules are defined within PowerShell Universal that are leveraged by the platform. The first is only installed with the server and uses the Start-PSUHost cmdlet to connect back to the server from the external process. This module is not installed with Install-Module. The second module, Universal, is installed with Install-Module and can cause conflicts. 

Search for multiple installed versions and ensure that are upgraded on the system. You can do so with Get-Module -ListAvailable. 

System Overloaded

The system is unable to process requests quickly enough and the server is timing out. Certain features, such as jobs, have configurable handshake timeout settings that can be configured in the General \ Settings to extend the handshake timeout to help avoid these issues. It may also be necessary to provide additional resources to the system.