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