OS: WIndows 10 64-bit, Macrium Reflect v.8

Hello,

The question in the subject line is self-explanatory, but I do need to define why it is being asked:

I have a multiple-drives Windows 10 PC, the OS currently still on a SATA 6/III Samsung SSD.  I have also always had what I call my "emergency drive", a physical duplicate of the OS drive that is offline until I have some OS problem and need to use it to do a system restore.

This is far faster than restoring off my Macrium Rescue USB (my OS has thousands of small audio and other media creation content files or samples, so backups and restore take longer than a basic consumer OS).  And in this situation, I've run into a snag:

I'm upgrading my SATA6/III OS drive from a 256 Gb to a 1 TB NVMe M.4.  For starters I did a restore on its capacity duplicate (the emergency drive), a 1 TB SATA6/III - which is what I am using as I write this.  Restore was as usual, flawless.

Three attempts to restore the exact same backup to the NVMe  resulted in not being able to boot ("Inaccessible boot device").  Even with all other drives disconnected.

But from what I've read -- and unless the 1 TB NVMe M.4 is possibly defective, which it may or may not be -- I'd have to restore off of the USB Rescue so as to be able to load the Windows NVMe driver as per this instruction on using Redeploy.

I talked to Samsung and they suggested I return the NVMe for a replacement.  I'll be doing that but I still will have to deal with this issue of Redeploy once I get the replacement.

So back to the subject line query:

Does my duplicate of Reflect 8 on my usually offline emergency drive have a built-in Rescue and Redeploy option, or is that only available on the Rescue Media on a USB or other such device?

It would save time if the answer were that it is available in the full on-PC Reflect, but I can't find anything like that.  If it is available, where to I look?

Thank you for your help.

P.S.:  While I may still return the drive, I did use the USB Rescue Media and the Redeploy worked (the NVMe drive finally booted).  The restore was quick too, but I'd still welcome a reply on my OP.

ReDeploy (and Fix Boot Problems) are not available to run in Reflect while running under full Windows. They are only available in the Rescue Media environment.  I understand your use case and thus your reason for wanting the former, but to my knowledge that isn't possible.  And even if it were, you would essentially have to run ReDeploy after every single clone operation, since the modifications that ReDeploy made to the clone target would be overwritten the next time you cloned your source to your target.  That would probably get old fast, and since not all ReDeploy scenarios are purely unattended, i.e. sometimes you need to manually supply drivers and/or make certain decisions, it wouldn't necessarily be feasible to have a post-clone automated ReDeploy option anyway.

So if your scenario involves cloning between two different types of storage devices such that ReDeploy would be required to make the clone target usable, then you should make sure you've always got Rescue Media handy.  And that's a good practice anyway, fyi.

And lastly, I definitely wouldn't jump straight to wanting a replacement SSD on the basis of seeing a BSOD when trying to boot a Windows environment that you cloned/restored from elsewhere.  First, the fact that it was possible to clone/restore onto the SSD already suggests that it's working properly, and second, cloning/restoring a "foreign" Windows environment is already a major variable.  So even if the fact that the SSD operated properly during the clone/restore operation isn't assurance enough, the next test would be to wipe the SSD and then try performing a clean install of Windows using regular Windows installation media.  If that worked properly, then that would be yet another indication that your BSOD does not signify a hardware issue with the SSD, but rather something about the cloned/restored environment's ability to operate on new hardware.  The "Inaccessible Boot Device" BSOD in particular almost always occurs when Windows doesn't have or isn't configured to load the appropriate storage driver for the device where the Windows folder is located.  SATA drives and NVMe drives use different drivers, unless you have a RAID or similar type of storage controller involved (e.g. Intel Rapid Storage), in which case Windows would always load the storage controller driver since the controller would be abstracting the actual interface of the physical storage device from the OS.  But if you ever switch from a RAID to non-RAID setup or vice versa, you can end up with the exact same BSOD for the exact same reason.  This is all because Windows is not smart or dynamic about loading certain types of drivers.  Essentially, when Windows is first installed, one reason the first boot takes so long is that Windows actually enumerates all of the hardware on the system to figure out what's there and therefore what drivers should be loaded.  But that takes a long time, so in order to boot faster going forward, Windows sets itself up to assume that certain boot-critical hardware will always be there and skips that full hardware enumeration.  And in the overwhelming majority of boot events, that assumption will be valid.  But if you change one of those boot-critical devices such that different drivers are required, Windows does not simply adapt accordingly, and thus you end up with a BSOD.   ReDeploy is therefore designed to make the necessary alterations to an offline Windows environment to allow it to load the correct set of drivers for the current hardware.

