Repository navigation
SysManager 1.52.76
What's new for you
Four service-layer fixes that improve resilience on real-world hardware: Disk Analyzer now reports accurate sizes even when scanning system drives, the File Shredder handles read-only files correctly, the Memory health tab survives incomplete WMI data, and app-icon loading no longer crashes on corrupt cache files. Also includes a CI test stability fix (no user-visible impact).
[1.52.76] - 2026-07-10
Fixed
- Disk Analyzer over-counted drive usage by descending into WinSxS and other heavyweight system directories during recursion. The
SkipSegmentsfilter (\windows\winsxs,\windows\csc,\$recycle.bin,\system volume information) was only applied to the top-level children of the analyzed root (line 71). The recursiveMeasureFolderwalk pushed every non-reparse subdirectory onto the stack without re-checking againstSkipSegments, so scanning a drive root likeC:\would enterC:\Windows(not skipped — it's not in the list) and then descend intoC:\Windows\WinSxS(a hardlink farm, not a reparse point) andC:\Windows\CSC(offline files cache), double-counting hundreds of thousands of hardlinked files at fullFileInfo.Length. The recursive loop now guards each subdirectory withShouldSkip(d)before pushing it, matching the top-level behavior. - App icon cache loading crashed on corrupt PNG/JPEG files that trigger WIC codec errors.
AppIconService.LoadFromFilecaughtNotSupportedException,IOException, andUriFormatException, butBitmapImage.EndInit()throwsFileFormatException(derives fromFormatException, notIOException) for malformed image headers andExternalExceptionfor native WIC decoder failures. Both are now caught, matching the established pattern inIconExtractorService(lines 203/234). Without this fix, a single corrupt cached icon file caused the entire app-icon load path to throw unhandled to the caller. - File Shredder failed on read-only files when invoked for a single file (not via folder shred).
ShredFileAsyncopened a write stream (FileAccess.Write) without first clearing theReadOnlyattribute, throwingUnauthorizedAccessException.ShredFolderAsyncalready stripped ReadOnly (lines 213-215) before callingShredFileAsync, but the ViewModel's single-file path (FileShredderViewModel:170) calledShredFileAsyncdirectly — the file survived with its data intact while the UI reported "Failed". The ReadOnly strip now lives insideShredFileAsyncitself so both entry points are covered. - Memory health scan returned partial or empty results when any single RAM module reported a
DBNullproperty.MemoryTestServiceusedConvert.ToDouble(mo["Capacity"] ?? 0)andConvert.ToUInt32(mo["Speed"] ?? 0u)— the??operator does not catchDBNull.Value(which is non-null), soConvert.ToUInt32(DBNull.Value)throwsInvalidCastException. The catch block for that exception sat OUTSIDE theforeachloop, so one problematic module aborted the entire scan. Now usesFixedDriveService.ToDoubleSafe/ToUInt32Safe(DBNull-aware, already tested) and the defensive catch wraps each individual module so remaining modules are still reported. - Flaky test (
ContextMenuViewModelTests.Constructor_TotalCount_DefaultsToZero) that raced the ViewModel's constructor-initiated async registry scan. On CI, the scan could complete before the assertion checked, producingExpected: 0, Actual: 6. Replaced all four timing-dependent baseline tests with post-scan invariant assertions that awaitInitializationComplete— the same deterministic pattern used by 16 other VM test classes.
Verify the download
Get-FileHash .\SysManager-v1.52.76.exe -Algorithm SHA256Expected SHA256: EC0FCC5B51B5953D3FDE091DF4ABB81F51D820EFFA770DBD15D37DCED569C656