SOLVED: Dual-Boot Win7/Win10 Resurrected with Creators Update Build 1703

[BonzaiDuck]

Some members must have seen my posts to various thread in recent currency about Windows Update Creators Build 1703.

If I attempt to run the download build in my current 1607 version, it led to all sorts of difficulties with making my dual-boot menu work correctly. Another member also had similar problems, suggesting that I unhinge all drives except the dual-boot-system-OS disk (960 Pro).

Since I have a good backup of this current dual-boot configuration with Macrium, I can always restore it.

I was hoping that I could follow a set of directions posted on Win 7 and Win 10 forums which allows an orderly removal of one OS while leaving the other bootable and intact. The idea being that -- given the 7-first, 10-second install sequence -- I should remove Win 7 after copying the MBR or BCD information to the proper Windows 10 boot volume.

However, it looks as though bootmgr is shown as a hidden file on that disk volume already. But I thought to install EasyBCD so I could scout around and explore before moving forward with anything.

Now I find that EasyBCD installed under either Win 7 or Win 10 throws up an error screen with text of the drives and their identifiers. I cannot even scroll that screen, and the only way to terminate it is the "End Task" option for Applications in Task Manager. And I've tried running as administrator.

This is quite astounding, because right now -- except for Windows (10) Update and the 1703 build I can't get and can't successfully install yet to save my existing 1607 configuration -- the restoration from my Macrium backup is working fine -- totally stable, totally reliable for hibernation/sleep and restarting to the OS selection menu. Both OSes load without any mishap.

The EasyBCD error screen says "error unable to open BCD registry" or something very similar to that phrasing.

I'm considering a clean install of Win10. I was hoping to save the Win 7 installation, which exhibits no problem and updates just fine. I'd want to inventory everything set up under 7, make sure I have all the drivers currently installed in Win 10.

But, barring this problem with EasyBCD, and maybe there's a fixable reason for that -- I'm wondering if I can simply "update" the 1607 build with an optical or USB install disc for the 1703 build.

Is that possible? Even if it fails, I can then move on to a clean install. And from what I read here, I can make an ISO and optical/USB installation media for the 1703 Build? Is that not true? Any "directions" or pointers, links and so forth -- would be vastly appreciated.

Somebody in another thread used the term "FUBAR" per my dual-boot configuration. It shouldn't be, but consider: First I went through hell installing Win 7 on a Z170 chipset and an MBR SSD partition. Then, thinking it would make a difference, I converted the drive from MBR to GPT with EaseUS Partition Master. Then, I installed Win 10 with the "accessibility" option we had -- on a second partition-volume of the same SATA SSD. Then I cloned the entire SATA SSD to NVMe 960 Pro.

And the dual-boot volumes, sys-reserved and EFI etc. have all been restored to the 960 Pro about two or three times.

I think it's time I cut loose of this configuration, and just install Windows 10. I'm assuming I can do that from installation media made specifically to install Build 1703?

 

[Iron Woode]

I heard problems can be caused by enabling 'fast boot' in 10. try disabling it and see if your problems go away.

On another note, I dual boot the hard way by changing the boot drive in the BIOS. This is clumsy but effective.

 

[deustroop]

The media creation tool is uptodate according to this
https://blogs.windows.com/windowsex...ndows-10-creators-update/#voHuL5YeTAaTtpjO.97

Keep a copy of all apps and drivers in a separate location to facilitate reinstalling them.

 

[JackMDS]

To avoid troubles Win 10 has to installed first (so it is in control of the Boot)

EZBCD should be installed only on Win 10. Other OS' should be in second, third etc, partitions.

Then, in-place upgrade in Win 10 has to be performed from USB or DVD with Win 10 install on it.

I did few upgrades using Win 10 Pro and Home with Win 7 Ulti and Premium.

All working very well.

 

[RLGL]

Have you tried https://neosmart.net/EasyRE/ ?
Crazy The install procedure for multiple OS is backward from what it used to be.

 

[BonzaiDuck]