+x

 

jphughan - 20 September 2022 2:01 AM

ReDeploy (and Fix Boot Problems) are not available to run in Reflect while running under full Windows. They are only available in the Rescue Media environment.  I understand your use case and thus your reason for wanting the former, but to my knowledge that isn't possible.  And even if it were, you would essentially have to run ReDeploy after every single clone operation, since the modifications that ReDeploy made to the clone target would be overwritten the next time you cloned your source to your target.  That would probably get old fast, and since not all ReDeploy scenarios are purely unattended, i.e. sometimes you need to manually supply drivers and/or make certain decisions, it wouldn't necessarily be feasible to have a post-clone automated ReDeploy option anyway.

So if your scenario involves cloning between two different types of storage devices such that ReDeploy would be required to make the clone target usable, then you should make sure you've always got Rescue Media handy.  And that's a good practice anyway, fyi.

And lastly, I definitely wouldn't jump straight to wanting a replacement SSD on the basis of seeing a BSOD when trying to boot a Windows environment that you cloned/restored from elsewhere.  First, the fact that it was possible to clone/restore onto the SSD already suggests that it's working properly, and second, cloning/restoring a "foreign" Windows environment is already a major variable.  So even if the fact that the SSD operated properly during the clone/restore operation isn't assurance enough, the next test would be to wipe the SSD and then try performing a clean install of Windows using regular Windows installation media.  If that worked properly, then that would be yet another indication that your BSOD does not signify a hardware issue with the SSD, but rather something about the cloned/restored environment's ability to operate on new hardware.  The "Inaccessible Boot Device" BSOD in particular almost always occurs when Windows doesn't have or isn't configured to load the appropriate storage driver for the device where the Windows folder is located.  SATA drives and NVMe drives use different drivers, unless you have a RAID or similar type of storage controller involved (e.g. Intel Rapid Storage), in which case Windows would always load the storage controller driver since the controller would be abstracting the actual interface of the physical storage device from the OS.  But if you ever switch from a RAID to non-RAID setup or vice versa, you can end up with the exact same BSOD for the exact same reason.  This is all because Windows is not smart or dynamic about loading certain types of drivers.  Essentially, when Windows is first installed, one reason the first boot takes so long is that Windows actually enumerates all of the hardware on the system to figure out what's there and therefore what drivers should be loaded.  But that takes a long time, so in order to boot faster going forward, Windows sets itself up to assume that certain boot-critical hardware will always be there and skips that full hardware enumeration.  And in the overwhelming majority of boot events, that assumption will be valid.  But if you change one of those boot-critical devices such that different drivers are required, Windows does not simply adapt accordingly, and thus you end up with a BSOD.   ReDeploy is therefore designed to make the necessary alterations to an offline Windows environment to allow it to load the correct set of drivers for the current hardware.

OK, thanks for your detailed response. 

Since I am currently replying to this on my new NVMe that booted successfully after doing the restore and Redeploy from the USB, will the backup of this OS-on-NVMe scheduled for about an hour (I do full backups once every day) from now work from now on when restored back on to the NVMe?

Meaning that the correct NVMe driver/s selected during the Redeploy will from now on be integral to every backup from here on out.

Correct or incorrect?  My guess is the former, but I need confirmation.
Thanks.

Happy to help. If your Windows environment is now working properly, then yes restoring any backups made under that condition back onto the same NVMe SSD will work without ReDeploy. But if you have the Samsung NVMe driver installed, then be aware thar restoring onto OTHER types of NVMe SSDs may present a problem until you use ReDeploy. That may even include other models of Samsung SSDs, since if my memory of another thread here serves me, someone found that Samsung’s NVMe driver is actually a package of drivers with one for each SSD model.

If on the other hand you’re using the default Microsoft NVMe driver built into Windows, then you should be fine restoring even to other types of NVMe SSDs.

+x

 

jphughan - 20 September 2022 3:06 AM

Happy to help. If your Windows environment is now working properly, then yes restoring any backups made under that condition back onto the same NVMe SSD will work without ReDeploy. But if you have the Samsung NVMe driver installed, then be aware thar restoring onto OTHER types of NVMe SSDs may present a problem until you use ReDeploy. That may even include other models of Samsung SSDs, since if my memory of another thread here serves me, someone found that Samsung’s NVMe driver is actually a package of drivers with one for each SSD model.If on the other hand you’re using the default Microsoft NVMe driver built into Windows, then you should be fine restoring even to other types of NVMe SSDs.

Thanks for the confirmation.  I have no plans to get any other NVMe for there is only room for one on my current MSI mobo. Increasing read/write speeds on my OS for now is good enough.