After a server reboot, connectors hosted by Sisense.CLRConnectorsContainer stop working with Event ID 7000 / 7006 [Windows]
Summary: Eiji Ozawa provides a detailed guide on resolving issues with the Sisense.CLRConnectorsContainer service failing to start after a Windows server reboot, causing connector-related errors and failures. The guide explains symptoms such as failed ElastiCube builds and live dashboard errors, identifies the root cause as a timeout error (Event IDs 7000/7006), and recommends extending the ServicesPipeTimeout registry value to give services more time to start. The post includes step-by-step instructions on adjusting registry settings and suggests setting non-core services to 'Automatic (Delayed Start)' to prevent timeouts.
Introduction:
After a Windows server reboot, the Sisense.CLRConnectorsContainer service fails to start (Windows Event 7000 / 7006), so its connectors (e.g. Microsoft SQL Server) stop working — causing build failures, Live dashboard errors, and connectors missing when adding tables. This guide resolves it by extending ServicesPipeTimeout. Applies to Sisense on Windows (on-prem), all versions.
Step-by-Step Guide:
Customers usually notice this issue through one or more of the following symptoms after a server reboot:
ElastiCube builds fail on cubes that use a CLR-hosted connector.
Dashboards using Live data models return errors, because live queries cannot reach the connector.
When adding a new table to a data model, the connector does not appear in the list and cannot be selected.
The root cause is that the Sisense.CLRConnectorsContainer service failed to start during server startup. In the Windows Event Viewer (Windows Logs → System), you will find events such as:
Event ID 7000 — "The Sisense.CLRConnectorsContainer service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion."
Event ID 7006 — "A timeout was reached (30000 milliseconds) while waiting for the Sisense.CLRConnectorsContainer service to connect."
The Windows Service Control Manager (SCM) requires each service to respond within a default window of 30 seconds (30000 ms), controlled by the registry value ServicesPipeTimeout. After a reboot, all services start at once and compete for CPU and disk I/O; combined with the CLR container initializing many connectors, the default window is often exceeded, the service times out, and its connectors become unavailable.
Resolution — extend the SCM service start timeout
This value applies server-wide (to all services).
Caution: Editing the registry affects the entire system. Back up the target key first and, where possible, perform the change during a maintenance window. Administrator privileges are required.
Log on to the server with administrator privileges.
Launch regedit (Registry Editor) as administrator.
Navigate to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control (registry path)Check whether a DWORD value named ServicesPipeTimeout exists in the right pane. If it does not exist, right-click the empty area → New → DWORD (32-bit) Value, and name it ServicesPipeTimeout.
Double-click ServicesPipeTimeout to open it.
Set the Base to Decimal.
Enter the extended timeout in milliseconds. Recommended: 180000 (180 seconds). For environments with longer startup times, increase up to 300000 (300 seconds).
Click OK to save.
Restart the server to apply the change (the SCM reads ServicesPipeTimeout only after a reboot).
After the restart, confirm that Sisense.CLRConnectorsContainer starts successfully and that Event 7000 / 7006 no longer recur.
Optional — mitigate via startup order (can be combined)
If services contend during a simultaneous startup after a reboot, set non-core services to Automatic (Delayed Start) so foundational services (Mongo, Zookeeper, RabbitMQ) start first, reducing the chance of a timeout. This works well combined with extending ServicesPipeTimeout.
Conclusion:
The Sisense.CLRConnectorsContainer failing to start after a reboot is caused by the Windows SCM default 30-second start timeout being exceeded under startup contention. Increasing the ServicesPipeTimeout registry value (e.g. to 180000 ms) and rebooting gives the service enough time to initialize, keeping its connectors available and preventing build failures, Live dashboard errors, and missing connectors. Setting non-core services to delayed start further reduces the risk.
References/Related Content
Disclaimer:
This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
