Having big problems imaging windows 10 to a larger disk

I mean, is there no setting in the GUI to make it default or only in the GUI when you are doing the restore?

 

Thank you, Frog.

 

Hadron,

If you select an Option in IFW (being used in Windows) and click Save Defaults then the option is written to ifw.ini and will be present the next time you use IFW.

If you select an Option in IFW (being used in TBWinRE) and click Save Defaults then the option won't be saved as IFW is running in RAM.

Once you have the "correct" ifw.ini your next created TBWinRE will have the "correct" options.

 

So, in Windows, I need to run through the manual Restore process to gain access to the settings in the GUI.
Otherwise just edit ifw.ini.

 

That's it.

 

So sadly I cannot confirm that this is the problem or the fix unless I buy the package.
There are several things that come to mind.

1) What about SSD > SSD ? that fails too with Win 10?
2) What about Windows 7 ? That always succeeds (although I haven't tried Terabyte software just the Samsung migrate and System Image backup"
3) If the driver is wrong (presumably at the restore stage, how is it possible to fix the problem by repairing the the boot files in the way I described #136.?

From their explanation it seems I could test one or two things.

1) Do a SSD > SSD image backup. Hopefully nvme is not a problem when used as the restore system so ..

a) I can fire up the 850 Windows 10 make an image (saved to the nvme) then I'd have to restore from the nvme side but from the above this should be ok as the back up wasn't made OF or FROM the SSD. Hopefully that would show whether this is a nvme > SSD problem or not.

b) I could make a backup of Windows 7 and test the restore but that is on the 860 which is larger than the destination hopefully I don't have to resize the partition. In this case it would just show that windows 7 via IFD or IFL or IFW is ok with with Windows 7 and unless I transfer the Win 7 to the nvme I won't be able to test the NVME > SSD side but th results of a) will determine if I really need to do that or not?

I have to say at this stage I am not totally convince on terabyte's explanation but it has to be tested in some way to confirm or eliminate it. Also I'd expect if true that more people would be complaining in general about imaging Windows 10 as it would be a very common problem.

And to be fair Terabyte may not have considered the full information. If they are say for instance (which makes sense) when imaging from IFD the nvme drivers aren't there, I'd understand but then you'd have to explain why:

IFW can't do it from windows which has the driver
Samsung Migrate .... same
Windows System image backup
etc

My money is on something that goes wrong in the boot sector and we don't need any injection of drivers to get the SSD or NVME to boot, we just need to repair bcd

 

Louiscar,

You shouldn't have a problem with SSD to SSD. You can store the image anywhere. Storing it on the NVMe should not matter. Go ahead...

Use these extra options...

Write Changed Sectors Only for all restores

Use these options for the Windows partition restore (not for the SRP) when restoring an image onto a different SSD
Update Boot Partition
Change GUID

I gather Win7 handles NVMe differently from Win10 so that might explain why Win7 works.

None of the TeraByte apps include a NVMe driver. (OSDTool either). The driver is in Windows and OSDTool just sets it up in the registry.

Check out this page from Dell on FAQ with NVMe drives. It's frightening but it shouldn't make you change to UEFI. I think OSDTool will work but you won't know until you have paid your money.

https://www.dell.com/support/articl...hy_does_my_NVMe_drive_not_work_with_Windows_7

Back in the WinXP days we used to see a lot of 7B BSOD and it was due to missing SATA/AHCI drivers. OSDTool fixed it but we had to provide the drivers as they weren't part of windows.

 

Thanks Brian ,

I have to take it all back
You know I've done so many tests and operations that I've confused myself over which combinations and variations I've done.

I've actually done the test 1) a) as per my post #156 which is to re-iterate - boot from the working 850 Win10 using IFW to make and image saved to NVME. Then boot from the NVME and do a restore via IFW. I did this twice and on the first occasion I removed the NVME before attempting a boot and on the the second I didn't remove it. Both were successful.

So it appears that Terabyte are correct.
I had also thought one thing about having 2 partitions is that one can install windows 10 and then just image the windows 10 partition and replace that. This may be a solution if forced to go to GPT.

I will read the link you point to now but I am now wary of the UEFI - I had it in mind to actually forego reviving this x99 system and go straight to the Ryzen current cpus but decided that things should move along a bit for various reasons and I'd wait. There will come a time when I will want to transfer my retail verison of Windows 10 system and getting it working on new hardware and I'll have the extra pain of probably having a UEFI bios level 3 with no CSM. Perhaps it's time to consider doing that now since I haven't really started this system in earnest .. not sure .

I still don't quite understand the logic here. As the image of Windows 10 was with a registry that contained the nvme driver I'm still at a loss to understand why windows doesn't pick it up in the same way as it would when booting the source copy. What removed it from the registry that stops the image from finding the nvme driver?

Anyway, It seems I have a solution for imaging windows 10 from nvme > ssd given either I repair the boot sectors or use OSD tools and now I understand where the problem lies I do feel much better for it.

 

When you installed Win10 on the SSD it installed AHCI drivers but not NVMe drivers because it didn't need them. When you restored an image of this system to the M.2 it didn't boot because the required drivers weren't installed. They were present but not installed.

 

But surely when windows boots normally it accesses the nvme ok but from a restored image it's still going through the same boot process. I'm having trouble seeing the difference between the 2 circumstances.

Also there's still something else that seems to be happening here. ie. that the boot sector appears to be damaged. If it's repaired via the method I describe it boots but then that's where I can see perhaps the driver issue happens because it goes to recovery first, then safe mode and then normal boot. Here is where at least I can see that Windows would fix drivers in safe mode.

Are drivers kept in the boot files?

 

The script looks for drivers in...

C:\Windows\System32\DriverStore\FileRepository

 

Moving Win 10 from one computer to another usually works but if it doesn't, use OSD Tool to "Remove all drivers". Then Win10 will boot.

 

So is it not a good idea to make sure this driver is present before doing the imaging?

OSD tools seems to be pretty useful in that case.

Searches for this issue often lead here: https://www.ubackup.com/windows-10/move-hard-drive-to-new-computer-windows-10.html
They've really done their SEO well methinks. I don't know how that works ie. if they make the image removing the drivers or it's done on the restore.

 

Louiscar,

This could be interesting. Win10 on one of your SSDs. An OS that you know won't boot if you copy it to your M.2
Install the Samsung nvme driver to this OS.
Now copy the OS to the M.2
Does it boot or not?

 

Went down the bookies and they gave me 70/30 against ... doing it now

 

Bookie is out of pocket.

I did the following using the Copy operation in IFW (only slightly concerning thing that may have scuppered it was IFW claimed handles used in destination drive which I ignored and got them released)

Installed Samsung nvme drivers
Starting from the 850 and copy to 970
Switched to boot from 970 (didn't take 850 out). Booted OK

From the 970 Copied to 850
Switched to boot from 850 (didn't take 970 out). Booted OK

Lastly just to make sure I removed the 970 to make sure the 850 will boot.

So it seems to work both ways and the nvme driver is the key to both.

Settings chosen were :

Update boot
Write standard MBR (where the global setting is Windows new MBR)
Change GUID

I don't know if I should do same tests with an image file rather than direct copy but I will probably at least do the same thing from 970 to the 860 1TB drive once I've made an image of Windows 7 that is currently on that.

As this thing started with 860, at least I think I should end there.
Then I've got a ton of notes to make from this thread.

 

Louiscar,

You are on top of this now.

 

I believe so and again thank you so much for your invaluable time and help in tracking this down.
This thread will hopefully help others if they have the same problem.