2

I have a recurring issue that prevents windows from being shut down, when the partition is cloned or migrated to another disk.

In this situation, clicking on shut down from start menu causes Windows to log out, and reboot back to the login screen. The only remedy for this is to issue a shutdown /s /f /t 0 command which will successfully shutdown Windows.

I suspect the issue is related to fast startup, a feature introduced in Windows which will hibernate the OS Kernel with a signed out user profile, rather than actually quitting the kernel.

Additional context

This will happen after cloning or migrating the partition where Windows is installed on. I use GParted to achieve this, which will break UEFI booting and thus I'll need to issue a bcdboot.exe c:\windows /s h: /f UEFI command from the recovery environment in order to restore the entry with the correct GUID for the boot drive.

How can I fix this issue without changing the fast startup or hibernate settings on Windows? The only other fix I know that works is a clean re-install, which negates the whole point of disk migration/cloning, and personally, I take as a sign of admitting defeat.

EDIT

I finally found the answer to my problem, described here.

David Refoua
  • 262
  • 2
  • 6
  • 20

2 Answers2

1

This is likely caused by the Windows kernel still being hibernated after the partition is cloned or migrated.

One solution to this problem would be to disable fast startup before cloning or migrating the partition. This can be done by going to Control Panel > Power Options > Choose what the power buttons do, and then uncheck the box labeled "Turn on fast startup".

  • You could also toggle powercfg hibernate off before the clone, and then after the clone completes, you can run powercfg hibernate on to turn that back on the original system.
  • The assumption is you are not using sysprep | generalize, shutting down on sysprep, and then doing the clone or making and image because this too may resolve this issue.

Another solution would be to use a third-party tool that is designed to handle the cloning or migration of Windows partitions, such as Macrium Reflect which can properly handle the hibernation state of the Windows kernel.

  • Or you could check if there are other options with your current cloning tool to use to better handle the the hibernation state of the Windows Kernel.

As a workaround, you can try the command shutdown /p instead of shutdown /s as it is used to power off the computer instead of shutting down and per the Windows kernel hibernation state, it could matter.

Lastly, a clean re-install may not even fix the issue because it doesn't always address the "hibernation state" of the Windows kernel before the clone is made.

Bonus item

  • According to Disable Fast Startup "Just turn off the machine to be cloned by pressing SHIFT when you shutdown. This disables fast boot only for this moment." so consider testing this at clone/image creation time.

Supporting Resources

Vomit IT - Chunky Mess Style
  • 42,624
0

EFI system flag not set correctly

Okay, I solved my issue while browsing for solutions to another problem, Windows Update failing to complete setup on my system. I came upon this answer by martijnvan der ploeg, which like me had cloned his disk to another drive.

It seems that the EFI system partition type field was missing from my boot partition (which is usually around 100 MBs), thus Windows was failing to sleep/hibernate/shutdown.

The author provides the following instructions to restore the flag:

diskpart
select disk <id>
select partition <id>

SET ID=c12a7328-f81f-11d2-ba4b-00a0c93ec93b

This is the important GUID that sets the partition as EFI, which results in:

DISKPART> list partition

Partition ###  Type              Size     Offset




Partition 1    Recovery           529 MB  1024 KB 
  Partition 2    System             100 MB   530 MB

Personally, I don't care about the Recovery partition, so I didn't bother to copy it as well to the new disk, also no other drives where connected at the time. So when doing list disk and list part, I see only disk 0 with part 0 being the System partition, so I went ahead and sel disk 0 and sel part 0 them.

I'm so happy that he actually decided to go through the CBS.log log file to actually understand and debug the issue, instead of the usual steps that other people suggest in order to nuke the downloaded files and then restart windows update services, which aren't even related to the boot upgrade procedures.

BTW, I found this other guide (in german) which explains how to create this EFI partition, from scratch. It's pretty similar, you only need bcdboot.exe to populate the newly created partition.

Since my EFI partition contains some other EFI files that I didn't want to touch (mainly some utilities, also another bootloader) I didn't create it from scratch, just restored the missing flag. A reboot, and BAM! Now everything works fine on the system, like it should have been from the beginning.

P.S. Absolutely no need to clean install, unnecessary reboots, cleans, etc people. Learn to fix the problem, unlike many "advisors" on the Microsoft forum "advising" you to nuke everything and start from scratch. Be like martijnvan der ploeg, read logs, debug and fix the actual issue rather than a clean install.

David Refoua
  • 262
  • 2
  • 6
  • 20