Dual Boot W11+W11 - 2nd One Takes Two Minutes

Just got my replacement laptop and trying to set up a dual boot like my old W10 one. It has 1TB NVMe, and I allocated 200GB for the second boot partition. Having got all updates available, I cloned the existing Windows partition onto the secondary partition, ran bcdedit and now have a dual boot menu. Both partitions are identical with the exception that I've since installed Word and Excel on the primary partition.

When I boot it up, selecting 'Windows 11' (main partition) takes 2-3 seconds for the Windows login screen to appear. If I then restart the laptop (to try something in the test partition) and select 'Windows 11 Test' (secondary partition), it's taking just over two minutes for the Windows login screen to appear. Further to that, if I restart and choose the 'Windows 11 Test' one again, it takes around 25 seconds for the login screen to appear and another 10 or so seconds before I can get the login field to appear. Within Disk Management, I have deleted the drive letter associated with the other partition.

I've used this process before with Windows 7, Windows 8 and Windows 10 and never had any issues before, using both HDDs and SSDs. This is the first time with a NVMe, but wouldn't have thought it would be any different. Where do I start looking?

Do you have Fast Startup enabled? If so, try disabling it (in both installs).

If disabled, try enabling it (again, both installs).

Thanks. Just trying that now. In the meantime, I went into msconfig and ticked the 'boot log' option. Rebooted into both partitions and checked the log files from both (see attached). I went through them both and they seem identical, with the following lines for items not loaded being listed (some multiple times):


UPDATE: I just tried several boots with both partitions having Fast Startup disabled (it had been enabled by default). Rebooting into each one was taking the same 2-3 and 25 seconds for the W11 and W11T (test). I've shut it down for now and will try booting into the test partition first thing tomorrow to see if I still have that two minute delay.

Using WinMerge, I only see the following differences:


Everything else is actually not in the same location (line number) but is there.

How did you clone the system?

I cloned the primary partition using the free version of Macrium Reflect to an external SSD drive. Then used the Restore option and placed the cloned partition into the 200GB partition. I could probably have cloned it directly to it, bur decided to err on the side of caution.

After leaving it overnight, I booted it up and selected the 'Test' partition first, and it took around 25 seconds to get to the login screen. I might enable fast boot again to see if the initial boot into it takes 2 minutes like previously.

Update to 'Fast Startup' - I enabled it on the Test partition, restarted, and it took two minutes to go into the primary partition, so that confirms the two minute startup. That's now been disabled again.

Still have the 25 second delay accessing the Test partition. Been searching for similar issues and came across one person who had a dual boot, but with Windows and Linux, with a two minute accessing the Linux partition. He listed his bcdedit file and someone identified an issue with his 'resumeobject' in the Boot Manager section. In his case, the resumeobject didn't exist.

I've attached my bcdedit file, having booted into each partition. Would the resumeobject being set to the primary partition cause the delay?

steamship said:

I've attached my bcdedit file, having booted into each partition. Would the resumeobject being set to the primary partition cause the delay?

Click to expand...

If the secondary partition is booting but then has to access the primary partition / volume to satisfy this resumeobject condition, then I would say absolutely.

And since the value in in both entries is pointing to the same GUID (therefore the same partition / volume), I suspect what is happening is that the boot process is deleting the file / store / object created by the other installation's boot process and recreating it for the current installation, which is why after booting into the test partition, the primary installation then also takes much longer to boot, because it then does the exact same thing as well.

However, if you repeatedly boot into the same installation, it should not still take the same amount of time. Unless the volume has been flagged (somehow) to let both installations know that that particular object is shared between two installations, so now it always deletes and recreates it. Which, now that I think about it - the BCD entries themselves might be the flag / cause for the forced deletion and recreation?

You could try the following:

Find the GUID through diskpart - and if that resumeobject setting is indeed pointing to the default installation's partition / volume, change it to the corresponding one for the test partition.

I would expect it to clear up both of those longer boot issues simultaneously, but it may not, and at this point I'm not even sure where else to troubleshoot if that does not.

johnlgalt said:

Find the GUID through diskpart - and if that resumeobject setting is indeed pointing to the default installation's partition / volume, change it to the corresponding one for the test partition.

Click to expand...

If I understand you correctly, are you asking me to change the 'resumeobject' in the 'Windows Boot Manager' from '{cc62dffe-a68e-11ed-ae1c-7c4d8f100967}' (which is my original C: drive) to '{1a9364f0-bc48-11ed-8405-eedab6bb450b}' (which is the cloned Windows 11 Test drive) whilst I'm booted into the Windows 11 Test system?

