Dette er en ældre version. Den nyeste version er 1.131.0. SysManager 1.131.0 · Udgivet:
Installationsfiler 1.65.1
| Arkitektur | Type | Omfang | Filstørrelse | Download | SHA256 |
|---|---|---|---|---|---|
| 64-bit | Portabel | — | — | github.com | VirusTotal |
Link og SHA256 stammer fra fællesskabets manifest i Windows Package Manager. Sammenlign hashen for den downloadede fil, før du kører den.
Udgivelsesnoter
[1.65.1] - 2026-08-13
Dates and times now look the same on every PC. If your Windows is set to a language whose calendar is not the Western one — Thai or Arabic, for example — the app was printing the wrong year, and in a few places the wrong month, in lists, exported reports, and even in the names of the files it saved.
Fixed
- Dates were wrong, not just differently formatted, on some regional settings. Where the app shows a date in a fixed layout — the Boot Analyzer, Privacy Monitor, Restore Points, Disk Analyzer, the bandwidth and resource charts, the crash notice, exported reports — it was letting Windows' regional setting pick the calendar. On a Thai setting, 4 August 2026 was shown as 2569-08-04; on an Arabic (Saudi) setting, as 1448-02-21, with the month changed too. On a Finnish setting the time lost its colon (13.45), which also broke sorting a column of timestamps. Every one of these now prints the same on every machine.
- Saved files could be named with the wrong date. Exported reports, log CSVs, resource-history CSVs, saved settings profiles, and the automatic registry backup taken before a context-menu change all put a timestamp in the filename. On the regional settings above, that timestamp was a different year, so the files sorted wrongly and did not match the date inside them.
- The Dashboard could report no critical events on a PC that had them. Its seven-day event-log scan builds a date filter that Windows parses literally. Under a non-Western calendar that filter asked for a year that has not happened, so the query came back empty and the Dashboard said nothing was wrong.
- "Updates paused until …" could state a date that was not the pause date. The Windows Update panel formatted that promise the same way.
Verify the download
Get-FileHash .\SysManager-v1.65.1.exe -Algorithm SHA256
Expected SHA256: EDE3D1A662BE0C282C32F5940296EB8A256723FA222AA72D7BFEB7217DAF4802
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.65.1.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.65.1.sbom.json, a CycloneDX inventory of
every dependency resolved for this build.https://github.com/laurentiu021/SystemManager/releases/tag/v1.65.1