If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||
|
|||
Macrium Error 9 And Trust in Microsoft
I ran into this error today, while making a backup
of the Win10 Insider HDD. It seems the $BITMAP information is incorrect on the Insider. This causes a problem with Macrium Reflect (and potentially other software of the backup persuasion). https://knowledgebase.macrium.com/di...uild+18234+Bug The thing is, Microsoft has been maintaining the release number on the NTFS file system at 3.1 all through the Win10 period. Indicating that all the modern OSes are using *exactly* the same file system features. It has not been indicating that the design of the file system has changed. There's basically no version control, over what file system features have been buggered with. First it was the $MFTMIRR getting broken. Then, it was addition of some Reparse Point types, which seem to be handled by other OSes OK, but the other OSes, if you run CHKDSK, may do weird things to the partition. I don't really feel all that comfortable about that one. I don't dare run WinXP CHKDSK on an NTFS partition that's been over in the Win10 machine, because I no longer know if that is safe. And now, it appears that (perhaps) the $BITMAP is being lazy-evaluated, to avoid "wearing" an SSD by writing that part while the OS is running. By not writing it, if the OS crashes or there is a power failure, what protects that field ? Can the Journal be relied on, plus boot-up cleanup actions, to restore the $BITMAP properly ? Is there some nice web documentation from Microsoft on the subject ? ******* OK, so they caused my copy of Macrium to fail. This means I'm forced to bump up the version of Macrium, to cover that disk. Then, when 1903 is released, it's going to have that "bug" in it. The problem then spreads to all the Win10 installs which will be upgraded in a month or two. Macrium claims some backup software already calls an API, in place of reading the $BITMAP directly, and they will get the right answer. But which programs do that ? ******* And then the question is, why should we be trusting Microsoft exactly ? 1) Changing a spec, without updating the version number. 2) Seemingly causing "partner" companies to chase after them with a mop and pail. VirtualBox went through hell maybe a year or more ago, and like Macrium, didn't make a big stink about the extra labor entailed. 3) Destroying trust from an end-user perspective, by adding more and more "special handling" procedures for the "rolling release OS". I'm rapidly losing the ability to keep track of what I should be doing! To give a vivid example, if I boot Win10 and have data disks connected, Win10 *will* damage the $MFTMIRR. Then, I have to run Win7 CHKDSK to repair it. The CHKDSK log makes no mention that the $MFTMIRR was repaired, but it has been. So when I'm planning procedures, I have to remember: 29) *Don't* boot Win10, while the data disks are connected, or you'll have to slide the Win7 disk back in, boot up, and CHKDSK all the NTFS partitions. Such is life, Paul |
#3
|
|||
|
|||
Macrium Error 9 And Trust in Microsoft
MrTsquare wrote:
In article , lid says... I ran into this error today, while making a backup of the Win10 Insider HDD. It seems the $BITMAP information is incorrect on the Insider. This causes a problem with Macrium Reflect (and potentially other software of the backup persuasion). https://knowledgebase.macrium.com/di...uild+18234+Bug The thing is, Microsoft has been maintaining the release number on the NTFS file system at 3.1 all through the Win10 period. Indicating that all the modern OSes are using *exactly* the same file system features. It has not been indicating that the design of the file system has changed. There's basically no version control, over what file system features have been buggered with. First it was the $MFTMIRR getting broken. Then, it was addition of some Reparse Point types, which seem to be handled by other OSes OK, but the other OSes, if you run CHKDSK, may do weird things to the partition. I don't really feel all that comfortable about that one. I don't dare run WinXP CHKDSK on an NTFS partition that's been over in the Win10 machine, because I no longer know if that is safe. And now, it appears that (perhaps) the $BITMAP is being lazy-evaluated, to avoid "wearing" an SSD by writing that part while the OS is running. By not writing it, if the OS crashes or there is a power failure, what protects that field ? Can the Journal be relied on, plus boot-up cleanup actions, to restore the $BITMAP properly ? Is there some nice web documentation from Microsoft on the subject ? ******* OK, so they caused my copy of Macrium to fail. This means I'm forced to bump up the version of Macrium, to cover that disk. Then, when 1903 is released, it's going to have that Funny you should mention it... I don't understand most of what your post talks about, but I locked onto "file system, Macrium and power glitch". I updated my 5 year old win7home system to win10home last week. Did the update approach rather than a clean install. (It appears to have activated with no problem at all.) I have been running Macrium Free for a few years with no issues needing further exploration. After installing Win10 and finding that it wasn't so bad after all, just a little different, I decided that I would need to start over on my backups so I deleted all previous backups and their XML command files and started over. Listed below are my 4 drives. Samsung SSD 840 EVO 500GB [Hard drive] (500.11 GB) -- drive 3, s/n S1DKNEAF600219Y, rev EXT0DB6Q, SMART Status: Healthy ST1000DM003-1CH162 [Hard drive] (1000.20 GB) -- drive 2, s/n S1DH893W, rev CC49, SMART Status: Healthy ST31000528AS [Hard drive] (1000.20 GB) -- drive 0, s/n 6VP40RF6, rev CC3E, SMART Status: Healthy WDC WD10EACS-00D6B1 [Hard drive] (1000.20 GB) -- drive 1, s/n WD-WCAU43948314, rev 01.01A01, SMART Status: Healthy Updated Macrium to 7.2 and did the image on the SSD and drive 0 with no problem (drive 1 is the target). But then and somewhere in there we had a wide area electrical glitch (just a second or so). When I went to select drive 2 I found that macrium wouldn't select it and that as far as Macrium knows, there is no file system on drive 2!! I honestly don't know if Macrium could see a file system on disc 2 before the glitch. Thinking about it for a while, I exited and rebooted... no change. Tried to go on line to the Macrium forums and post a question, but that didn,t work cause I have the free version of Macrium. Ok, maybe Macrium got sick. Deleted all of the backups and command files again and deleted/uninstalled Macrium. Reinstalled a new download of Macrium and it still can't see disc 2. Ok, get this... Win10Home is still perfectly happy with disc 2 (see the Belarc status of the drives above). Macrium is the only thing unhappy with drive 2. Any thoughts? T2 You can do a backup from your Macrium Emergency CD. That would prove that the disk detection, without the Windows Registry to muddle things, was working. Most of the failure mechanisms I know of, happen when you try to run the backup. Just sitting in the main screen, there should be fewer things to go wrong. And the Error 9 I was getting yesterday, I think it was happening in the middle of a backup of four partitions or so. Paul |
#4
|
|||
|
|||
Macrium Error 9 And Trust in Microsoft
In article ,
lid says... MrTsquare wrote: In article , lid says... I ran into this error today, while making a backup of the Win10 Insider HDD. It seems the $BITMAP information is incorrect on the Insider. This causes a problem with Macrium Reflect (and potentially other software of the backup persuasion). https://knowledgebase.macrium.com/di...uild+18234+Bug The thing is, Microsoft has been maintaining the release number on the NTFS file system at 3.1 all through the Win10 period. Indicating that all the modern OSes are using *exactly* the same file system features. It has not been indicating that the design of the file system has changed. There's basically no version control, over what file system features have been buggered with. First it was the $MFTMIRR getting broken. Then, it was addition of some Reparse Point types, which seem to be handled by other OSes OK, but the other OSes, if you run CHKDSK, may do weird things to the partition. I don't really feel all that comfortable about that one. I don't dare run WinXP CHKDSK on an NTFS partition that's been over in the Win10 machine, because I no longer know if that is safe. And now, it appears that (perhaps) the $BITMAP is being lazy-evaluated, to avoid "wearing" an SSD by writing that part while the OS is running. By not writing it, if the OS crashes or there is a power failure, what protects that field ? Can the Journal be relied on, plus boot-up cleanup actions, to restore the $BITMAP properly ? Is there some nice web documentation from Microsoft on the subject ? ******* OK, so they caused my copy of Macrium to fail. This means I'm forced to bump up the version of Macrium, to Macrium can't see disc 2 from there either. Everything still works fine in Win10Home. T2 |
#5
|
|||
|
|||
Macrium Error 9 And Trust in Microsoft
MrTsquare wrote:
In article , lid says... MrTsquare wrote: In article , lid says... I ran into this error today, while making a backup of the Win10 Insider HDD. It seems the $BITMAP information is incorrect on the Insider. This causes a problem with Macrium Reflect (and potentially other software of the backup persuasion). https://knowledgebase.macrium.com/di...uild+18234+Bug The thing is, Microsoft has been maintaining the release number on the NTFS file system at 3.1 all through the Win10 period. Indicating that all the modern OSes are using *exactly* the same file system features. It has not been indicating that the design of the file system has changed. There's basically no version control, over what file system features have been buggered with. First it was the $MFTMIRR getting broken. Then, it was addition of some Reparse Point types, which seem to be handled by other OSes OK, but the other OSes, if you run CHKDSK, may do weird things to the partition. I don't really feel all that comfortable about that one. I don't dare run WinXP CHKDSK on an NTFS partition that's been over in the Win10 machine, because I no longer know if that is safe. And now, it appears that (perhaps) the $BITMAP is being lazy-evaluated, to avoid "wearing" an SSD by writing that part while the OS is running. By not writing it, if the OS crashes or there is a power failure, what protects that field ? Can the Journal be relied on, plus boot-up cleanup actions, to restore the $BITMAP properly ? Is there some nice web documentation from Microsoft on the subject ? ******* OK, so they caused my copy of Macrium to fail. This means I'm forced to bump up the version of Macrium, to Macrium can't see disc 2 from there either. Everything still works fine in Win10Home. T2 OK, when you have the Macrium Rescue CD booted, you have some tools: 1) A Command Prompt icon. 2) "diskpart" in Command Prompt (equiv to Disk Management) diskpart list disk select disk 2 list partition select partition 3 detail partition exit That's how you get some WinPE detected details about your disks. You can iterate over disks and partitions, and dump info about all of them. 3) Macrium has its own Explorer-like icon on the desktop. Look in there for the partitions. Are they present ? Or missing ? If present, it implies Macrium "remembers" something about that disk. But, where would that info be stored ? Is there a "LOCK" file at the top root level of any partition on that disk, signaling the disk is "in usage by Macrium" ? The thing is, if there are identical disk identifiers, that can cause a problem. But normally, you only see evidence of that system-wide, if Disk Management shows a disk on the left hand side as being "Offline". That's evidence of one of two things: a) Two disks have the same identifier, coming from around byte 442 or so of the MBR. Other disk identifiers which could be identical, don't hurt anything. Identical labels on disks like "DATA" "DATA" "WIN10" "WIN10" don't hurt either. Only the disk identifier around byte 442 is an issue. b) You can manually set a disk to the Offline state, which helps if TXF (NTFS transactions) won't allow a USB hard drive (HDD) to be Safely Removed. When this is done on a persistent OS, the OS "remembers" the offline state, so you have to switch it online again the next time you're in that OS. Since you see the disk under all ordinary circumstances, we can't blame either of these reasons for the indigestion in Macrium. I'm stumped as to what to blame it on. Nothing is a match. ******* Using a Linux LiveCD, you can install "disktype" and do sudo disktype /dev/sdb # dump info on disk 2 and it will tell you what the partitions are. Some file systems, it uses multiple checks that the file system is what it says it is. So if it said "5 of 5 FAT32", then you'd know that the five characteristic checks passed. Not all file systems have thorough checks like that. And if I was in the room there right now, that's the only additional check I'd do. I have a Cygwin copy of "disktype.exe", which I use on this machine, and that saves me the bother of booting Linux. If you already have Cygwin set up, and know how to use the package manager to add stuff, it would take no time at all to add that one. http://disktype.sourceforge.net/ No one seems to be interested in doing a Windows version, which would likely require some small namespace tweaks in there somewhere. The Cygwin version still uses this syntax, which is not a Windows syntax. sudo disktype /dev/sdb # sdb would be the second row of Disk Management ******* The fact that $MFTMIRR is getting damaged by Win10, doesn't seem to affect Macrium that I can see. And the $BITMAP problem should not have affected things when using the Macrium Rescue CD, since the file system is "at rest" at that point, and the $BITMAP is likely correct at that point in time. Paul |
#6
|
|||
|
|||
Macrium Error 9 And Trust in Microsoft
MrTsquare wrote:
In article , lid says... MrTsquare wrote: In article , lid says... I ran into this error today, while making a backup of the Win10 Insider HDD. It seems the $BITMAP information is incorrect on the Insider. This causes a problem with Macrium Reflect (and potentially other software of the backup persuasion). https://knowledgebase.macrium.com/di...uild+18234+Bug The thing is, Microsoft has been maintaining the release number on the NTFS file system at 3.1 all through the Win10 period. Indicating that all the modern OSes are using *exactly* the same file system features. It has not been indicating that the design of the file system has changed. There's basically no version control, over what file system features have been buggered with. First it was the $MFTMIRR getting broken. Then, it was addition of some Reparse Point types, which seem to be handled by other OSes OK, but the other OSes, if you run CHKDSK, may do weird things to the partition. I don't really feel all that comfortable about that one. I don't dare run WinXP CHKDSK on an NTFS partition that's been over in the Win10 machine, because I no longer know if that is safe. And now, it appears that (perhaps) the $BITMAP is being lazy-evaluated, to avoid "wearing" an SSD by writing that part while the OS is running. By not writing it, if the OS crashes or there is a power failure, what protects that field ? Can the Journal be relied on, plus boot-up cleanup actions, to restore the $BITMAP properly ? Is there some nice web documentation from Microsoft on the subject ? ******* OK, so they caused my copy of Macrium to fail. This means I'm forced to bump up the version of Macrium, to Macrium can't see disc 2 from there either. Everything still works fine in Win10Home. T2 I can find trivial examples of failures in Macrium, but they don't necessarily match your symptoms. https://www.sevenforums.com/backup-r...s-missing.html https://knowledgebase.macrium.com/di...isks+or+drives I tested mixing MBR and GPT disks, and that isn't a problem. Even if the boot OS is Windows 7. Tested with Win10 too. Mixed drive types in the same machine ? All detected. And it's not VSS related, because the CD doesn't use or need VSS to make the file systems quiescent. The X: partition is the OS RAMdrive when the CD is booted. We never back up X: when using the CD, and things like C: drive on the HDD don't then need the services of VSS to be captured. Macrium should be "content" with a superficial analysis of the drives before doing anything. Checking the partition type fields, examine file system header sectors, that level should be enough. It doesn't need to look at $BITMAP. That's only necessary during an actual backup run. It suggests "disktype" is the tool we need to use now, to have a look at the disk(s) and see if there is some superficial issue. I can't believe there is otherwise a "marker" or "flag", stored somewhere, that can be seen from both the OS-installed version, as well as the CD running version. Some softwares can and do probe a Registry file in an offline way, so it's theoretically possible to carry info to an emergency CD that way, but then if the customer has two OS drives... there could be mayhem depending on which OS it randomly selects. I actually had an example of that "random mayhem" with Macrium, while working on the "error 9" problem. I installed the newest version, and asked it to make a rescue CD. It finished the job, telling me it used the "WinRE" that the OS provided. But little did I know, it grabbed a WinRE off another disk drive! It grabbed an 18xxx version of a WinRE from my Win10 Insider disk, jammed that onto the CD, and even fouled up the bitness. It put a x64 WinRE setup onto a x86 CD, then when I boot the CD, Macrium won't autolaunch. I navigate to the Program Files folder on the CD and manually launch and it keeps reporting the "software is not compatible". When I check the version of .wim it's using, I see it's scarfed from my Insider disk drive, not something I selected or approved. But there is a preference inside the tool, that claims to control this, that I wasn't even aware existed... Until ruining a CD-R learning about it :-( So yeah, Macrium has some surprises. After fiddling around a bit, I coerced a good piece of media out of it. ******* Using the OS-installed Macrium, I might try to use Process Monitor to discover what it's doing when it sees the "invisible disk drive". But since I am not reproducing any invisible drives here, and neither am I finding any lock files on the roots of any partitions, I doubt I can learn something using Process Monitor here, that'll help you. I've actually traced entire Macrium Reflect backups with Process Monitor, and it does have the capacity to do a 20 minute session. But the 6GB trace collected does take a while to analyze, and the only way I could reasonably deal with it on that experiment, was knowing that only a few seconds of stuff at the beginning and at the end of the backup, was the relevant stuff. And 5.9GB of trace events in the middle could be ignored. https://docs.microsoft.com/en-us/sys...nloads/procmon In your case, just the "startup transient" lasting maybe ten to fifteen seconds, needs to be traced and checked. And setting a filter for the main Macrium executable (during post trace analysis), could cut down on the noise. The File menu has a tick box you remove, when you want the trace to "stop". and once the Macrium initial screen with the missing disk is painted, you can "stop trace" and go through the trace results. *No* experiment with Process Monitor is "easy". *Every* experiment is a needle in a haystack. For example, once I went through 100,000 registry operations, and managed to find a single erroneous registry operation involving two sound cards. The installer for one sound card had damaged a setting the other one was using (they both needed it), and I got lucky and happened to notice this while scrolling slowly through the results. With such masses of accesses, it's pretty difficult to filter out all the noise. The OS can make 10,000 accesses a second to RAM-cached registry info, just to give some idea how there can be noise in the trace. It's really impressive to capture such joyous activity when you're expecting an idle desktop to "not be doing anything: :-/ And it also means you'll be shoveling crap forever, looking for the relevant ops. But this is the tool we're offered, and I'm not complaining. If it wasn't for that, we would have practically nothing to use. Maybe 10% of the time, I learn something by using it. Paul |
#7
|
|||
|
|||
Macrium Error 9 And Trust in Microsoft
In article ,
lid says... MrTsquare wrote: In article , lid says... MrTsquare wrote: In article , lid says... I ran into this error today, while making a backup of the Win10 Insider HDD. It seems the $BITMAP information is incorrect on the Insider. This causes a problem with Macrium Reflect (and potentially other software of the backup persuasion). https://knowledgebase.macrium.com/di...uild+18234+Bug The thing is, Microsoft has been maintaining the release number on the NTFS file system at 3.1 all through the Win10 period. Indicating that all the modern OSes are using *exactly* the same file system features. It has not been indicating that the design of the file system has changed. There's basically no version control, over what file system features have been buggered with. First it was the $MFTMIRR getting broken. Then, it was addition of some Reparse Point types, which seem to be handled by other OSes OK, but the other OSes, if you run CHKDSK, may do weird things to the partition. I don't really feel all that comfortable about that one. I don't dare run WinXP CHKDSK on an NTFS partition that's been over in the Win10 machine, because I no longer know if that is safe. And now, it appears that (perhaps) the $BITMAP is being lazy-evaluated, to avoid "wearing" an SSD by writing that part while the OS is running. By not writing it, if the OS crashes or there is a power failure, what protects that field ? Can the Journal be relied on, plus boot-up cleanup actions, to restore the $BITMAP properly ? Is there some nice web documentation from Microsoft on the subject ? ******* Maybe I have been misleading you by saying Macrium couldn't see the disc. As I said in my first post, Macrium apparently will not select disc2 apparently cause it cannot see a file system on disc2. The others show NTFS, but disc2 shows "file system empty". Kindof a black hole disc. That's why I tried replacing Macrium, thinking that it had been corrupted by the power glitch. T2 |
#8
|
|||
|
|||
Macrium Error 9 And Trust in Microsoft
MrTsquare wrote:
In article , lid says... MrTsquare wrote: In article , lid says... I ran into this error today, while making a backup of the Win10 Insider HDD. It seems the $BITMAP information is incorrect on the Insider. This causes a problem with Macrium Reflect (and potentially other software of the backup persuasion). https://knowledgebase.macrium.com/di...uild+18234+Bug The thing is, Microsoft has been maintaining the release number on the NTFS file system at 3.1 all through the Win10 period. Indicating that all the modern OSes are using *exactly* the same file system features. It has not been indicating that the design of the file system has changed. There's basically no version control, over what file system features have been buggered with. First it was the $MFTMIRR getting broken. Then, it was addition of some Reparse Point types, which seem to be handled by other OSes OK, but the other OSes, if you run CHKDSK, may do weird things to the partition. I don't really feel all that comfortable about that one. I don't dare run WinXP CHKDSK on an NTFS partition that's been over in the Win10 machine, because I no longer know if that is safe. And now, it appears that (perhaps) the $BITMAP is being lazy-evaluated, to avoid "wearing" an SSD by writing that part while the OS is running. By not writing it, if the OS crashes or there is a power failure, what protects that field ? Can the Journal be relied on, plus boot-up cleanup actions, to restore the $BITMAP properly ? Is there some nice web documentation from Microsoft on the subject ? ******* OK, so they caused my copy of Macrium to fail. This means I'm forced to bump up the version of Macrium, to Macrium can't see disc 2 from there either. Everything still works fine in Win10Home. T2 The OS-installed version, has a registry entry that can be used to "exclude" disks from the backup screen. Such as excluding the disk that will be used to hold all the ..mrimg files and won't itself be backed up. https://knowledgebase.macrium.com/di...lect+starts+up HKLM : SOFTWARE : Macrium : Reflect Disks DWORD 2 # Ignore "2", whatever that is The reason for having the feature, is to save time parsing a complicated drive structure. My test though with Process Monitor, shows that for most regular disks, not a lot of I/O is done on a disk at startup. EXT4 partitions get a lot more inspection than NTFS ones do. The above page was found in this "jumbo" articles page. https://knowledgebase.macrium.com/di...roubleshooting Paul |
#9
|
|||
|
|||
Macrium Error 9 And Trust in Microsoft
Paul wrote:
I ran into this error today, while making a backup of the Win10 Insider HDD. It seems the $BITMAP information is incorrect on the Insider. This causes a problem with Macrium Reflect (and potentially other software of the backup persuasion). https://knowledgebase.macrium.com/di...uild+18234+Bug The thing is, Microsoft has been maintaining the release number on the NTFS file system at 3.1 all through the Win10 period. Indicating that all the modern OSes are using *exactly* the same file system features. It has not been indicating that the design of the file system has changed. There's basically no version control, over what file system features have been buggered with. First it was the $MFTMIRR getting broken. Then, it was addition of some Reparse Point types, which seem to be handled by other OSes OK, but the other OSes, if you run CHKDSK, may do weird things to the partition. I don't really feel all that comfortable about that one. I don't dare run WinXP CHKDSK on an NTFS partition that's been over in the Win10 machine, because I no longer know if that is safe. And now, it appears that (perhaps) the $BITMAP is being lazy-evaluated, to avoid "wearing" an SSD by writing that part while the OS is running. By not writing it, if the OS crashes or there is a power failure, what protects that field ? Can the Journal be relied on, plus boot-up cleanup actions, to restore the $BITMAP properly ? Is there some nice web documentation from Microsoft on the subject ? ******* OK, so they caused my copy of Macrium to fail. This means I'm forced to bump up the version of Macrium, to cover that disk. Then, when 1903 is released, it's going to have that "bug" in it. The problem then spreads to all the Win10 installs which will be upgraded in a month or two. Macrium claims some backup software already calls an API, in place of reading the $BITMAP directly, and they will get the right answer. But which programs do that ? ******* And then the question is, why should we be trusting Microsoft exactly ? 1) Changing a spec, without updating the version number. 2) Seemingly causing "partner" companies to chase after them with a mop and pail. VirtualBox went through hell maybe a year or more ago, and like Macrium, didn't make a big stink about the extra labor entailed. 3) Destroying trust from an end-user perspective, by adding more and more "special handling" procedures for the "rolling release OS". I'm rapidly losing the ability to keep track of what I should be doing! To give a vivid example, if I boot Win10 and have data disks connected, Win10 *will* damage the $MFTMIRR. Then, I have to run Win7 CHKDSK to repair it. The CHKDSK log makes no mention that the $MFTMIRR was repaired, but it has been. So when I'm planning procedures, I have to remember: 29) *Don't* boot Win10, while the data disks are connected, or you'll have to slide the Win7 disk back in, boot up, and CHKDSK all the NTFS partitions. Such is life, Paul From that article, the patch they show for the Home (payware) version of Macrium Reflect that I have and for Windows 10 x64 is: http://updates.macrium.com/reflect/v....3570x6415.exe Well, all of them show the same filename up until the last 5 characters, which a x86 (32-bit OS) x64 (64-bit OS) xx Macrium Reflect edition (00 = free, 15 = home/workstation, 20 = server, 25 = server plus) The patch version is same for all of them: upgrade from 7.1.3317 to 7.1.3570. I checked on my Win 7 x64 Home host and Macrium Home is at 7.2.4063. So, my Macrium install is already a minor version later (.2 instead of .1). With its auto-check option enabled, Macrium Reflect tells me when there is a new version available, and I remember updating it a couple weeks ago, and maybe a month, or two, before that. The article you mention is dated back to September 08, 2018: more than 6 months ago. You should've been notified 5 times since then about more updates since then unless you disabled Reflect's update check. http://updates.macrium.com/reflect/v...ls7.2.4063.htm That's a release history of updates. Don't know if it is a complete list. It goes from 7.1.3317 to 7.2.3811 - which skips the patched level of 7.1.3570. No mention of "bitmap" in that release history. If you updated to any of the 7.2 versions, you got the patch already. https://knowledgebase.macrium.com/di...um+Reflect+7.2 There was nothing there about the $BITMAP fix. There is mention of a change in their CBT (Changed Block Tracker) driver. https://knowledgebase.macrium.com/di...+Block+Tracker However, I don't see their tracking feature is related to the $BITMAP record or its attributes within NTFS. The patch, if coded correctly, should *not* install if you have a version of Reflect later than 7.1.3570, especially since you should already be on 7.2. Plus Macrium's article addressed the *Insider Build* of Windows 10. That doesn't mean the bug was exhibited in the release build. From the Macrium article: 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. The fault isn't with the NTFS specification or implementation but with whatever is writing the values into those fields (attributes) of the $BITMAP record. It isn't NTFS that is broke. It is the driver that came with that pre-release, er, Insider build of Windows 10. Well, if you choose to run the Insider builds then you also choose to be their unpaid voluntary alpha tester (versus the released builds which have users operate as unpaid involuntary beta testers). Insider builds should not be installed on mission-critical, important, or daily-use hosts. That's for tinkering, like having your regular commuter car but a clunker sitting in the garage on which you tinker and proclaim that one day you'll get all fixed and spiffed up. The problem isn't with NTFS. It's with the driver in the Insider build (back then) that writes into the NTFS records. I can give you a form to fill out. Just because a form field says "First name" doesn't preclude you, the writer, from entering you age in that field. So, as for the real cause of the problem - the Insider driver - did you check if it made it unchanged into the release builds? |
Thread Tools | |
Display Modes | Rate This Thread |
|
|