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

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

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

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

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

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

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

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

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?