The media creation tool is uptodate according to this
https://blogs.windows.com/windowsex...ndows-10-creators-update/#voHuL5YeTAaTtpjO.97

Keep a copy of all apps and drivers in a separate location to facilitate reinstalling them.

Yep. It's just part of several chores culminating in maybe a day or two's time to execute all the reinstallations, reboot, clean the registry, etc. in repetitive cycles. I printed out my "Programs and Features" list for later annotation. I'll want to sort the list so I can follow the installation in a way more intelligent than the alphabetic order.

I also downloaded the latest Belarc Advisor and ran it to generate the system descriptions -- including the list of software product-ID or activation keys.

To avoid troubles Win 10 has to installed first (so it is in control of the Boot)

EZBCD should be installed only on Win 10. Other OS' should be in second, third etc, partitions.

Then, in-place upgrade in Win 10 has to be performed from USB or DVD with Win 10 install on it.

I did few upgrades using Win 10 Pro and Home with Win 7 Ulti and Premium.

All working very well.

I took the last day or so to evaluate what had happened and where I am.

I have an hypothesis about (a) why EasyBCD generates the drive info list in an error window, and (b) why my installation leaves me with a flakey native Windows dual-boot menu that makes it impossible to hibernate the computer without mishap -- as just one example.

The PrimoCache SSD-cache. To create it, one has to use Computer-Management-Disk-Management to create a simple volume on "some" SSD. This volume is then converted by Primo and the file system and disk organization are seen by Windows as "Unknown."

So I suspect the drive enumeration and volume access throws the error. I have yet to test it, because I uninstalled EasyBCD. I'll need to reinstall -- which takes about 20 seconds.

But on the positive side, right now -- having restored from the April 14 Macrium Image -- the Windows 7 boot-sequence after normal menu selection is perfect and tip-top -- including the Windows Update function and the operation of my "tweaks" and add-ons -- like Primo.

Further, Windows 10 behaves perfectly, good event-logs like Windows 7, after selecting it in the boot-menu. The only shortcoming as Windows UPdate, which is hung up on the Build 1703 Security UPX update or whatever it's called -- I can find the KB number . . . KB4013214. It must be installed before the 1703 build can be installed through Windows Update.

At the moment, the Win Update screen shows a progress bar and 0% for this update, and the description of the update and its progress bar "jump" ever couple seconds to show they're being refreshed.

Here's where it gets interesting. A tech article -- I can hunt for it later -- from what looks like a reliable IT blog site was just posted around the 11th -- a significant date for this general topic. Regurgitating information from MS, they noted that KB4013214 might not be available for certain groups of users right away, that there were bugs and so on. Thus, those people couldn't get the 1703 build right away.

But there was a path I had previously followed that gave me a working 1703 install but borked PaperPort and maybe another program -- which I think would be fine if uninstalled and then reinstalled. This result included the flakey boot menu: first it would go directly to Win 7, then restarting from the Win 7 login screen brought up the boot menu so that selection of Win10 proceeded properly. If you restarted again, it would repeat the cycle -- Win 7, and when rebooted -- the menu.

So -- except for the mention by JackMDS about the ordering of boot-disk volumes -- I have a perfectly operational dual-boot configuration, but with Windows 10 unable to proceed with an update to KB4013214. This update is cited in a tech article as an obstacle that will eventually be surmounted. In the meantime, I can continue to test any other hypotheses such as the one at the beginning of my tome here.

And since I had the 1703 build working (even with the boot-menu defect), I'll also say it was a day or two before I noticed that particular problem -- there may well be a path toward saving my carefully-evolved Win 10 configuration and software installs without starting from scratch.

In the meantime, I'm going to prepare for starting from scratch.

As I continue with that set of tasks, can anyone confirm a reliable procedure for reorganizing those partitions/volumes on the dual-boot-system disk so the result is still a reliable operation of either OS through the boot-menu? Mini-Tool, Macrium and probably EaseUS all offer that option. The question is: which software gives you back a perfectly-operational dual-boot behavior?

 

