Windows Screensaver Worker Overview
Supported Platforms
Windows 10 & 11 (64-bit; x86-64)
Execution Model
The Windows Screensaver Worker uses a Windows-specific execution and privilege model. While it shares the same DCP Worker and evaluator sandbox guarantees as other Standalone Workers, its execution lifecycle, process hierarchy, and privilege enforcement are implemented using native Windows service, screensaver, and restricted-token mechanisms.
Two Ways to Deploy
The same MSI serves two audiences. Pick your path:
Home & individual users: interactive install, configured through a settings dialog, automatic updates. See Home & Individual Installation below.
Enterprise & fleet deployments: silent, fully scriptable installation with command-line configuration, central deployment via SCCM, Intune, NinjaOne, or PowerShell, optional domain service accounts, worker registration into your control plane, and control over the update policy for frozen or managed machines. See Enterprise & Fleet Installation below.
Home & Individual Installation
Download the MSI from https://download.distributive.network/windows/latest/dcp-worker/ and double-click it, installing as administrator.
After installation, the settings dialog opens automatically; reopen it any time via Change Screensaver Settings. Configure the Worker across its tabs:
Screensaver tab:
Saving writes these settings to the Windows Registry and automatically restarts the Worker service to apply them. Settings are preserved across upgrades.
The installer automatically configures the machine to never sleep or turn off the display while on AC power, so the Worker can compute uninterrupted. Battery (DC) power settings are deliberately left unchanged; if you are installing on a laptop and want it to compute on battery, adjust Control Panel > Edit Power Plan yourself.
Let the screensaver activate on its own, or select Preview in the Windows screensaver settings to activate it immediately.
Updates are automatic. The Worker keeps itself current in the background; no action is required.
Enterprise & Fleet Installation
The MSI supports fully silent installation with all configuration supplied on the msiexec command line, suitable for SCCM, Intune, NinjaOne, PDQ, or PowerShell rollout scripts.
Silent Install
From an elevated Command Prompt:
cmd
msiexec /i dcp-worker.msi /qn /l*v "%TEMP%\dcp-install.log" ^
REGISTRATION_KEY="<key from DCP portal>" ^
EARNINGS_ACCOUNT="<dcp-bank-account>" ^
JOIN_GROUP="<joinkey>,<joinsecret>" ^
MANUAL_UPDATES_ONLY=1
From PowerShell, single-quote each PROPERTY="value" token and use backtick line continuations instead of ^, so the inner double quotes reach msiexec intact.
Configuration Properties
Domain Service Accounts
By default the Worker service runs as the Windows virtual account NT SERVICE\DCP Worker, which the OS creates automatically and which requires no password management. Environments whose security policy requires domain accounts for services can supply one instead.
One-time setup by your AD team:
- Create a domain service account (e.g. YOURDOMAIN\svcDCPWorker). It needs no admin rights, no interactive logon, and no mailbox. Use NetBIOS form (DOMAIN\user, not user@domain); the account name and password must not contain single-quote characters.
- Grant it "Log on as a service" (SeServiceLogonRight) on target machines via GPO. This is the only right it needs.
- Exclude it from roaming-profile and folder-redirection policies. The Worker's identity lives in the account's local profile, so the profile must be local and stable on each machine.
What the installer does: it creates the service, switches it to your domain account before the first start attempt (so the service never tries to start under an account your GPO would block), starts it — which creates the account's local profile with no interactive logon — and then registers the Worker, writing its identity into C:\Users\<account>\.dcp. The profile location is resolved from the Windows registry rather than assumed, and registration is skipped rather than written to a wrong location if the profile is not healthy.
Important: every install and every upgrade command must include SERVICE_ACCOUNT and SERVICE_PASSWORD. Running the MSI without them resets the service to the virtual account, which on GPO-restricted machines prevents the service from starting. For the same reason, always set MANUAL_UPDATES_ONLY=1 on these fleets so an automatic update cannot reset the account.
Verifying a Deployment
cmd
sc qc "DCP Worker" SERVICE_START_NAME shows the expected account
sc query "DCP Worker" STATE shows RUNNING
A registered Worker appears in your DCP Portal control plane within a minute or two, labelled DCP Worker@<hostname>.
Monitoring a Running Worker
Worker, supervisor, and evaluator events are written to the Windows Event Log (Event Viewer > Windows Logs > Application). Registered Workers can also be monitored centrally from the DCP Portal.
To forward logs to a third-party logger such as BetterStack, add the following registry entry:
registry
[HKEY_LOCAL_MACHINE\SOFTWARE\Distributive\dcp-worker\dcp-config\worker\logging\syslog]
"url"="tls://<YOUR_SOURCE_TOKEN>.syslog.betterstack.com:6514"
Updating the Worker
By default, Workers update automatically in the background; no action is required.
For frozen or managed machines, install with MANUAL_UPDATES_ONLY=1 to disable automatic updates entirely. To upgrade, push the new MSI with the same command line you used to install — configuration, registration, and (if supplied) the service account are all preserved or re-applied automatically.
Uninstalling
Uninstall via Settings > Apps or msiexec /x. A true uninstall removes the service, the Worker's registry configuration, and the service account's local worker state, leaving the machine clean. Upgrades never remove configuration or the Worker's identity.
Process Model
All evaluator processes inherit a restricted security token and communicate only with the local Worker service over loopback TCP. No evaluator process accepts inbound network connections or executes with administrative privileges. The process tree for dcp-screensaver looks like this:
dcp-screensaver:
| node.exe (dcp-worker)
| dcp-evaluator (dispatcher) [listens on port 9000, locally]
| dcp-evaluator (v8-evaluator)
| dcp-evaluator (v8-evaluator)
| dcp-evaluator (v8-evaluator)
| ...
When the screensaver exits, the evaluator sandboxes terminate immediately, abandoning in-progress tasks. The Worker may submit completed results before returning to an idle state.
Service Accounts and Privilege Model
Operational Characteristics
Windows Screensaver Workers are typically used for:
- Individual or home users contributing idle CPU and GPU resources
- Institutional or enterprise deployments reclaiming idle CPU and GPU resources
- Interruptible batch workloads
They preserve the same core sandboxing and security properties as other DCP Worker variants, while leveraging the Windows screensaver subsystem as a native idle-state trigger for workload execution.