The curiosity Windows service

Reference for the curiosity service that Install creates: what the setup script checks and applies, how the service is defined, and what the start error codes mean. Nothing on this page is a step you need to take after a successful install.

What configure-windows-service.bat does

The script ships in the install folder and is written for cmd.exe: it refuses to run from PowerShell or without elevation, and it must sit next to curiosity.exe. It never supplies a configuration value on its own. It has two modes.

Without arguments

It checks, then creates or updates the service:

1. Environment variables. Every MSK_* variable visible in the console or in the machine-scope registry key is checked. A name the server does not read is reported as a probable typo; a variable that exists only in this console or for the current user is reported as invisible to the service, with the setx /M line that fixes it; a machine-scope variable set after the console was opened is reported as not visible here yet.
2. Folders. The install folder, MSK_GRAPH_STORAGE, MSK_LOG_PATH, MSK_AUDIT_LOG_PATH, MSK_GRAPH_TEMP_FOLDER and the optional journal, backup, web-root, fonts, plugins and Git-tracking folders, read from machine scope the way the service sees them. A missing folder other than the install folder is created as administrator. Each folder is checked for a UNC or mapped-drive path (a service has no drive mappings, and LocalSystem reaches a share as the computer account), a location inside C:\Users, whether it is writable at all, whether SYSTEM holds full control or modify (when the service runs as LocalSystem), and whether its drive has less than 10 GB free. A missing MSK_GRAPH_STORAGE is a warning that names the per-account default it falls back to.
3. The service. A new curiosity service is created with the command line below, running as LocalSystem, and started with net start. An existing service is stopped, its command line, display name and start type are rewritten with sc config, and it is started again — its logon account and password are kept. If the start fails, the script prints a short explanation of errors 1053 and 1069.

Warnings are counted and printed but never stop the script — it says so and creates the service anyway. Only three things stop it: PowerShell, no elevation, and no curiosity.exe beside it. The access of an account other than LocalSystem is not checked in this mode. An install path containing parentheses (C:\Program Files (x86)\…) is handled correctly.

setup

configure-windows-service.bat setup is the guided mode. It asks three things — the base folder for data, logs and temp files, from which the four MSK_* paths are derived; whether to seed the admin account through MSK_ADMIN_USER, MSK_ADMIN_EMAIL and MSK_ADMIN_PASSWORD; and whether the service runs as LocalSystem, a user account or a gMSA — proposing whatever is already configured as the default. It then prints a plan in which every item is [done] or [todo]. The status comes from looking at the registry, the folders, the ACLs, the local security policy and the service definition; nothing is remembered between runs. After you confirm, the [todo] items are applied:

• setx /M for each variable whose machine-scope value differs;
• the four folders, followed by the same folder checks as above;
• for an account other than LocalSystem: icacls grants — read and execute on the install folder, full control on data and temp, modify on logs, inheritable and applied to existing files — and the Log on as a service right through secedit, with the account resolved to its SID first. A gMSA is also checked with Test-ADServiceAccount when the Active Directory PowerShell module is installed;
• the service: created, or updated in place with the new account and command line, then started.

Running setup again is safe: it reports everything as [done] and only restarts the service.

The service command line

The service is created with this command line — every path and password comes from the machine-scope environment:

curiosity.exe --MSK_RUN_AS_SERVICE=true

• --MSK_RUN_AS_SERVICE=true must be part of the binPath command line — the script passes it there rather than as a machine-wide variable. It registers the process with the Service Control Manager (without it, sc start fails with error 1053 after 30 seconds, because the exe runs as a console app the SCM never hears from), sets the working directory to the install folder (services otherwise start in System32), and keeps the terminal interface off, which a service has no console for. The server reads it from the machine-scope environment as well, so setting MSK_RUN_AS_SERVICE there fixes the working directory for a service somebody created without the flag — but the command line is what the script writes, and what a hand-made service should carry.
• When MSK_LOG_PATH is not set at machine scope, the script also appends --MSK_LOG_PATH="<install folder>\logs" so the logs land next to the binaries instead of in the service account's temp folder. To remove that override, set MSK_LOG_PATH at machine scope and re-run the script; the account is kept.

To create the same service without the script, from an elevated Command Prompt:

sc create curiosity binPath= "E:\Curiosity\CuriosityWorkspace\curiosity.exe --MSK_RUN_AS_SERVICE=true" displayname= "Curiosity Workspace" start= auto
sc start  curiosity
sc query  curiosity

sc does not grant Log on as a service — for an account other than LocalSystem, grant it as described on Service account. The service is also visible in services.msc.

Service start errors

When the service fails to start, net start prints a Windows error code; the script explains 1053 and 1069 briefly, the table below covers the rest. A failure inside the workspace itself is written to error.log — in the log folder, next to curiosity.exe, or in the service account's temp folder — and to the Application event log as a .NET Runtime entry.

Binaries or data under another user's C:\Users\<name> profile is the most common cause of 1053 and 5 — see Directory layout. For a gMSA, gMSA troubleshooting covers the account-side causes.

See also

• Install — the install steps.
• Service account — running the service as a dedicated user or a gMSA.
• Configuration reference — every MSK_* variable.
• Troubleshooting.