While imaging. I saw people complaining about CBT, so I ran "repair", and uninstalled that component, but sadly, this did not stop the BSODs when imaging.
I rolled back from Windows 1809 build as I experienced BSODs multiple times (not Macrium related). Build 1803 is at least stable and BSOD free. No issue with latest Macrium update, CBT enabled.
I will make it known that I did update another PC that is on Windows 10 1809 and have not had any BSod's yet. There has to be other factors than just that. The one that had one has RAID. I don't know if that figures in,to see if others that are have a problem are using RAID. I'm also using ESET Internet Security on the BSoD PC. I don't know if that matters and I'm not blaming it, but if there is something common... ---I submitted a ticket and offered a full dump if they want it. We'll see.
I was getting green screens in MRCBT.sys while trying to mount an image so i could copy a few files... Problem was NOT with that one. Posted in macrium forum, turned out it was the windows file wcifs.sys, an MS 'filter' driver for secure containerising, if you have an agreeable fltmc.exe in your build you can open an administrative command window and type: fltmc.exe unload wcifs then hit enter. it unloads till the next boot, if you don't want to reboot , type: fltmc.exe load wcifs you may need to use the full path & file name for wcifs.sys (It's in c:\windows\system32\drivers) My current insider build insists it can't find the file in either case. I took ownership of it, gave myself full privs, renamed the file extension to .xxx, reboot, mounted the .mrimg full backup, copied the files I was after, dismounted the image, renamed the file back to .sys, rebooted. ALL worked. I seem to recall if you can copy the wcifs.sys (first rename your current one to .old justincase) from an earlier insider where macrium worked & copy it over the non-working one, that may also do the job. Caveat emptor,
Did you restart after uninstalling it? Also, you need to run a Modify install to remove a component, not a repair install.
Green screen when mounting an image on that newer Insider builds is a known issue. That driver unload workaround was provided by Macrium a while ago (they say that there’s a bug in that Microsoft driver), although the release notes for the new 3954 release say that Macrium has worked around that issue so that the unload is no longer necessary.
Correct. I meant to say "Modify install," that's what I did. I also rebooted. I saw this issue on Win10 x64 1809 with Windows Defender, and also with Avast. No RAID setup or anything.
I'm not sure what to do at this point. I got a response from their support. They are asking me to run the program and open the support case form and submit error logs and backup definition files. The PC that still has this version has not crashed, and the one that did has been restored to a backup from last week. I can still offer them the dump from the laptop that crashed, but it's all I have at this time. This has already cost more time than it should have. I will make reasonable effort to help them identify, but I do not have all day to recreate this situation. Check for updates is now off. I will likely disable it on all 18 PCs and 2 servers if this is not resolved sooner than later.
If you don't have anything easily retrievable left over from the previous issue and don't have time to recreate problems, then I wouldn't worry about going out of your way for this. There are enough people reporting this issue that I suspect Macrium will get what they need from someone else and/or from working to recreate the issue internally. I would think carefully about disabling update checking, though. Note that it's only an automatic check; Reflect never automatically installs or even downloads available updates. And you never know when there might be some critical fix that you might not know about if you're not checking for updates. Ironically the best example of that situation also involved CBT. Macrium introduced a bug that caused any images created using CBT to be corrupt, and that bug existed in 3 production releases released over a roughly 3-week period before it was fixed. But of course, there were people who updated to an affected release and then didn't check for updates again for quite a while, so they went longer than that completely unaware that there was a massive problem in the version they were using. That incident is partly what led to the background automatic update check, which didn't exist at that time. And the option to send email notifications of available updates is mostly for servers where user logons are rare and therefore even a system tray notification isn't useful. Of course if you'll keep an eye on updates somewhere else, then no problem, but make sure you do.
You make some good points, I'm just tired of seeing the notification for an update that should be pulled at this point. I am well aware o the previous CBT issue, we were bitten by that too. These things are going to make it a hard sell to get the boss to upgrade this product when the next paid version comes out. I like the product but if there are any more issues in the near future I'm not willing to bet my job on it.
People say that version 6 is pretty solid, if you can get your hands on the latest build of it. But there is no way to know how long it will continue to be stable on Windows 10 with updates.
Version 6 was great. It's why we bought 7. I guess we'll see. Hopefully they'll get this straightened out.
Latest V6 build is V6.3.1855. Reflect V6 will activate on a V7 key, although the V6 download agent will download a V7 installer if you supply a V7 key. However, if you can find an actual V6 installer of the correct edition for your key from a third-party download site and verify that the EXE's digital signature is intact (per this KB article) you could use that. The concern about future Windows 10 releases is valid, though. As of this writing, there's a known issue with V6 and earlier V7 releases running on the latest Insider builds that prevents imaging from occurring. Macrium's KB article about it here says that it stems from a Microsoft bug that they anticipate will be fixed before the next Win10 release goes to production, and in the meantime they developed a hotfix workaround for 7.1 and have since included that in 7.2, but nothing has been backported to V6.
In that case I'd recommend reaching out to Macrium, either via heldpesk ticket or support email address, since resolving this was specifically called out in the release notes of 7.1.3954, quoted below. If you have minidump files you can provide them, so much the better. From Macrium's release notes page: What's New v7.2.3954 - 17th December 2018 Compatibility with Windows 10 Insider Preview 1809 (18290/8 ) System Image files can now be mounted in the latest Windows 10 Insider Preview release. We've worked around the Windows Container Isolation File System (wcifs) bug that caused a GSoD with earlier releases of Reflect.
I grabbed the sale too thinking that enough time had passed to render v7 "safe", but when I upgraded my Win8.1x64 system, I ran into massive conflicts with blank explorer windows and crashing Windows Search service. Installing a plain vanilla version went no better. Only if I disabled Windows Search service would my machine boot safely. That didn't work for me, so I'm back to v6. Recently I did find a small anomaly wrt Windows Search, but I can't imagine how MR got involved with that. My dism and sfc checks all passed, and Event Viewer is squeaky clean. Now this BSOD mess has shaken my confidence a bit. So waiting and watching...
proud to be a user of MR (free) also because it has always served me good but i admit that these episodes are shaking me too...
According to someone on the Macrium forums, a patch to 3957 exists and has solved the BSoD issue for that person, who received it as part of a support ticket. So I would expect it to become publicly available soon as long as no new issues are discovered.
As someone in the Macrium forums pointed out, and I thought about it myself, I m betting this has something to do with external drives. The laptop I am getting BSODs with happened when I had my external USB drive attached that I was backup to. The PC that is having no issues backs up to a network share and has no external drives attached.
Not sure about that, because on both my laptops I had no issues, and external portable USB drives attached.
Well it may not be something that affects every situation where an external drive is present, but perhaps the more illuminating data point would be whether anybody is currently experiencing BSoDs WITHOUT having an external drive attached, or can cure their BSoDs by disconnecting their external drive.
Agreed. It may not be that everyone with an external drive has a crash, but everyone that has a crash uses an external drive. If we could get more responses on whether or not that is the case maybe that will narrow it down.
Bug Fixes v7.2.3957 - 21st December 2018 Macrium Changed Block Tracker (MRCBT) Some customers have experienced a Windows system exception causing a BSoD if the CBT feature was installed with v7.2.3954. This has been resolved.
