Desktop service maintenance
If several features fail or the background service is not ready, use this page to inspect its state, restart it, and collect diagnostics. Open Settings > Advanced. Standalone Evolver services use their CLI, not this Desktop control.
Identify the failing service
Inspect background-service status and technical details, then health diagnostics. Record the application version, service state, failure time, and active tasks. An open window does not establish service readiness; a healthy service does not establish every model or plugin connection is usable.
Separate the window, background service, and external connections
The Desktop window exposes controls, the background service handles its runtime work, and models or plugins depend on their own connections. Follow the failing path. An open window establishes UI availability; readiness establishes service startup; feature success also requires its configuration, authorization, and dependencies.
| Observation | Check first | Next action |
|---|---|---|
| Window available, service not ready | Service state, startup errors, recent configuration | Preserve diagnostics and repair startup |
| Service ready, one model request fails | That model's configuration, credentials, request error | Repair the connection and repeat the bounded check |
| Service ready, one plugin unavailable | Plugin enablement, configuration, authorization | Address its error and validate its function |
| Service ready after restart, task outcome unclear | Original task and external effects | Reconcile before resuming or retrying |
Narrow the fault rather than changing every connection after one dependency fails. Preserve a before/after comparison for each identified change.
Scenario: a task is writing externally before restart
Record the task, progress, generated artifacts, and submitted requests. If maintenance interrupts it, make those results explicit post-restart checks. Once ready, inspect task and external-system outcomes before continuing.
A lost response does not establish that the request failed, and restarting cannot establish that either. Repeating it directly can duplicate an action. Service maintenance restores the runtime entry point; you still need to check the task and destination outcome.
Restart the background service
- Inspect active tasks and preserve task identifiers and results before restarting during external writes.
- Use Restart on the background-service row and wait for the state to update.
- Confirm readiness, then run a limited check of the affected function.
- On failure, inspect technical details and copy diagnostics. Address the reported cause instead of repeatedly restarting.
The restart control reports success after the new service becomes ready. It does not restore modified files or reverse sent messages, publications, or charges.
Prepare support details
Service details provide Refresh, Open log folder, and Copy diagnostics. Use health checks to locate configuration and connection failures, recording each result and repair. Review the bundle using sharing redaction before sending it.
If failure persists after restart
If the service is not ready, preserve the latest error and logs and investigate configuration or startup problems identified by diagnostics. If it is ready but one feature fails, inspect that feature's model, plugin, or network connection instead of attributing every failure to the background service.
Change one identified factor at a time and record before/after results. Escalate with reproduction steps, application version, failure time, service state, and redacted diagnostics. Record successful startup separately from resolution of the original problem.
Completion criteria
The service is ready, the failing function has been verified, and task and external outcomes are reconciled. For unresolved failures, provide version, time, task identifiers, diagnostics, and actions already taken.