[deustroop]

But on the positive side, right now -- having restored from the April 14 Macrium Image -- the Windows 7 boot-sequence after normal menu selection is perfect and tip-top -- including the Windows Update function and the operation of my "tweaks" and add-ons -- like Primo.

Further, Windows 10 behaves perfectly, good event-logs like Windows 7, after selecting it in the boot-menu. The only shortcoming as Windows UPdate, which is hung up on the Build 1703 Security UPX update or whatever it's called -- I can find the KB number . . . KB4013214. It must be installed before the 1703 build can be installed through Windows Update.

At the moment, the Win Update screen shows a progress bar and 0% for this update, and the description of the update and its progress bar "jump" ever couple seconds to show they're being refreshed.



So -- except for the mention by JackMDS about the ordering of boot-disk volumes -- I have a perfectly operational dual-boot configuration, but with Windows 10 unable to proceed with an update to KB4013214. This update is cited in a tech article as an obstacle that will eventually be surmounted. In the meantime, I can continue to test any other hypotheses such as the one at the beginning of my tome here.

And since I had the 1703 build working (even with the boot-menu defect), I'll also say it was a day or two before I noticed that particular problem -- there may well be a path toward saving my carefully-evolved Win 10 configuration and software installs without starting from scratch.

In the meantime, I'm going to prepare for starting from scratch.

As I continue with that set of tasks, can anyone confirm a reliable procedure for reorganizing those partitions/volumes on the dual-boot-system disk so the result is still a reliable operation of either OS through the boot-menu? Mini-Tool, Macrium and probably EaseUS all offer that option. The question is: which software gives you back a perfectly-operational dual-boot behavior?

This question doesn't make any sense. You say you have a single working disk with the 2 OSs. So what does your question mean ?

" Gives you back " ? From what ?

You are preparing for the worst and hoping for the best . The best will not happen until you sort out why the privacy questions KB4013214 will not install. There is likely an error log to tell you the answer.

Try installing CU using the update assistant. https://www.microsoft.com/en-us/software-download/windows10
That procedure may throw up the error preventing the install.

( Why do you not use two disks, one for each OS ? Install a second Samson with the cache arrangement on a riser PCIe adapter?)

 

[BonzaiDuck]

This question doesn't make any sense. You say you have a single working disk with the 2 OSs. So what does your question mean ?

" Gives you back " ? From what ?

You are preparing for the worst and hoping for the best . The best will not happen until you sort out why the privacy questions KB4013214 will not install. There is likely an error log to tell you the answer.

Try installing CU using the update assistant. https://www.microsoft.com/en-us/software-download/windows10
That procedure may throw up the error preventing the install.

( Why do you not use two disks, one for each OS ? Install a second Samson with the cache arrangement on a riser PCIe adapter?)

At least one forum member in particular -- CorkyG -- suggested the same thing about using two different physical drives. Perhaps, someone might use those two different physical disks in hot-swap bays, and if data, programs and files are separated either in a way that they are exclusive to either OS, or shared between them to avoid duplication and inconsistencies, that would certainly work. I ran into one problem with the caching program which suggests that an SSD cache for each OS would be better created on separate devices, or it would be best to use that feature in only a single OS.

With other plans for my hot-swap bays and some other thoughts about it, I just chose to put both OSes on the same physical disk. When I initially upgraded my laptop, I only had one disk, so both OSes reside on it. Without any clear picture of a future in which I would simply delete Windows 7, start from scratch with Win 10 or any option remaining that I could think of -- the dual-boot OS started out on an SATA SSD, and it was successfully cloned to NVMe. If it was working fine since January that way, I didn't anticipate trouble with a new "build" update. There was never a problem with WU in Windows 10 until KB4013214. But others have problems with KB4013214:

Dated 4-12-17 -- article at Softpedia

My system is up-to-date through 11 April. And when I initially encountered this problem, I found the Creator's Update link that allowed me to install it without using Windows Update. This is something this forum and threads about CU show has been done by several here.

