How to specify EXACT location for partition recovery?

Forgive the Bump, but I'm lost :(

I can't figure out how to safely make Windows10 to go where I want it.
I doubt I could again recover Windows 10 to the first, now empty, slot because Windows will not like it.

I'm thinking of something like this:
From Windows 7 (default boot) in msconfig remove Windows 10 line and reboot to make sure I have no option to boot 10.
Back in Windows 7 delete? format? windows 10 partition at the end.
Somehow stretch the M-data partition all the way to the end on the right so ATI won't see two unallocated spaces.
Now restore Windows 10 to where it always was.
Boot to windows 7 and add Windows 10 line?
Later, shrink? the M-data partion (how?) so that I can put Linux inside that extended area.

I'm not sure why that happened. From your picture, there should have been enough space for Windows 10 to fit in the 78.49 GB of Unallocated Space, since the restored Windows 10 partition was 78.48 GB. Did you separately specify the location of the System Reserved partition and the Windows 10 partition when you restored? If not, try the restore again but this time specify where each partition goes.

If you did specify the locations and got the result shown in your picture, there is another way to get your desired outcome. First, copy everything on the Local-M partition to temporary storage. Then use Windows disk management to delete the Local-M partition and the Windows 10 partition, leaving a large block of unallocated space (385.44 GB). Next, use TI to restore only the Windows 10 partition to the unallocated space.

When the recovery has succeeded, use disk management to shrink the Windows 10 partition to the size that you want. Next, create the Local-M partition in the remaining unallocated space, then restore its contents from your temporary storage. This should give you the layout that you want.

Mark, thanks for being here. You rescued me on XP ages ago :)

See my pics. Considering how often 2016 validations fail, I've started taking pictures of what I do.

7907 was as I was about to click the leftmost unallocated, and I did click it.

7910 is the result. Note that in the same session the image failed to restore back to the old position, but zapped Windows 10. Subsequent validation of the same image worked, and it restored, but to a wrong place.

I did save the logs to my data drive(M). They're unreadable, but might they help you see what happened?

If you don't mind, go ahead and post a log and we'll take a look.

I see in your screenshots that during the 10:51 PM failed attempt, TI is attempting to recover in "Sector by Sector" mode. Did you explicitly specify that mode? Or, did you back up in that mode?

If you did not, you may have disk errors that trigger that recovery mode. If that's the case, it might explain some of the validation errors. I would run chkdsk /r on the disk that your backup is stored on (is it F:?) to see if Windows can fix any file system errors and/or map out the bad or intermittently bad sectors.

Log attached.

Recovery is from Cnv-Grey1, F in boot envirenment, another letter in Windows.

Btw, when I do images I always include System_Drv, otherwise I won't boot.

Sector-by-sector always baffles me. It always does it. Don't know why. I will run chkdsk /r through Windows 7 I suppose, or do I  have to find Safe mode?

Also, when I relocate Win10 to where it always was, do I have to tell msconfig about it? I forgot how I did it when installed Win10 for the first time.

If there is any file system corruption then ATI defaults to sector by sector mode. You should run chkdsk /r on both the Windows 7 partition and on the drive you are storing backups on. You can run chkdsk /r on the backup drive from within Windows. You can start chkdsk /r on the Windows partition from within Windows, but it will ask you for permission to reboot to run the disk checks. Try this first before proceeding any further.

The /r switch on chkdsk will both check for file system errors and then scan and attempt to recover data from bad sectors. The latter operation will take a long time, especially if there really are bad sectors.

Thank you, Mark.

I will do chkdsk /r and nothing else. It'll all take forever, as you know. But I'll report the results. Since I can check Win10 from 7, I'll do it from command prompt. OK?

Yes, sounds good.

Chkdsk /R of the backup drive and windows 7 done from Windows 10 elevated cmd.
Chkdsk /R of Windows 10 done from elevated cmd on Windows 7. Curiously, it took the longest time.
See screenies.

