[Bug 1229886] Re: Grub2 cannot bring Win 7 out of hibernation - error 0xc000009a

[Robin Battey]

I have the same problem, but also a fair bit of information gleaned from
experimentation.  Here are my notes:

My setup:
* Lenovo T530 (yes, it can hold 3 internal hard drives, two SATA and one mSATA)
* Windows 7 EFI on /dev/sda1=(hd0,gpt1), Windows install on /dev/sda2=(hd0,gpt2)
* Ubuntu 12.04.3 EFI on /dev/sdc1=(hd2,gpt1), Ubuntu install on /dev/sdc2=(hd2,gpt2)
* grub-efi is installed on (hd2,gpt1)/efi/grub/grubx64.efi
* rEFInd is installed on both EFI partitions under /efi/refind/refind_x64
* Attempts to resume Windows from hibernate using grub result in the 0xc000009a windows error

Things of note:  I *had* resume working without issue, using MBR booting
rather than UEFI booting and using the drivemap -s grub command to fake
the bios ordering for windows (windows MBR resume *only* looks for the
BCD on the first bios drive...so stupid), but when my SSD crashed I
installed a fresh from-disk copy of Win7 Pro.  To do this, I actually
*removed* all my linux drives from the machine so that the windows
installer had no chances of screwing up the linux partitions or boot
sequence, so windows installed thinking it was the only OS on the only
drive on the system.  It installed itself using UEFI booting, which
caused me headaches until I converted my linux grub install to use grub-
efi.  However, I've collected lots of data in my floundering yet
ultimately successful attempts to get windows booting from grub-
efi...though I still can't resume from hibernate using grub.

Here's what I've found:

* It doesn't matter if the linux disklabel is GPT or msdos/MBR -- so long as you insmod the proper grub module for the partition table, behavior is exactly similar (can boot linux just fine, and can boot windows but not resume windows from hibernate)
* It doesn't matter if you use the standard UEFI image location of /EFI/Boot/bootx64.efi for grub or if you use the standard /EFI/grub/grubx64.efi location, exact same behavior.
* It doesn't matter if grubx64.efi is installed on the same EFI as windows, or on a different drive (though I must point out that my grub modules are on a different drive -- I have not tested with Ubuntu and Windows on the *same* drive entirely)
* It doesn't matter if the grub EFI partition is partition 1, or partition 3, or partition 4, or if the EFI partition is near the start of the disk or near the end...I've tried all combinations and it's the exact same behavior, both with GPT and MBR disklabels.
* No matter how many times hibernate fails to resume, if I boot directly to the windows EFI image (not through grub), the resume succeeds.   Similarly, it will succeed if I boot directly to rEFInd (not through grub), either of them, and then attempt to resume windows from there. 

Here's the most interesting stuff I've found:

* rEFInd *can* resume windows from hibernate, using its default of loading /efi/Microsoft/Boot/bootmgfw.efi.
* rEFInd can reusme windows from either refind installation, even -- it doesn't care if it's the same drive or not.
* rEFInd ***CAN'T*** resume windows from hibernate if you've chainloaded to it from grub. Same behavior.

Basically, I can chainload from rEFInd to rEFInd all day long (I have
two installs, one on each OS drive) and then resume windows from
hibernate, but once I've let grub into the chain, resume from hibernate
breaks.  If I reboot and select a boot path that does not include grub,
that same previously-failed resume attempt will succeed. Grub is clearly
doing something to alter the EFI environment in a way that breaks
windows resume, and in a way that rEFInd does not.

For now, I'm booting using rEFInd, which is annoying because the OS
ordering is random each boot...but at least it functions.  I'm parsing
through the rEFInd source code and the EFI chainloading code, looking
for conceptual differences, but I'm in a little over my head there.  I
hope this information helps other, more knowledgeable people find the
answer more quickly.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1229886

Title:
  Grub2 cannot bring Win 7 out of hibernation - error 0xc000009a

Status in “grub2” package in Ubuntu:
  Confirmed

Bug description:
  Installed Ubuntu 12.04  for dual-boot on HP P7-1222 (a UEFI machine
  that came with Win 7).  All Ubuntu and Win 7 updates are installed,
  current as of 9/20/2013.

  Ubuntu works well. The 'Grub2 "Windows Boot UEFI loader" selection
  boots Windows 7 64-bit fine, too.

  Problem is: Win 7 cannot resume from hibernate.

  Pre-Ubuntu I had activated Win 7 hibernation and used it successfully.
  I like to hibernate my Windows machines and then unplug them to
  protect against voltage spikes etc., but have a fast restart with
  retained state.

  After Ubuntu was installed, if I hibernate Win 7 (which it seems to
  do) and the machine turns off.  If I then try to resume Win 7 from
  hibernation, I get a "Your computer cannot come out of hibernation
  0xc000009a" error from the Windows loader.

  If I try to reboot Win 7 again from Grub2 I am presented with the
  "delete hibernation file and restart" option, which then does so and
  reboots Win 7 OK. Of course, searching on the 0xc000009a error code
  brings up little of value. (Thanks, MS, for such informative error
  messages.)

  I've tried the "off the top of my head" attempted fixes - powercfg -h
  off, then powercfg -h on; defragmenting; etc. No change.

  In effect, I cannot use hibernation in Win 7 anymore.

  This seems to be a grub2 bug.  It does not occur on a dual-boot non-
  UEFI Celeron 352 machine w/Ubuntu 12.04 and Win 7 (note that the old
  machine is unning the 32 bit version of Win 7 but the 64-bit version
  of Ubuntu).

  I believe this is a Grub bug, but have no idea what source package the
  bug is in.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229886/+subscriptions