Finally tried running my main backup job from within Windows itself instead of WinPE. Rather disappointing so far. What took about half an hour now takes hours it seems...
Setting your connection to metered might cause you to miss out on other normal updates you might actually want. I remember originally Microsoft said that only critical updates would be downloaded over a metered connection, but now that Microsoft has switched to just monthly cumulative updates rather than individual updates, I’m not sure what the behavior is. As for WinPE vs WinRE, I’m personally using WinPE. I don’t need WiFi support and I don’t mind having to download the ADK from Microsoft, so those benefit should of WinRE don’t apply to me. If I ever need some feature that isn’t available in WinPE 1709 that becomes available by using WinRE after updating my Windows 10 environment, I may switch. But based on the latest Microsoft events, I honestly think that using WinRE is more likely to INTRODUCE a bug that wasn’t there before whenever I update Windows 10, so I kind of like the idea of having a consistent “platform” for Rescue Media.
Interesting, usually it’s Rescue that takes longer because it doesn’t use VSS, which means it ends up backing up more data (such as the Windows Search index and System Restore snapshots, for example) and until recently it also defaulted to the Balanced power scheme, whereas manually switching to High Performance could cut job times in half. But 7.2 now defaults Rescue to High Performance. The most common culprit for abnormally long job times within Windows and not within Rescue is third-party anti-virus if you’re running any.
Defender wouldn’t be the issue. Never heard of Hitman, although I also haven’t used third-party AV since Microsoft Security Essentials arrived (which has since been rolled into Defender), so I haven’t kept a close eye on what’s out there. If you haven’t already, try excluding the EXEs in the Reflect installation folder and the contents of your backup destination folder(s) from scanning.
No idea either. Maybe I'll switch it on again, and just see what happens wrt 1809. Won't 'Check for Updates'. Feel the same after my recent upgrade experience, which included new boot menu entries* ... Will stick to WinPE for now. (* A new 'Windows 10', and 'Windows 10 Setup' entries in the boot menu, above the regular 'Windows 10' and 'Macrium Reflect System Recovery' entries, and IIRC the latter no longer working ... something borked. Don't quite recall how I did recover in the end TBH as I think I also had issues with my boot CD, but here I am!). Thanks .
Brian, for me, the Macrium PEs have always loaded faster than the REs... and the 32-bit PEs are even faster than the 64-bit PEs. Almost all of my Recovery Media these days are 32-bit.
Froggie, in the Macrium Boot Menu builder, I don't even have a choice nowadays as to what type I want. I remember previously there were 4 options but it seems that has changed and I am getting a default setting. That's probably perfect for me not wanting to get into trouble
In the current BOOT Menu builder (v7.2), if you select the "Windows BOOT Menu" option, before you hit "Build," use the "Advanced" option at the bottom and it'll let you build the architecture you want.
Nope... that's just the architecture of the mini-Windows running in WinPE. Reflect can run under either architecture and the running Reflect can restore (or image) whatever is on the disk you wish to image, regardless of the on-disk architecture you are imaging or restoring.
I'll expand on TheRollbackFrog's answer to say that if you choose to use 32-bit WinPE while running 64-bit Windows, I don't believe RMBuilder will be able to pull drivers from your host OS into your Rescue Media build, since the host OS won't have 32-bit drivers available. That's particularly an issue for Windows 7 users who choose to build with WinPE 3.1 (based on the Win7 kernel) because the Windows 7 kernel doesn't have native support for, among other things, USB 3.0 -- so if you go this "disjoint architecture" route, you'd either need to furnish 32-bit drivers to RMBuilder manually or forego USB 3.0 support, whereas if you used 64-bit WinPE 3.1, the drivers already on your system could be pulled automatically. The same idea goes for things like RAID or network controller drivers. Using a 32-bit version of WinPE 5 or later would work around the USB 3.0 issue, and possibly other hardware since newer WinPE versions might support your hardware natively, but that won't be a guarantee.
I just installed the update for 7.2.3954. Rebooted as prompted. First BSOD I've seen on this PC in a couple of years. I assume it is related to this update and I am not rolling it out any farther until I see if others are having issues.
Looks like that release updated both the image mount driver as well as the CBT driver, the latter ironically to resolve some existing BSoD issues. Does the system you updated have CBT installed? If so and you're feeling up for testing, try removing the CBT component before updating (Control Panel > Macrium Reflect > Change > Modify > uncheck CBT) and see if you still get a BSoD on reboot after updating. And either way, sending the dump file generated by the BSoD you already encountered to Macrium would likely help determine underlying cause and hopefully a fix.
I do have the CBT installed. It booted fine the next 2 times so hopefully it won't happen again. I think the system made a dump. If I have time I will see what I can do.
No BSoDs here, Free or Paid - with no CBT though. (I always still have to uninstall the Free on one machine, setup won't run - not sure what's blocking it).
OK, I looked at the dump with Nirsoft's BlueScreenView and it names mrcbt.sys as the issue. What is the best way to me to get this to someone at Macrium?
SAME HERE! I rebooted after building the new PE folder and got the BSOD. Boot after BSOD but the Definition file does not show. When creating a new one, it bullds it with a (1) suffix. Any ideas what is going on here?
v 7.2.3954 has been released. Code: http://updates.macrium.com/reflect/v7/latest_release_notes.asp A Windows system restart, immediately after applying this update, seems to be compulsory. HTH