The reason I used Windows 7 to check Win10 is because Win10 has a nasty feature of EA and reparse records. When I do chkdsk from booting, I never get a chance to see the end of the log because winiinit just cuts it off.
There is a MFT error in Win7. I don't understand that reparse pest, nor what/why the MFT error. I've seen the same MFT error after clean installation of Windows 10 in January.
Might that be the cause of bad validation or bad recovery or sector-by-sector?

I think so. And since your restore was done in sector by sector mode, the file system error was carried over from your source and is present in your backup.

If you still have the Windows 10 source that you created an image of, use chkdsk on it to fix the problem, then create another image. I'll bet that it restores properly in the partition that you target, and not in sector by sector mode. Or, since you've fixed the file system error on the current installation of Windows 10, you could create an image of it and then try again to restore it to your desired location on the disk.

Tomorrow I'll image current System_drv plus Windows 10 since it was fixed. I assume you speak of the MFT error.
Do I restore to the emty slot where I want it with Windows 10 existing in the wrong place? I doubt it. Two Win10 is unlikely to work.
Or do I follow the last two paragraphs in the third post you wrote above?

Now that you have the file system errors fixed, I'd try restoring it to the empty slot where you want it. But first, delete the existing Win 10 partition so that you end up with only one Win 10 partition on the disk.

Ok. Will do using new image, thanks.

Mark,
Windows didn't take too kindly to removal of 10. I'm stuck on a not functioning 7. Maybe got fixed as I'm writing this from XP box, not yet sure.

First I removed Windows10 in msconfig so it would be gone from boot options.
Restarted really fast, but then hit big trouble - I was able to login but nothing worked. Not even Start menu.
Ctl-alt-del took a long time to give me menu. I did Task Manager, but it too got stuck.
Ctl-alt-del again. This time I logged in as Administrator (THE Administrator, not user-admin).
That worked. Here I deleted Windows 10 volume.
Restarted. Logged me in. Welcome screen cycled for over 15 minutes (unheard of). But finally came to its senses.

Before I do anything else, i.e. recoveries, I thought I should report to you and likely have to take a good look at Windows 7 to assess the damage if any.
If you have any thoughts, please share.

That's not good. The only thing that I can think of that might cause slow speed is disk problems. Any time that I've had issues like you're describing, it's been because of bad sectors on the disk. When you're waiting for Windows to start up, is there disk activity during the long wait? If so, perhaps boot from a Windows repair CD or an installation DVD and run chkdsk /r on the Windows 7 partition from a command prompt.

No disk activity during crashes or long Welcome delay. Just slight infrequent blinks.
No NTFS errors in the event log.
I restarted twice now, both lightning fast.

I'm running chkdsk. Started in Windows7, selected both file and sector options. So far I see 2 EA and 90 reparse records processed, so should be able to catch the entire log.
I don't have any CDs or DVDs for repairs.  ATI is my lifeline :)
This laptop has a way to get into safe mode and other stuff when it boots. I haven't yet learned to use any of it.

I wonder if I should have deleted Win10 volume in the same session as deleting the boot line in msconfig instead of rebooting in between. Learning as I go along.
I may need to know how to do it correctly in case the next recovery from the fresh image goes to a wrong place again.

You might want to make a Windows Repair disk for future needs. It will allow you to boot the PC from the disk, run a command prompt window, do automatic boot repairs to the BCD, etc. To create a repair disk start Windows 7 and type "Repair" into the Start/Search box and choose "Create a System Repair Disk".

In your last reply you said that you "restarted twice, both lightning fast". Am I to assume that Windows 7 is now working properly?

Repair disk - I'll try. I think I did that once, it didn't boot.

Yes, Windows 7 is starting and running ok, except one or two things, and the event log showed a whole mess of Microsoft Security Essential unspecified errors, and many were during those long delays. I've used it for the past three or so years with no issues.
Anyway, Mark, take a break. I need to go through Windows 7 more.
So I'll be back when I restore Windows 10 to impose on your kindness again. Because whatever issues I now see/will see are Windows issues, not ATI.
Oh, chkdsk was ok, no MFT issues just as there were none on win7 yesterday.

