(Related annoying bug: WinClone then pops up another dialog saying the clone has completed successfully - when it hasn’t.)
Yet, volume-to-volume cloning of the same volume works, which leads me to think there’s nothing wrong with my NTFS volume.
I have run chkdsk both at boot and with Windows running, and it finds nothing wrong. I ran dism and sfc to check for and fix Windows system problems, with no effect.
This is (as far as I know) unchanged for roughly the past year, so probably not related to Catalina. I only recently realized that my image file backups were useless.
Here’s the WinClone.log output that appears to be relevent:
2019-11-01T23:21:14+13:00:Archiving file data: 89 GiB of 89 GiB (99%) done
2019-11-01T23:21:15+13:00:[ERROR] File data was concurrently modified!
Location ID: 4
Expected SHA-1: 1e6a20f51bccb063dcab47d1234bafbbb7be9ee4
Actual SHA-1: 5b9f2adb8a4bd82b2794b5dc1cd90b71c967fdd9
2019-11-01T23:21:16+13:00:ERROR:
2019-11-01T23:21:16+13:00:Exiting with error code 88:
A file being added to a WIM image was concurrently modified.
2019-11-01T23:21:17+13:00:Executing "wimverify /Users/brsmith/Desktop/BOOTCAMP image.winclone/Windows.wim"
2019-11-01T23:21:17+13:00:Last message repeated 9 times
2019-11-01T23:21:17+13:00:Helper tool error: There was an error while file imaging. Please check the volume and try again. Status:88
2019-11-01T23:21:17+13:00:[WARNING] The WIM_HDR_FLAG_WRITE_IN_PROGRESS flag is set in the header of
"/Users/brsmith/Desktop/BOOTCAMP image.winclone/Windows.wim". It may be being changed by another process,
or a process may have crashed while writing the WIM.
[WARNING] "/Users/brsmith/Desktop/BOOTCAMP image.winclone/Windows.wim" does not contain integrity information. Skipping integrity check.
2019-11-01T23:21:17+13:00:ERROR: Exiting with error code 84:
The WIM file is incomplete.
2019-11-01T23:21:18+13:00:Helper tool error: The WIM file is invalid. Please check the file and try again.
2019-11-01T23:23:14+13:00:Setting the system to allow sleep...
Interestingly: The SHA-1 values (both expected and actual) are same for the last 4 times I’ve tried this, suggesting it might be one particular file triggering the problem. Could it be a particular bit of data that’s showing an error in the SHA-1 calculation?
I’m out of ideas. Any suggestions?
[A bit later:] For shits and giggles I tried imaging the copied volume from the successful volume-to-volume copy. It also fails at the same point, with the same error. I guess if the volume copy is block-by-block copy that would make sense, but if it’s a file copy that’d be a strong indication that it’s something in a file causing the problem.
I tried running chkdsk /B on the copied Windows volume and it ran for quite a bit longer than on the original volume (SSD vs HDD, so not a huge surprise)… to find nothing wrong. I also ran a full Defender scan of my Windows volume - nothing.
At this point, I’m thinking I’ll have to run an exhaustive search of the filesystem to find whatever file matches the SHA-1 hash that keeps coming up when the imaging fails. Maybe it’s something I can live without or modify?
Yay, block-based imaging works! Ok, that’s helpful, thanks for that.
Can you see any way I could further diagnose the problem? My guess that there’s a subtle bug in the SHA-1 code is a shot in the dark; unlikely, but not impossible. Someone who knows the process better could make better guesses at how to troubleshoot.
% find /Volumes/BOOTCAMP -type f -print0 | xargs -0 shasum > Desktop/sums.txt
shasum: /Volumes/BOOTCAMP/Windows/Installer/{5FEE6A85-BB93-49AB-8927-F1D780BB6727}/CalendarIcon.exe:
shasum: /Volumes/BOOTCAMP/Windows/Installer/{694E3E02-E14A-4BB2-A970-CF7F017FD5CC}/CalendarIcon.exe: Value too large to be stored in data type
shasum: /Volumes/BOOTCAMP/Windows/Installer/{82FCC407-A0E5-4B80-9241-5ABA78B61090}/CalendarIcon.exe: Value too large to be stored in data type
shasum: /Volumes/BOOTCAMP/Windows/Installer/{C8127F91-0244-4FF0-8014-0C432E15E09D}/CalendarIcon.exe: Value too large to be stored in data type
% grep 5b9f2adb8a4bd82b2794b5dc1cd90b71c967fdd9 Desktop/sums.txt
5b9f2adb8a4bd82b2794b5dc1cd90b71c967fdd9 /Volumes/BOOTCAMP/Windows/Installer/{29C6B346-C29C-40CE-89EB-DF7C149E0EB9}/CalendarIcon.exe
And now that I try to copy that file elsewhere… I can’t. Can’t access any of the contents. So is that SHA-1 the hash of a read error?
% md5 CalendarIcon.exe
md5: CalendarIcon.exe: Value too large to be stored in data type
I’ll boot into Windows and see what harm I can do there.
[Later: Deleting those installer folders fixes the imaging error!]
For anyone else who happens upon this in the future…
I rebooted into Windows and deleted the 5 directories mentioned by the find/sha errors. They appear to be more-or-less identical installer dregs from iCloud updates - and none of the ones mentioned in the error messages was the most recent version - so they are probably not necessary for system functioning. I expect I only needed to delete the one that contained the match for the error message, but I didn’t think deleting the others would do any harm.
And… Windows appears fine on reboot. iCloud is still working. And back on MacOS, when I tried a file-based/WIM image with WinClone it worked fine. That one copy of CalendarIcon.exe was almost certainly the entire problem.
So yay! I’ve got WinClone images being generated properly.
No idea what was actually wrong with the deleted file, though.
This is awesome and very, very helpful. I am going to incorporate it in Winclone to help with error checking and letting people know which files are causing the errors.
If you see something like it happen again and can figure out what is wrong with those files, I’d love to hear it. I was too gung ho to investigate further once I found something to delete.
I just ran into exactly the same problem. error88.
I tried exactly the same advice given here…but cannot find anything in that huge sums.txt file.
I dont even know what error 88 means ??
Is there any logfile with helpfull hints ?
Unfortunately I cannot copy volume to volume, because it is prevented by another error that the blocksizes differ from my IMacPro (4k) to my external SSD (512) , and I dont know how to change that blocksize!?
does anyone have the same experience, and can probably give my some hint how to get winclone (the most recent update) to run ?
…no reply !? …anyway … I found a solution based on the information here from tinkerbearnz.
found the logfile (was too obvious to my )
One line indicated a problem with a “concurrent changing filesize” ???
That one gave me a sha value (original and found).
I ran the commandline given in this thread , and searched in the created sums.txt file for that particular value.
Found the value with the corresponding real filename and Folderpath
…in my case a wes-file
6.booted into bootcamp-w10 …deleted that file and the whole folder (only crashlogs)
ran winclone again and successfully made the backup
just for information to all the others who will presumably run into the same problem
