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.