I don’t often write about Insider Preview stuff in this blog because it mostly focuses on production Windows. But every now and then, something comes up that cries out for coverage. This time, it’s an incredibly gutsy, quick, and proactive maneuver from Macrium. The latest Windows 10 Skipahead release 18234 hit on Friday, September 7. Before that day was out, users were reporting issues trying to back that new release up using Macrium Reflect. Here’s what the error looks like, taken from the Macrium website’s patch announcement. Notably, this fix appeared the next day (September 8, on a Saturday). That’s right: Macrium patches Skipahead Preview Reflect Win10 bug. In fact, it does so exactly one day after the release goes live and the bug pops up. Over the weekend, no less. I’m in awe of their attentiveness and responsiveness!
I’m running 18234 on my Surface Pro 3. I was able to provoke this error message on that machine by running Reflect. Then, I applied the patch, and completed a successful backup.
Appreciating Macrium Patches Skipahead Preview Reflect Win10 Bug
Here’s the really interesting twist to this repair. According to Macrium’s website, the problem stems from Windows itself, not from an outright bug in Reflect. The title for the page of interest hints at this: “Windows 10 Insider Preview Build 18234 Bug.” The explanatory paragraph is entitled “What’s the problem?” and reads:
NTFS contains a series of meta data file records that describe the layout and format of the file system. One of these records is named$BITMAP and contains a series of ‘Bits’ in a data stream that indicate which clusters in the file system are in use and which are not. Each record has multiple attributes to further describe the record and location and size of data streams. The $FILE_NAME attribute contains the allocated and actual size of the data in the stream. For the $BITMAP record the $FILE_NAME attribute contains incorrect size information. This would appear to be a problem with, or an undocumented change to, the NTFS driver shipped with the OS. This caused the file system to update the $BITMAP record incorrectly at the time of installation.
If Backup Doesn’t Work, It Doesn’t Matter Who’s at Fault
Frankly, what blows me away about this is reaction time. Macrium figured this out and sussed out a fix within 24 hours of a new OS preview. That solution, apparently, retrieves the problem data using Windows APIs (which Macrium asserts are “unaffected by this problem”). Usually, Macrium reads system meta data directly, without using API calls. But for this patch they must’ve drawn upon that alternate source for the same data to fix an ostensible bug in the NTFS file system driver. Zounds!
My hat is off to these guys. Their understanding of their subject matter is inspiring, as is the quality and speed of their fix. One could argue (as they have, ever so gently) that it’s really not a problem with Reflect itself that’s causing the issue. But they fixed it anyway, and darned quickly, too. Even though Skipahead Insider Preview users are a tiny fraction of the overall Win10 user base, Macrium understands very well that they need backup just as urgently as do other users. Kudos to Macrium and their developers.
[Note:] Thanks to TenForums user Jimbo whose thread “Only patch and use Macrium update on Skippy 18234” alerted me to this situation and its fix. It helped me figure out the usual built-in update facility in Reflect wasn’t enough to address this special problem.