SysManager 1.113.6

[1.113.6] - 2026-09-24

Enabling a service now brings back "Automatic (Delayed Start)" when that is how it was set. The
Services tab took every delayed-start service for plain Automatic, so disabling one and then enabling it
again asked Windows to start it together with the others at boot instead of shortly after them.

Fixed

• Enable restores a delayed start. Windows can hold an automatic service back until shortly after the
  others, to keep it out of the busy moment right after startup. services.msc shows these as "Automatic
  (Delayed Start)"; on the Windows 11 machine this was checked on they were 17 of the 108 automatic
  services, Windows Search among them. The Services tab read each startup type in a form that has no word
  for the delay, so it recorded such a service as plain Automatic when disabling it, and Enable then asked
  for plain Automatic. It now reads the delay too, remembers it when you disable a service and asks for it
  back when you enable it, and the Enable confirmation and the status line after it both name it. The
  Startup column still shows these services as "Automatic". Present since Enable began restoring the
  previous startup type, in v1.20.34.
• The file that remembers what Enable should restore now keeps only types Enable can apply. It
  accepted two startup types that only hardware drivers use, which this tab never lists and which made
  Enable fail with an error, and it ignored capitals in a type's name where the restore did not, so a
  hand-edited "automatic" came back as Manual. Both now follow one list.

---

Verify the download

Get-FileHash .\SysManager-v1.113.6.exe -Algorithm SHA256

Expected SHA256: 3534D7677E665FA78F494ABB9167A66E4BEB9D8179CE7018FE34092D2D4C362C

This build is not code-signed, so Windows will warn on first launch. That is
expected for a small independent app: see what the warning says and what to
click.
Code signing is planned through the SignPath Foundation,
which provides free certificates to open-source projects, with signing performed by
SignPath.io. Until then, the SHA256 above and the build
attestation below are what establish that a download is the genuine build.

Code signing policy

This release is not code-signed. The team roles, release-approval process and
privacy policy required by the SignPath Foundation programme
are documented in advance under Code signing
policy. That
documentation is a prerequisite for applying, not evidence of a certificate. The
attribution line naming SignPath as the signing provider will appear here once a
certificate is actually issued.

This program will not transfer any information to other networked systems unless
specifically requested by the user or the person installing or operating it. Full
privacy policy.

Verify where this binary came from

This exe was built by GitHub Actions from this public source, and the build is
recorded in the Sigstore public transparency log. With the
GitHub CLI:

gh attestation verify .\SysManager-v1.113.6.exe --repo laurentiu021/SystemManager

That proves which commit and workflow produced this exact binary, something the
SHA256 file cannot show, since it is published alongside the exe it describes.
Each release also ships SysManager-v1.113.6.sbom.json, a CycloneDX inventory of
every dependency resolved for this build.