The numbers for last week are even worse: * v7: 2 GB incremental image in 40 minutes (Read 2.2 Gb/s, Write 14.0 Gb/s) PS: I noticed the line "Write Method: Using File System Cache" in the v7 logs, but don't see it in the v6 logs. Is that OK?
The Write Method log item is new for V7 because at some point within V7, Reflect started testing both write methods on new destinations to see which was faster, especially because some AV solutions dramatically slowed down one or the other. With V6, you had to choose one or the other, and that setting applied to all destinations. You can view these decisions, including their benchmarks, and override the auto-determined write methods under the Backup menu > Disk Write Performance. Are you absolutely positive that the logs say nothing about consolidation either at the beginning or end of the job, depending on whether "Run purge before backup" is enabled? That's the only situation where I've seen this combination of long run times and implausibly high I/O figures as you have (or impossibly high in the case of your write speeds if the target is a SATA disk). If you definitely don't have consolidations occurring, it would've been nice to test the effect of updating to V7 separately from updating to Win10 1809, but at this point, the fact that you're running Incrementals means you have a paid license, so you should consider submitting a support ticket to Macrium at helpdesk.macrium.com. Even if you bought V7 more than a year ago and are just now upgrading, in which case you'd be past your "formal" support period, Macrium still seems to offer support on a discretionary basis.
I'm not 100% sure, but can't check right now. I upgraded from v6 (paid) to v7 (paid) this Black Friday, so I do indeed have support. Will contact them.
Have you gone thru the process using Diskpart to make the USB key bootable. I don't have the link handy but you can google for it
Hello Pete, You are most welcome ... There used to be a time when I would have issues getting an UFD to boot and that link helped me. I have made it a practice that whenever I create a boot-able UFD on a new UFD, for the first time, or change the boot environment (for example: creating a Macrium UFD on an UFD that contains TBWinRE), I go through those steps in that link first. A while back, I noticed with a Macrium update something that persuaded me to do this. I had an UFD with a customized TBWinRE on it and I built the Macrium rescue environment on top of it assuming the process would overwrite the entire UFD. I just happened to browse the contents of the UFD afterwards and noticed that were were some files left on it from the previous TBWinRE. Since that time, I now go through the steps outlined in that link when changing an UFD from one boot environment to another. I also go through those steps when I create a boot-able UFD that is on a new UFD or previously used to only store files. Since I have been doing this, I have never had issues building a working boot-able UFD. It may be overkill but it works for me. On a side note: I do not see these issues when I create a boot-able UFD with TeraByte products as the UFD always gets formatted during the creation. Evidently, Macrium does not format the UFD first and it creates its files while leaving any previous files contained on the UFD intact.
Reflect's Rescue Media wizard used to be non-destructive, i.e. it would only add or update Rescue Media files and leave the rest of the drive intact, mostly out of an abundance of caution in case users were using the same device for Rescue Media and actual backups, which some people do. The new Rescue Media Builder in 7.2 supports destructively partitioning and formatting flash drives, but it will only do that if it can't find a suitable partition already on the UFD to work with (and after warning the user). If it finds a suitable partition, it will maintain its non-destructive behavior. I personally think this is the right approach, and I personally haven't had any cases where initially having other items left over on the flash drive prevented my Rescue Media from working, and then going through a manual build resolved the issue. The only case I can think where this MIGHT be an issue would be if the UFD was previously partitioned on a Linux or pre-Vista system, in which case it might not have the correct MBR bootstrap code and/or partition boot sector to use Windows Bootmgr, which is what Windows PE uses, but I haven't tested this scenario. This would also only affect Legacy BIOS systems, not UEFI systems. But there's nothing inherently problematic about extra files being left around, even from other bootable environments. It can be messy and certainly doesn't add any value, but as long as all Rescue Media files were all successfully written to the UFD, then other data won't interfere simply by existing on the UFD.
Thanks Pete, I do remember this particular issue but that was a while ago and since the stick is bootable on at least two other pc, I think this time the problem is not with the stick but just with one of the pc. Since that one works with a cd, I can take my time looking for a solution - Rufus or otherwise.
Has anyone had issues with the manual update check malfunctioning, as in it does nothing? I believe this popped up a few updates ago. I turned off hourly background checks, but kept on daily check for software updates. Regardless, I don't think I'm getting any sort of check. When I click on the check update button, nothing happens. It's supposed to report even if a new update is not there. Another PC on the same LAN behaves correctly.
Small update: I solved my boot issues on my ancient PC. Reflect v7 has the same bug as v6 had: when the disk used to create the ISO file is full (I use a RAM drive) Reflect still reports successful image creation, while in reality the image built is incomplete. Hence it does not boot properly... With some help from Macrium I learned how to include the drivers for my ancient video card. The rescue image can run in 2560 x 1440 now. Macrium is still investigating the extremely slow imaging on the other PC.
How did you do this? I wasn't aware WinPE could even accept "external" video drivers. I also wonder if it would work on UEFI systems since it uses a separate mechanism for handling video output, but if it's an old PC I'm guessing you can't test that there. And just purely out of curiosity, why was 1600x1200 not enough resolution and/or a usable aspect ratio for Rescue in your case? Or was it just a principle thing?
It was a principle thing... It can be done like this: https://forum.macrium.com/FindPost9080.aspx (I did it a little bit different because I found this post only after accomplishing this)
Interesting, I thought Reflect Rescue would only load network, storage, and USB drivers and would ignore other type of drivers even if they were present in that folder. Learn something every day I guess.
After upgrading from v1803 build 17134.441 to v1809 build 17763.194 on a Win 10 Pro x64 machine, I get this error when trying to do a full backup. Any idea what the problem could be (looks like VSS), and how to get around it? This occurred after a reinstall also (as well as recreating new rescue media). Code: Backup aborted! - Failed To Create Volume Snapshot. Failed - 0x80042302 - IDispatch error #8450 Starting Image - Wednesday, December 12, 2018 14:44:32 Initializing Write Method: Using File System Cache Destination Drive: My Passport 2TB (E:) - Free Space 293.40 GB Free space threshold: Delete oldest backup sets when free space is less than 5.00 GB Creating Volume Snapshot - Please Wait Failed: Failed - 0x80042302 - IDispatch error #8450 - Retrying without VSS Writers ERROR: COM call "m_pVssObject->InitializeForBackup()" failed. - Returned HRESULT = 0x80042302 - Error text: ERROR: COM call "m_pVssObject->BackupComplete(&pAsync)" failed. - Returned HRESULT = 0x80042301 - Error text: VSS_E_BAD_STATE ERROR: COM call "m_pVssObject->InitializeForBackup()" failed. - Returned HRESULT = 0x80042302 - Error text: Gathering Windows Events - Please Wait Backup aborted! - Failed To Create Volume Snapshot. Failed - 0x80042302 - IDispatch error #8450 Edit: Guess I should've tried Other Tasks>Fix VSS Problems... Just saw that now.
You don't say if 'Fix VSS Problems' solved your issue, or which version of Reflect you're running. I've had VSS problems with all 7.2.x releases of Reflect to date. They appear to be related to CBT as the problems do not occur unless CBT is installed. There is a post on the Macrium Support Forum that a fix is forthcoming in the next release. If you still have the problem and are running 7.2, you might want to try removing the CBT feature.
I didn't try 'Fix VSS Problems...' after upgrading to v1809 because I only saw that option after I rolled back to v1803 (sorry, should have mentioned that I imaged back to v1803!). I am running MR v7.2.3906, but without CBT installed.
Hmmm. And still experiencing the problem. So much for my theory. 7.2.3906 is running fine (sans CBT) on the only machine I have running W10 Home 1803. 7.2.3811 (sans CBT) is running fine on W10 Pro 1803 and W7. I've backed off updating anything else because this VSS problem is a showstopper.
To be clear @layman, now that I am back on Win 10 Pro 1803, MR v7.2.3906 (sans CBT) is running fine. The problem only occurred after updating to 1809, so I was scared off - yes it is a showstopper! I just saw afterwards that there is a 'Fix VSS Problems...' option, and wondered if I should have tried that while I was still on 1809. But there were other problems also, like new Boot Menu options ... , so I will give 1809 a rest for a while.
So I tried imaging my SSD from within Windows instead of WinPE for the first time and now I'm in trouble... I created a job and PowerShell script to execute that job. By accident I double-clicked on the menu item for that file. Two backups started and I stopped one. The other one failed at the end because there was insufficient space. End result: no backup, and about 20 GB of disk space lost on the drive that should hold the image. 1) How can I regain this lost space? 2) How much space does VSS need to make sure a backup can succeed?
Turn off MIG. Maybe this file has an attribute "hidden". Check occupied space with WizTree or TreeSize.
Offline I got the suggestion to use WinDirStat (similar space check tool). Turns out that in an experiment one week ago I apparently stored the SSD image in a different location... ("eating up the space") Problem solved!
I usually eat the dog food by updating to new Win10 releases as soon as they're available, mostly because I work in IT and feel it's important to be aware of what the new release brings (good or bad, purposely or accidentally), but with all of the mess around 1809 even AFTER the re-release, I've officially switched my main system's Windows Update from the default "Semi-Annual Channel (Targeted)" to the "Semi-Annual Channel". Those names used to be "Current Branch" and "Current Branch for Business". The latter option causes your system not to retrieve new Windows 10 releases until they've been deemed ready for broad business rollouts, rather than "targeted" deployments, and historically that's been about 4 months after the general release. Unfortunately this is only available for Win10 Pro and above. Apparently Microsoft considers all Win10 Home users to have opted into "targeted" testing. The Windows 10 rollercoaster has just gone completely off the rails with 1809 IMHO, and there were significant initial issues with both 1803 and 1709 before it. I really hope these fumbles cause Microsoft to back off to annual releases at most, because nobody seems to want this 6-month cadence. Consumers seem to hate seemingly trading one set of bugs for another every 6 months, since Microsoft decides not to fix certain things until the next major release but then breaks things that previously worked, and IT departments definitely hate having to prepare and test new corporate images every 6 months. And frankly there just haven't been that many compelling features across all of these releases. I've read articles that Microsoft was considering fewer releases due to customer feedback even before the 1809 fiasco, so hopefully this moves the needle further in that direction. It's almost enough to make me want to switch to Win10 LTSC (formerly LTSB), but that's formally only available to volume licensing and MSDN customers, and unfortunately the only options there are 1507 (original), 1607 (Anniversary), and....1809. If only I could get an LTSC release of 1709, since that added a few things I legitimately do want, such as the Hyper-V "default switch" and support for multi-partition flash drives. Sigh....
, though I may give it one more go before the general business rollout ... Set my Home machine to 'Metered connection' as well, which may not be reliable - in which case I will need to do something more drastic if I experience similar problems there. Edit: One more thing @jphughan - if I create new rescue media, I notice it still default highlights WinPE (presumably because I used this before). Would you still recommend changing this to the WinRE option?