I had considered that to see if it had any effect, but I've been searching and can't find any command to allow me to change that field.

steamship said:

If I understand you correctly, are you asking me to change the 'resumeobject' in the 'Windows Boot Manager' from '{cc62dffe-a68e-11ed-ae1c-7c4d8f100967}' (which is my original C: drive) to '{1a9364f0-bc48-11ed-8405-eedab6bb450b}' (which is the cloned Windows 11 Test drive) whilst I'm booted into the Windows 11 Test system?

I had considered that to see if it had any effect, but I've been searching and can't find any command to allow me to change that field.

Click to expand...

Exactly. I suspect having it be the same for both boot environments is causing the slowdown.

As for changing it by itself - the BCD file itself should just be text, I think you can manually edit it and then use BCDEdit to push it like you would a normally generated one.

However, I'm not sure this will work - for all I know that resumeobject entity is not in fact for a hibernation / sleep file, but rather something entirely different. But even if it temporarily breaks your second installation boot, it should not change the primary one (but be sure to make a system image just in case).

I came across a program called VisualBCD and installed it on my old laptop which has dual boot set up with W10+W10Test. From just playing around with it (not making any permanent changes), I can copy the GUID ID for the Test partition and put that into the ResumeObject in the 'Windows Boot Manager'... but I'm leaving that until tomorrow morning. Going to do the easy bit tonight and get images of both partitions.

So installed VisualBCD on both partitions on the new laptop. Before using it, I did a few more reboots into each of the partitions sequentially and alternatively, and spotted something. In the above post where I attached the two TXT files containing the bcdedit output from both partitions, the 'resumeobject' in the 'Windows Boot Manager' was '{cc62dffe-a68e-11ed-ae1c-7c4d8f100967}'. It turns out that the 'resumeobject' contains the GUID ID of the last booted drive.

e.g. Booting from Main to Test will give '{cc6...', as will Main to Main. However, booting from Test to Main will give '{1a9...', as will Test to Test.

So, no further forward as to the 25 second delay.

What I also noticed when playing with my old laptop was that from powering on, it takes about 4-5 seconds to display the Windows boot menu. Booting in Windows 10 takes about 10 seconds (installed on a SSD) and booting into Windows 10 Test takes about 1 minute (installed on a HDD).

Weirdly, my brand new laptop with a NVMe takes about 15 seconds just to display the Windows boot menu.

Ahhh. That makes sense. so it is an auto-populated value.

I'm currently out of ideas at the moment, but there is something here that we should be able to tackle. I just don't know what that is at the moment.

johnlgalt said:

Ahhh. That makes sense. so it is an auto-populated value.

I'm currently out of ideas at the moment, but there is something here that we should be able to tackle. I just don't know what that is at the moment.

Click to expand...

Thanks for the help anyway. Having just noticed the 15 second delay on the new laptop just getting to the boot menu, compared to my 9 year old laptop, I think I'll post the question on the HP site. I just need to be careful as they don't like anything negative being said about their products... I've already had one post deleted because I complained about how long it took to get the laptop (19 days instead of 2), after having been promised it three times by three different staff that I spoke to.

Interesting. I helped my Dad get a laptop last year, and ran into something similar, except not only was it late by 2 weeks, but the box was physically damaged as well, which had a small dent in the laptop cover too. Had to fight tooth and nail with them to get them to replace it as a brand new device. That replacement was also late, by a week.

There has to be something that I'm missing. I really think that because of the cloning, it is attempting to use some part of the main installation partition for something. Mind you, I'm not saying this is your fault - but rather, that Windows has some very stupid ideas, when it comes to a cloned partition.

You could always try booting into the test installation and re-setting up the sleep / hibernation in there to verify that it is using the test partition and not the main install partition, since you've already changed the fastboot options. But it might take a deep dive into the registry to find some tiny, obscure offending key that is making the test install access the main partition.

EDIT: Added the following:

Oh, lightbulb moment! How about going into the test install, then running sysprep to perform a new OOB setup, and see if that fixes it?

johnlgalt said:

Interesting. I helped my Dad get a laptop last year, and ran into something similar, except not only was it late by 2 weeks, but the box was physically damaged as well, which had a small dent in the laptop cover too. Had to fight tooth and nail with them to get them to replace it as a brand new device. That replacement was also late, by a week.

Click to expand...