And so I'll repeat what I was saying. There is as very good chance that the boot-menu problems were a result of too many disks and one non-standard volume on the boot-system disk that I might otherwise have easily deactivated. The installation went smoothly. Maybe one software program threw errors described on its official web-site as related to Win 10 updates in the past, and the solution would be to reinstall it with Administrator rights after uninstalling it and cleaning up leftovers and the registry. It might require setting Compatibility within Win 10. That's just another problem indicated in the linked article and noted elsewhere. I didn't see it as some cataclysmic problem: it's a software maintenance issue with a program that is at least seven years old in its latest version.

But the "skinny on the street" like the linked article, some number of users have trouble with KB4013214 -- and some here who've posted in this thread.

If that's not just a problem indicative of something buggy in my system -- and it isn't -- and if I had an otherwise successful install but for the boot-menu issue -- then I can either wait for MS to resolve it or attempt another installation circumventing WU that leaves the boot-menu functioning properly. I could certainly CHECK any log-files to see what causes it, but I'm not the only person stalled at KB4013214.

I swear -- with my prolix posts about this here and elsewhere -- the costs in time might lead me to simply download the CU and install it from scratch without Win 7. But with everything but the download of KB4013214 working perfectly, I think I can still save the entire enchilada, and there shouldn't be any hurry about it.

"Sunk cost" issue with that. There were all sorts of post-installation glitches with Windows 10 discovered and discussed on other forums -- things that required registry tweaks like security settings on particular components and programs -- DCOM errors, for instance. I took a few days to do the reading with hopes that my fixes would be accurate and avoid messing things up, and so all of that has been resolved.

For a clean CU install, it's lucky I kept notes on that stuff. I think there's a good chance I can still "upgrade" to CU with the single physical drive dual-boot arrangement. I could take my time over a month or so. If there's no light at the end of that tunnel, I'll be all set to completely install and restore from scratch.

 

[deustroop]

Apparently you want to take a second shot at updating Windows 10 by installing CU without using Windows Update so you can circumvent the drama of KB4013214 which your Windows 10 unfortunately will not process. My friend, you are taking the long way around. I think using two disks is best and that if you remember to take the 7 disk off line prior to the install all this shit would go away.

 

[BonzaiDuck]

Apparently you want to take a second shot at updating Windows 10 by installing CU without using Windows Update so you can circumvent the drama of KB4013214 which your Windows 10 unfortunately will not process. My friend, you are taking the long way around. I think using two disks is best and that if you remember to take the 7 disk off line prior to the install all this shit would go away.

Yes -- although my memory isn't so good to be sure that you mean "take the 7 disk offline" or "take the 7 disk-volume" offline. If I can't do the latter, then putting both OSes on a single physical disk sailed me up shit-creek. But I don't think that's the case. I think there were forum/thread respondents on this KB4013214 issue who were using a dual-boot configuration or were intimately familiar with it. And if the Windows (own) boot-menu works properly, this should all be accommodated through whichever upgrade path I choose -- Windows Update or the MS link for a CU ISO or just the link that does the update without going through "Windows Update." During the first pass at an install process, it did not mismanage that matter of the boot menu. When it restarted, it would continue working with the disks and OS where it was being installed.

But there are new developments. I followed through with one poster's suggestion about getting info from the Windows Update Logs.

Not too tricky, but tedious. One has to use Powershell to process the "EFL" update log files into a single Notepad-accessible file, and don't let me go into the details about what it's called but it turns up in a "Temp" folder. So I got through all that.

Now. I have four (4) disks installed on this system besides the ODD. I have the NVMe 960-Pro. I have a Seagate Barracuda. I have a Samsung-Seagate (or Seagate-Samsung?) and an HGST. The HGST saves only media captures and contains certain local business files shared between the OSes: Quicken, etc. There are no special considerations for that disk, and it has no pagefile. It has no cache. The Sammy-Seagate is a 2TB drive used only for Macrium scheduled backup. It is my "life-saver." No pagefile, no caching. The NVMe contains the Win7/Win10 boot volumes and stubs, and the "Unknown [format]" volume for caching the Barracuda has been unhinged and deleted.