Windows 7 continues to work fine. Issues were with MSE, fixed itself.

So I tried recovery again.

Going to the correct unallocated space didn't work. I aborted recovery.
I used the fresh image done after all those chkdsk fixes and before wiping out Windows 10.
ATI insists on putting Windows 10 to the 107gig unallocated. I tried both .2571 and 2581.
I rechecked that I picked the correct slot (78.49 gig), clicked Accept, and it presents me with 78.48 gig + free space after 28.94. That's 107g large unallocated.
I fiddled with the graph and the individual sizes, but had to give up.
Took several pictures, in case you need them.

Since that failed, I haven't yet checked if it will not do sector by sector after the MFT fixes.

Two theories here:

1. What is the used space on your imaged Windows 10 disk? Is it close to 78.49 GB?
2. The fact that you have a logical partition following the target restore location may be causing issues, although I can't imagine why.

At this point, if it were me, I would take the pragmatic approach and do the following:

1. Copy the contents of your Local-M disk to temporary storage.
2. Delete the Local-M partition and its logical partition container (two separate operations). You can do this in Windows 7 using Disk Manager, or you can do it with DD 12.
3. You should now have unallocated space on the disk of 310.56 GB, directly to the right of the Windows 7 partition.
4. Restore your saved Windows 10 image using ATI to the unallocated space, specifying the partition size that you want.
5. Test Windows 10. If it won't boot, you'll need to use something like EasyBCD to fix the BCD entry for Windows 10 (or, you can post a copy of your BCD here and I'll give you the commands to repair it. From Windows 7 enter an administrative command prompt and type bcdedit /enum all > C:\users\(your user account name goes here)\Desktop\bcd.txt which will put a text file on your desktop that you can attach to your reply).
6. Finally, re-create the Local-M logical partition and copy your files back.
 

Mark,
Used space in Win10 partition was a bit over 22gig. See first post.

I normally restore Win10+system_drv which starts the boot process.
Should I, or should I not now restore system_drv from an image created with Win10 in a wrong place?
Or if not be able to boot to Win10 do the easyBCD job in Windows 7 ? I have it, never used it.
Thanks a ton for the commands!

22 GB used space - it was in your picture. Forgot about that. There is more than enough room in the first block of unallocated space for your Windows 10 image to fit. So it's still a mystery why TI won't restore to that location.

You should restore just the Windows 10 partition. The existing contents of the System Reserved partition should be OK, except for the BCD entry referencing Windows 10 will point to the wrong place on the disk. True Image may be able to correct the BCD entry when you restore the Windows 10 partition or maybe not; it sometimes gets confused in multi-boot systems. But it's pretty easy to fix if it doesn't.

It's late. I'm afraid to do anything tonight.
Tomorrow maybe, Monday for sure.
Just wanted to acknowledge I saw your last help about not doing system_drv. Thank you.

When I woke up this morning, the answer came to me. Here is what I think TrueImage (TI) is doing. To understand this explanation, look at your disk layout picture that is attached to your very first post above.

When TI asks for a restore location, it lets you specify either a particular partition or unallocated space. You want to restore to the unallocated space of 78.49 GB that is located in-between the C: and M: partitions. But you also have 107.42 GB of unallocated space at the end of the disk (before the restoration of Windows 10 took place). When you specify to restore to unallocated space, there are two blocks of unallocated space and it looks like TI is choosing the largest block of unallocated space, which is at the end of the disk.

To get around this I think you can create a partition in the spot where you want TI to restore to. Then you can choose to restore to a partition location which is unambiguous.

So, from Windows 7 open Disk Management and create a new simple volume in the 78.49 GB of unallocated space. Choose the maximum available size, choose an arbitrary drive letter, and assign the label "Windows10_OS" when formatting. Then restore your saved Windows 10 image to this location. In the TI interface you will see the location listed by its label.

As for restoring the System Reserved partition, that will depend on its current contents. If it still contains the BCD with a Windows 10 entry from your last restore attempt, then there is no need to restore it again, but it wouldn't hurt to do so either. In any event, unless TI magically fixes the boot entry for Windows 10 upon restoration, you will need to do this manually in order to get Windows 10 to boot since you're restoring it to a different location on the disk.

Brilliant.
And when I woke up this morning I was worrying how will I maintain this state if Windows update trashes me and ATI zaps my Windows 10 again. No more worry.
Thank you. It worked.
Recovery - normal, no sector-by-sector. Took all of 4.5min.

I haven't selected Windows 10 at startup yet, because after EasyBCD added second entry and it's called "Microsoft Windows". Ditto in MSCONFIG, but does show K partition.
It used to be called Windows_10. Is it because I'm in Windows 7? Should I run 10 before changing this? If so how? I suspect is not important.
Just in case it needs fixing, I'm attaching the bcd text file you suggested earlier.

Super. Sorry that it took us that much time to get to this point.

It's easy enough to change the label from "Microsoft Windows" to "Windows 10". Boot to Windows 7 and start an administrative command prompt window. Enter the following:

bcdedit /set {6e94774b-af99-11e6-88a8-3c970ec27b1b} description "Windows 10"

The BCD object for booting Windows 10 is missing a few items (for autofailing to the Recovery Environment and for Resuming from Hibernation), plus it has a lot of orphaned entries that can be deleted. It's late here and I don't want to make any mistakes, so I'll get back to you in the morning with the commands needed to fix it. But it should boot as-is, so feel free to test.

OK - here we go. You have an extensive number of orphaned objects in your bcd that can be deleted. Additionally, there are a few things missing from the bcd that should be present. Here are the bcdedit commands needed to fix things up. It's best to use copy/paste to avoid errors in entering the long {guid} numbers.

Boot into Windows 7 and open an administrative command prompt window. First, make a backup copy of your current BCD to your Windows 7 desktop (or choose a different place to store the file by modifying the path in the command below):

bcdedit /export C:\Users\your_username\Desktop\bcd.bak

This copy can be imported later if you want to restore the bcd to the way it currently exists. Next, delete the orphaned entries:

bcdedit /delete {06924b02-b500-11e5-890e-9fadb3b79452}
bcdedit /delete {45a9579b-b583-11e5-b4af-f5b079350279}
bcdedit /delete {64973565-b2c0-11e5-be49-a5d60207ccad}
bcdedit /delete {8367deb6-27d9-11e3-9df5-9c4e36ce69b0}
bcdedit /delete {ac3fe285-8089-11e6-be98-ec4802900dfb}
bcdedit /delete {b872fd4f-bb20-11e5-831d-fcae3e8d9eb6}
bcdedit /delete {eb42cee4-bbba-11e5-b60e-b225ce378c65}
bcdedit /delete {7fb795c1-b582-11e5-b4af-f5b079350279}
bcdedit /delete {06924b03-b500-11e5-890e-9fadb3b79452}
bcdedit /delete {06924b04-b500-11e5-890e-9fadb3b79452}
bcdedit /delete {45a9579c-b583-11e5-b4af-f5b079350279}
bcdedit /delete {ramdiskoptions}

Next, fix the pointer to the resume loader in Windows Boot Manager (it currently points to a nonexistent location):

bcdedit /set {bootmgr} resumeobject {05b6ac8d-2354-11e3-88f6-3c970ec27b1b}

Fix the Windows 10 Boot Loader (EasyBCD creates a barebones set of entries that will boot, but it omits adding some of the recovery and resume from hibernation features that are present in a clean install of Windows):

bcdedit /set {6e94774b-af99-11e6-88a8-3c970ec27b1b} description "Windows 10"
bcdedit /set {6e94774b-af99-11e6-88a8-3c970ec27b1b} inherit {bootloadersettings}
bcdedit /set {6e94774b-af99-11e6-88a8-3c970ec27b1b} recoverysequence {8367deb0-27d9-11e3-9df5-9c4e36ce69b0}
bcdedit /set {6e94774b-af99-11e6-88a8-3c970ec27b1b} recoveryenabled yes
bcdedit /set {6e94774b-af99-11e6-88a8-3c970ec27b1b} resumeobject {06924b00-b500-11e5-890e-9fadb3b79452}
bcdedit /set {6e94774b-af99-11e6-88a8-3c970ec27b1b} nx OptIn

Finally, fix the Windows 10 Resume from Hibernation Loader:

bcdedit /set {06924b00-b500-11e5-890e-9fadb3b79452} device Partition=K:
bcdedit /set {06924b00-b500-11e5-890e-9fadb3b79452} filedevice Partition=K:
bcdedit /set {06924b00-b500-11e5-890e-9fadb3b79452} recoverysequence {8367deb0-27d9-11e3-9df5-9c4e36ce69b0}

When you finish, your bcd should look like the attached file. List it by typing:

bcdedit /enum all

You can test the added features by booting into Windows 10 and checking to see if the computer hibernates and resumes from hibernation properly, and by going into "Settings" > "Update and Security" > "Recovery" > "Advanced Startup" > "Restart Now" to see if you can enter the new Windows 10 graphical recovery environment.

Watch the word wrap on these two commands - they are all on one line

Mark, it doesn't like to delete {ramdiskoptions}. Can't be deleted until /f switch is specified on the command line. Should I ignore and keep going or midstream login as super-Administrator? I'm doing it now as me-admin in elevated cmd.

I guess {ramdiskoptions} doesn't want to be deleted since its a so-called "friendly name". Why don't you just leave it in the bcd. It won't hurt.

The files are almost identical. Due to that ramdisk thing I have at the end

Setup Ramdisk Options
---------------------
identifier              {ramdiskoptions}
description             Ramdisk options
ramdisksdidevice        boot
ramdisksdipath          \boot\boot.sdi

Do anything? I haven't gone into Windows10 yet.

Looks good. Give it a try now.

Looking good here. Huge THANKS :)
Mark, you really are a gem.
Windows 10 and 7 are in the boot menu, both named correctly.
Windows 10 runs well, as does 7.
Boot device is windows 7 still (black menu). It's always seemed better for me since 7 seems more stable and I'm not skilled to fix things.