Ha, can beat that hands down. Not only did it take 19 days to arrive, I sent it back for a new one within 30 days as the trackpad was becoming unresponsive over about 2/3 of the surface, including the left-click. The 'new' replacement exhibited the same issue within two weeks and I was that disgusted, I put it in the box and went back to my 9 year old laptop. Eventually wised up, got it out again, tried lots of things and contacted support. It was now outside their 30 days return, so it was sent back for repair. That came back and lasted 2 days before the same issue. Sent back again, came back (and for some reason they replaced the main battery) and it failed yet again. Had to send them a video of the problem. Didn't want it going back again for repair, didn't want my money back as the prices had risen by £300 during that time, so only option was another new one, but a better spec to compensate for all the hassle. That's the one I'm trying to sort out now with dual boot, and as such still doesn't have much installed yet.

Anyway, checked both partitions and Hibernation isn't even ticked. Disabled the Sleep option (in both) and shut down. Restarted but still having the same problem, so re-enabled Sleep as it might kick in if I'm away from the laptop for a while. It's set at 5 minutes which works for me, as it'll only kick in about 1% of the time.

Did some searching on Sysprep beforehand and it seemed straightforward, so booted into Test partition. Ran it and it eventually failed. Did some more searching and it appears that it doesn't like having other programs installed and/or all the Windows apps have to be installed. Checked a few things and ran it a second time, and it failed again on the verification stage. After another reboot into the Test partition, it was indeed the OOB process than ran. Completed that, shut it down and powered on again, but still the 15 second delay. What was more of a surprise was this morning when I booted up into the main partition, as that was also displaying the OOB process. Everything still there, apps and what little data I've saved on it so far, so no harm done, but no further forward unfortunately.

Posted on the HP site, but no response yet.

steamship said:

What was more of a surprise was this morning when I booted up into the main partition, as that was also displaying the OOB process.

Click to expand...

Oddly enough, but that right there screams to me that they are sharing something somewhere (besides the bootloader, naturally). Running Sysprep to force the OOBE to run on one installation should not have had anything to do with the other one.

And "Ye, gods, man!" - you definitely got my Dad beat lol!

Nice that you were able to sorta upgrade though....I know, I know, only if it actually starts working.

johnlgalt said:

Oddly enough, but that right there screams to me that they are sharing something somewhere (besides the bootloader, naturally). Running Sysprep to force the OOBE to run on one installation should not have had anything to do with the other one.

And "Ye, gods, man!" - you definitely got my Dad beat lol!

Nice that you were able to sorta upgrade though....I know, I know, only if it actually starts working.

Click to expand...

Thought you'd like that.

Haven't had any responses from the HP forums so far. I was contemplating last night about booting into the recovery management and revert the laptop back to the start. It's not as if I'll be losing much as only installed Chrome, Partition Wizard, Macrium Reflect, Word and Excel on the main partition plus a few tweaks, and one program on the Test partition. Was then thinking of resizing the partition again, downloading the Windows ISO from MS and install it on the Test partition and using the product key from the main partition. Only concern would be if the product key would work, as the laptop came pre-activated as it's OEM.

That's actually a valid question. Technically speaking, it *should* be legal, as it is the same physical machine, and you are dual booting, so you can't log into both (installs) simultaneously, it's one or the other, and also, technically speaking, it's a fair use practice to have the identical OS (being a clone) as what you have installed now, specifically for the moments when your evil cousin Justin Case comes to visit....

Bu that is all my own opinion. What Microsoft actually deems fair use and allowable and legal, may be completely different.

Decided to bite the bullet and reset the laptop back to factory settings and start from scratch. Went through the OOB settings and did the obligatory Windows Updates. When all that was done, powered it down and then restarted to time it. Roughly 2-3 seconds to get to the Window login screen. That confirms that dual boot is adding to the bootup time. Installed Partition Wizard and resized partition as before.

Then went onto the MS site and downloaded the latest Windows 11. Prepped a USB and booted into that. Installed it on the new partition, went through the OOB process and Windows Update. A lot more needed as it had to install all the necessary drivers for the hardware. It automatically created a dual boot menu.

On the next reboot, it's the same as I've been experiencing before. 15 seconds just to get to the dual boot menu, 2-3 seconds to get to the original Windows login screen and around 25 seconds to get to the secondary Windows login screen.

BTW In relation to the product key for the secondary install, because of the necessity to login to your MS account, the product key is saved there from my initial setup, and so it uses that for the new install, and as you say, it's physically impossible to run both instances at the same time.

Also, after a week, I got one response on the HP forum which was just your typical generic response to certain keywords in my post, none of which was relevant to the actual question.

Though the boot menu is taking a bit of time, at least booting into the default installation is now back down to 2-3 seconds. I suspect that at this point it can probably be relegated to annoyance level as that is a backup install for testing / troubleshooting, correct?