The log files perpetually show either of two GUIDs in error-message lines showing "No format information found". But with Mini Tool, I can look at the properties of each drive that it sees, and none of the GUIDs matches those shown in the logs -- NONE!

Now I look at Device Manager and I change the "View" to "show all hidden devices." There had been a Crucial MX100 drive previously connected. Before the cloning to NVMe, the OSes had resided on an ADATA SP-550. Then I had added a 960 EVO to the system before finally replacing it with a Pro. And I had discovered that the EVO still appeared as a hidden drive in DM, so I deleted it (maybe I even deleted the ADATA, but that was a couple or three months ago). Finally, there had been another Seagate-Samsung in the hotswap bay for Macrium backup; I had replaced it with the current one, before becoming more comfortable and familiar with Macrium full-diff-incremental backup files and the scheduling.

there is an entry of "hidden" drives for the Crucial MX100, and a hidden entry for a second Seagate-Samsung of the same model as the one that is not "hidden."

I know my prolix answers or posts in this thread are annoying, but maybe this will be of some help to others -- who can say?

So I'm going to think about this some more, and then I'm either going to make some tweaks so that strange GUIDs disappear from the system and KB4013214 installs within Win Update, or I get a successful installation (with fully-functional and reliable dual-boot menu) the way I had done it once already.

This all goes back to an illustrious member -- possibly posting here -- who noted that "extra drives cause trouble" (my paraphrase.) thanks again for that.

In the meantime, you can turn off the Windows Update service for Win 10 in the advanced "services" window, probably for the particular session you're in.

There is hope!

 

[BonzaiDuck]