- I can't test hibernation or hybrid hibernation because I've disabled it. Dual boot apparently does not like fastboot, and disabling hibernation is a solution which has worked for me for months.
- Not sure if I can safely test recovery in Security settings of Windows 10. This laptop was Windows 7, and I'm afraid that all that recovery might put me in a factory-delivered state.

Probably a good time to make a clean image now.

Is there a way to compare BCD, no extension, that is in the image of my system_drv? Just curious.

Yes, you could mount the image (right-click, choose Mount, or double-click on it to open it in Windows Explorer. Then look in the /boot folder on the system drive for a file named BCD, it's a hidden file. For convenience, copy it someplace easy to get to, like C:\. Then you can list the BCD contents by doing:

bcdedit /store C:\BCD /enum all

Or, to write to a text file on your desktop,

bcdedit /store C:\BCD /enum all > C:\users\your_username\Desktop\"bcd from image.txt"

When done, delete the file BCD that you copied to C:\

You should be able to enter Windows Recovery Environment and do something like open a command prompt just to see if it works. You would have to deliberately choose a Recovery option to restore the laptop; it won't happen automatically.

I did have an additional bit of advice for you about your partition layout. You have unallocated space at the end of your disk that is outside of the Extended Partition Container. Windows Disk Management will not be able to work with this so you will not be able to create additional logical partitions with Windows Disk Management unless you do the following:

1. Copy the contents of your Local-M partition to external storage (or create an image of it).
2. Use Disk Management to delete the M: partition.
3. Click on the remaining Extended Partition Container (the one with the green outline around it) and delete the container.
4. Click on the now-contiguous unallocated space and create a new partition. Since you have 3 primary partitions, Disk Management will automatically create a logical partition with an extended partition container that surrounds all of the unallocated space. Choose the size of the logical partition to be whatever you want (your old one was 203.13 GB).
5. Copy your data back to the M: partition.
6. You should now have the remaining unallocated space inside the Extended Partition container (green outline), so you will now be able to create additional logical partitions with Windows Disk Management.

Or, if you have other partitioning software (Acronis Disk Director 12, GParted, PartedMagic, etc.) they will not have the limitations that Windows Disk Management does, so you can create additional logical partitions without doing the above steps.

Glad to help; I enjoy a challenge.

By looking at BCDs, images of BCDs, and BCDzeros in the registry, I've learned few little scraps thanks to your annotated file and helps. Pretty slick stuff.
Questions about two places - see attached:
1 - In hibernation, which I don't use, are two differences of strange numbers - I don't have to know it, so explain only if very simple.
2 - I understand (pretend to) all on this screenshot except how does the computer's boot manager know that Windows 7 is the default? Nowhere in any of these outputs is default named.
Any idea where all the orphans you listed earlier came from?

I'll return to the unallocated at the end then when I get to it. Likely by Mint-Live gparted 'cause I think that's how I did it for adding Windows10. It used to be all one big extended. Not sure why it's not now. Have to check my notes :(

The entries that you have circled in the Resume from Hibernation BCD object were added by your laptop's manufacturer. Usually the "custom" entries are in the Windows Recovery Environment BCD object. When you boot to the recovery environment while pressing a certain key (defined by the manufacturer), you boot to their specialized "Return to Factory" recovery environment. If you don't press the special key you boot to the standard Windows Recovery Environment. I have no idea why this appears in your Resume from Hibernation BCD object. The other two "allowedinmemorysettings" and "bootmenupolicy" are new to Windows 10. I haven't found any documentation explaining exactly what they do.

In your second picture, in the Windows Boot Manager BCD object, the entry "displayorder" lists the installed operating systems in order. The first one in the list is the default one to boot. You can rearrange this list to change the default OS. Your list shows "friendly names" instead of {guids}. So in your first picture you were booted to Windows 7 when you listed the BCD contents, so the first OS in the list says "{current}", meaning it is the OS that you are currently booted to. The next picture lists the first entry (Windows 7) as {default}, meaning that it is the default OS to boot.

If these are ambiguous you can add the /v switch to bcdedit, bcdedit /enum all /v, which will cause the output to explicitly list everything by the long {guid} identifiers so you can tell exactly which OS is being referred to by finding its identifier in the output list.

The orphaned BCD entries usually result from failed installations of Windows, or failed attempts at automatic recovery, or sometimes from major Windows 10 updates, or from operating systems that were re-located on the disk and thus their starting sectors are now invalid.

Yes, Mint gparted does partition table entries for logical partitions in a different way, the way that most people (except Microsoft) do it. Windows Disk Management (and the command-line tool Diskpart) are very particular in how they operate and have more limitations than other editors. Either will work. My advice was only if you want to create more logical partitions using Windows Disk Management. If you create them with one of the Linux editors then you don't need to do anything.

Extended space all done in seconds by gparted in Live-Mint.
Next step will be to study about taming grub and windows boot from destroying each other.
It was simple on XP years ago, but with this booting system on System_drv and either windows could get funny especially if windows decides to repair something.
Anyway Mark, THANK YOU again. This was a long but interesting process. Current state attached.
 

Looking good!

Getting Linux and Windows to dual-boot on an MBR system is relatively straightforward. Until a few months ago I used Grub4DOS as a boot manager. It's a derivative of GRUB so the principle is the same. You will install GRUB to the MBR as your main boot manager. The menu file for GRUB lists the boot choices, so you would have an entry for each Windows OS that simply jumps to the relevent partition and an entry for Linux that Mint will set up for you. If I'm not mistaken, Mint uses GRUB2 which is a newer version of GRUB. I've not kept up with how GRUB2 differs from the older versions but I'm sure that someone on the Mint forums can help you.

A few months ago I switched everything over to UEFI boot, so the PC firmware handles booting to multiple OS versions now. UEFI eliminates the need for boot managers (finally!).