이전 버전입니다. 현재 최신 버전은 1.131.0입니다. SysManager 1.131.0 · 출시일:
설치 파일 1.76.17
| 아키텍처 | 형식 | 설치 범위 | 파일 크기 | 다운로드 | SHA256 |
|---|---|---|---|---|---|
| 64비트 | 포터블 | — | — | github.com | VirusTotal |
링크와 SHA256은 Windows 패키지 관리자 커뮤니티 매니페스트에서 가져왔습니다. 실행하기 전에 다운로드한 파일의 해시를 비교해 보십시오.
릴리스 노트
[1.76.17] - 2026-09-07
Some perfectly healthy apps were being listed as "Not responding" in Processes — Films & TV and Settings did
it on this machine every single refresh. They are fine; the check SysManager used to ask them was the wrong
one. The list also refreshes faster now, and no longer freezes for five seconds when an app really has
frozen.
Fixed
- "Not responding" now means it. SysManager asked each app whether it was alive by sending it a message
and waiting up to five seconds for a reply. Some apps from the Microsoft Store never reply to that message
even when they are perfectly responsive — measured over four passes, Films & TV and Settings answered
"no reply" instantly, every time — so they were labelled frozen on every refresh. The check is now the same
one Windows itself uses to decide whether to grey out a window and add "(Not responding)" to its title, so
the column agrees with Task Manager.
- The Processes list no longer stalls on a frozen app. The old check waited up to five seconds per
frozen window before it could finish the refresh, so the one case the column exists for was also the one
that made the whole list hang. Confirmed against a deliberately frozen window: the old check blocked the
refresh for 5,013 ms; the new one answered in under a millisecond and still reported the freeze.
- Refreshing the list does about a third less work. Finding each app's window was being done twice for
every process, once for the responsiveness check and once for the "has a window" flag, and neither reused
the other's answer. It is now done once per refresh for all of them. On a machine with 478 processes a
refresh went from 202 ms to 138 ms, and the part that is not the deliberate CPU-sampling pause dropped
from 102 ms to 38 ms.
Verify the download
Get-FileHash .\SysManager-v1.76.17.exe -Algorithm SHA256
Expected SHA256: 5DA1E0A873D1B215EBB317418DDABB158881FBDE274E885DA842C4F8B7592006
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.76.17.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.76.17.sbom.json, a CycloneDX inventory of
every dependency resolved for this build.https://github.com/laurentiu021/SystemManager/releases/tag/v1.76.17