UPDATE: [I realize I nit-pick my problems to death and that I'm not the focus of this post by all rights. But I think being cool about this is leading to "the payoff."]

So I took all the measures I mentioned to eliminate the Windows Update logfile errors I'd exposed and mentioned in my previous post. Rebooted. Now Windows Update is running again, and -- AND! -- it shows:

"Your device is up to date. Last checked: Today, ‏‎4:03 PM"

"Good news! The Windows 10 Creators Update is on its way. Want to be one of the first to get it?"

No more progress bar stuck on 0%.

So should I follow the link to Win 10 Creators Update now? Or just wait? Because -- now -- I have two OSes in dual-boot working perfectly again to include Windows 10 Windows Update.

Progress. I think I'll attend to managing my backup files and start a new set of Full-Differential-Incremental Macrium backups.

We'll worry about Build 1703 to give it special attention, but with no hurry now.

 

[BonzaiDuck]

I decided to add this latest post and change the name of my thread to "SOLVED: . . . " as an advisory over BCD and boot-problems or quirky Boot-menu behavior after updated a Win10 Build 1607 to Win10 Build 1703 in dual-boot with Win 7.

Someone might find it useful or interesting in troubleshooting their own Build 1703 problem, or generally when problems develop with dual-boot Win 7 and Win 10.

The prevailing wisdom about setting up a dual-boot system is contrary to what one would expect who might pursue a successive approach of installing the later OS so that it is an additional volume following after the older OS on the same physical boot drive. Some of our "old hands" and veterans suggest that it is better to install the newer OS first on the disk, and install the older OS second. But with the proper preparation, backup and rescue tools, I was able to set things straight without starting over or deleting even one of the two OSes.

These were the symptoms. Windows Update under Windows 10 began throwing a new log file every 5 seconds or so, deleting the oldest after a couple dozen had been written to disk. It did not hog clock cycles, but it wasn't updating. This behavior apparently developed after the offer of the Build 1703 had appeared in Windows Update and I followed the link to the upgrade within Windows Update and then backed out of it. So I advise people to save that link to Microsoft that offers the "Upgrade Now" to Creators Update as well as the "Download . . . . to create ISO" or whatever the second button offered. If you don't save it, you can probably resurrect it within your Edge "history" list. That's what I had to do to get it back, since it was no longer available with my Win Update screen perpetually throwing an error and log for failure to update to KB4015214 -- the "Windows Update Assistant."

The previous and first time I attempted to install Win 10 Creators Update, it had been through the MS link that circumvents Windows Update. I recommend the Windows Update approach above all. What you CAN do in addition to that and prior to it is to use the Media Creation Tool to create the Build 1703 install disk -- tailor made to your system. You could also download the "full" version of the update through the Windows / Microsoft Catalog. Better to do all of these things as fallbacks.

With this particular sequence of Win 7 and Win 10 volumes on my single boot drive, the update to Build 1703 appears to be successful -- and it is, more or less. However, it messes with the BCD or Boot Configuration Data file on you boot disk. The symptoms I had of this are described in NeoSmart's EasyBCD documentation -- or similar symptoms are described. If, in Windows 10, I chose to restart the system to expect the dual-boot menu to appear after post, the system would instead boot directly to Windows 7. Restarting from there in Windows 7 will then shut down and restart through system post to the boot menu, from where you can uneventfully boot into Windows 10. Some would say this is acceptable or something to live with, But it fouls a lot of things up. For instance, if you configure Windows 10 to hibernate, it will not come out of hibernate properly and will instead boot to Windows 7. So before even reconfiguring or setting up hibernate, one would want this boot-menu problem solved.

It can supposedly be fixed within EasyBCD selecting the Backup & Restore button, then deleting all OSes listed for the BCD dual-boot setup, and then adding them back one at a time. HEre it is important to make sure both OS boot volume have a drive letter. Windows 10 will already be C :, but in my case, to avoid having one OS and user meddle with the boot volume of the second OS, I had chosen to delete drive letters for the OS not currently running. So the boot-volume for Win 7 would not have a drive letter when running Win 10, and vice-versa. But in order for EasyBCD to configure or even recognize the two OS volumes, they must both have drive letters. So you would simply assign a letter through Disk Management to the other volume. The OS in current use would be drive C : -- you might assign H : to the other OS volume if H is not in use.

Maybe there was an "Apply" button I didn't select in EasyBCD, and I can't remember for sure. But my BCD was totally destroyed after restarting. The system wouldn't boot into anything.

My previous problem with my Macrium Reflect Rescue disk was one of my own imagination. I couldn't get Macrium to "Search" and list both OS volumes. Either it would list none of them, or it would list only one of them as "C : \Windows . . " etc. This time, booting to Macrium Rescue Media, I didn't let it bother me that Win 10 wasn't listed while Macrium showed Win 7 as drive C :. I let it "fix" the boot problem for only one OS. From there, I was able to boot immediately into Win 7.

And when I got into Win 7 desktop, I made sure to assign drive letter H : to the Win 10 system volume. Then, I rebooted to the Macrium CD. Again selecting the "Fix boot and startup problems" in Macrium, I was able to "Add" windows 10 and a boot menu where I had previously restored only Windows 7. Once this was done, a fresh BCD file was created, and now we have Build 1703 of Win 10 working properly with Win 7 in a dual-boot menu that does not cycle as I described.

Thus, I see my problem here at an end. The moral of the story for those elite or obsessed few who must have a dual-boot system, who might have set it up in a better way and/or who just can't let go of all the tweaks they had made in perfecting Win 10 Build 1607, is simple. Always have a reliable backup image of your dual-boot physical disk handy with any rescue media needed for restoration. And a reliable backup imaging system should allow you to create a single image file that can contain the physical disk with all the boot volumes and BCD on it, and even fold into that image the volumes on other physical drives. The imaging system must be able to restore the dual-boot configuration perfectly after deleting all the volumes on the target physical disk. there can be no compromises.

Macrium does that. And in the end, it wasn't EasyBCD that restored me to full satisfaction with Build 1703. It was Macrium Reflect.