The unreadable files are one of two error classes, as reported by running the tool you had so generously built for me probably by now a decade ago:
Code: Select all
wimboot-verify-x64.exe C:\
or
The WOF driver encountered a corruption in WIM image's Resource Table
The checksum mismatched files seem to contain all NULLs, based on my entirely unscientific random sampling of three files out of several thousand.
Running this command:
Code: Select all
wimverify c:\diskzip.wim
Running DiskZIP's own CHKDSK tool, which only checks whether external backing is found, does not report any errors (since all externally backed files do have, an albeit corrupted, WIM on disk).[WARNING] "c:\diskzip.wim" does not contain integrity information. Skipping integrity check.
Verifying metadata for image 1 of 1
[ERROR] Failed to decompress data!00 GiB (20%) done
ERROR: "c:\diskzip.wim" failed verification!
ERROR: Exiting with error code 2:
The WIM contains invalid compressed data.
Press any key to continue . . .
The unsafe compaction pass which produced this WIMBOOT archive did NOT report any errors in its processing log.
I do have backups of all affected files, so I plan to replace them with their healthy counterparts, and then reimage my system. I've got several questions in this regard:
1) Can I make do with an unsafe compaction pass, despite the fact that the WIM image resource table is corrupt? OR, do I have to perform a full new compaction pass, creating a brand-new WIM from scratch?
2) Is there a way to perform an offline repair on this WIM image, repairing the errors found inside of its Resource Table; while of course dropping any unhealthy files it contains?
3) Is the currently corrupt WIM image re-applicable in WIMBOOT mode? My current operating device (where I'm typing this from presently) definitely seems to suggest so; however I'm curious how this works at all, given the corruption in the WIM image Resource Table. OR, could it be the case that whatever the corruption is, it affected my device AFTER the image was applied in WIMBOOT mode?
4) I thought I'd refrain from asking which hardware component the forensic data at hand might seem to suggest is at fault, but I couldn't help myself and welcome any speculations in this regard.