SysManager 1.52.76 ჩამოტვირთვა

[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 SkipSegments filter (\windows\winsxs, \windows\csc, \$recycle.bin, \system volume information) was only applied to the top-level children of the analyzed root (line 71). The recursive MeasureFolder walk pushed every non-reparse subdirectory onto the stack without re-checking against SkipSegments, so scanning a drive root like C:\ would enter C:\Windows (not skipped — it's not in the list) and then descend into C:\Windows\WinSxS (a hardlink farm, not a reparse point) and C:\Windows\CSC (offline files cache), double-counting hundreds of thousands of hardlinked files at full FileInfo.Length. The recursive loop now guards each subdirectory with ShouldSkip(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.LoadFromFile caught NotSupportedException, IOException, and UriFormatException, but BitmapImage.EndInit() throws FileFormatException (derives from FormatException, not IOException) for malformed image headers and ExternalException for native WIC decoder failures. Both are now caught, matching the established pattern in IconExtractorService (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). ShredFileAsync opened a write stream (FileAccess.Write) without first clearing the ReadOnly attribute, throwing UnauthorizedAccessException. ShredFolderAsync already stripped ReadOnly (lines 213-215) before calling ShredFileAsync, but the ViewModel's single-file path (FileShredderViewModel:170) called ShredFileAsync directly — the file survived with its data intact while the UI reported "Failed". The ReadOnly strip now lives inside ShredFileAsync itself so both entry points are covered.
- Memory health scan returned partial or empty results when any single RAM module reported a DBNull property. MemoryTestService used Convert.ToDouble(mo["Capacity"] ?? 0) and Convert.ToUInt32(mo["Speed"] ?? 0u) — the ?? operator does not catch DBNull.Value (which is non-null), so Convert.ToUInt32(DBNull.Value) throws InvalidCastException. The catch block for that exception sat OUTSIDE the foreach loop, so one problematic module aborted the entire scan. Now uses FixedDriveService.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, producing Expected: 0, Actual: 6. Replaced all four timing-dependent baseline tests with post-scan invariant assertions that await InitializationComplete — the same deterministic pattern used by 16 other VM test classes.
Verify the download
Get-FileHash .\SysManager-v1.52.76.exe -Algorithm SHA256
Expected SHA256: EC0FCC5B51B5953D3FDE091DF4ABB81F51D820EFFA770DBD15D37DCED569C656