[vbox-dev] GPT corruption on Windows versions with the NT5 kernel

[Matt Coleman]

Hello,

I've documented a reproducible case where Windows sees large disks (over 
2TB) as the total disk size minus 2TB. When I use 'VBoxManage 
storageattach ...' to add the disk to a running Windows VM, this causes 
Windows to decide that the backup GPT header is missing, so it writes a 
new backup header at the location that it thinks is the end of the disk 
(2^32 sectors from the end of the disk); this corrupts whatever file is 
at that location. This occurs in any version of Windows that's running 
the NT5 kernel and has GPT support, which includes Windows 2003 SP1 and 
later along with Windows XP x64 Edition.

I have verified that the corruption occurs only when the disk is 
attached to a SATA controller on the VM, and the same corruption occurs 
using KVM as the virtualization platform; it does not occur on a 
physical system (based on a Gigabyte GA-D525TUD motherboard, which has 
the NM10 Express chipset - I do not have access to any ICH8 or ICH9 
physical systems). It does not occur if you boot the same VM using a 
Linux LiveCD ISO image, which leads me to believe that it's a bug in 
either Microsoft's Windows SATA code or Intel's SATA controller driver 
that only manifests itself when virtualized.

Aside from the incorrect sizing and GPT header/data corruption, 
something is preventing the Windows bootloader from loading if the large 
volume is attached to the VM before booting. If you attempt to boot the 
machine with a large (>2TB) volume attached to a SATA or SCSI 
controller, it freezes at a black screen with no cursor. If I create an 
unpartitioned, empty raw disk and attach it to a SCSI controller on the 
VM, Windows is able to boot and then I can use Disk Management to 
partition and format its full capacity. However, once I shut down (or 
reboot) the machine, it will no longer boot, freezing at a black screen 
with no cursor just the same as when attaching the volume to the SATA 
controller.

I had a brief discussion with Klaus in #vbox on Freenode, during which I 
reproduced the bug as follows:
largevolume-vbox13.vmdk is a text header file with no data, pointing to 
largevolume-vbox13.raw; see its contents here: 
http://paste.ubuntu.com/1071285/

largevolume-vbox13.raw is a 2726162350592 byte (approximately 2.5TiB) 
GPT partitioned with a single NTFS partition; see its partition table 
throughout the tests here: http://paste.ubuntu.com/1071279/

First boot: In the VirtualBox GUI, I attached largevolume-vbox13.vmdk to 
port 1 of the virtual machine's SATA controller. The machine freezes at 
a black screen with no cursor, shortly after the VirtualBox BIOS splash 
screen. See the VBox.log file for this boot here: 
http://paste.ubuntu.com/1071275/

Second boot: Windows was booted without largevolume-vbox13.vmdk 
attached, then it was attached to the VM once Windows had reached the 
GUI and I logged in. As soon as the disk becomes visible in Disk 
Management, the partition table gets corrupted, as can be seen in the 
partition tables pastebin (http://paste.ubuntu.com/1071279/). See the 
VBox.log for this boot here: http://paste.ubuntu.com/1071276/

Third boot: I created an unpartitioned raw disk image and VMDK as 
documented in the last entry in the partition table pastebin 
(http://paste.ubuntu.com/1071279/). Windows recognized the disk as a 
490.9GiB drive and partitioned it accordingly (as an MBR disk) when I 
followed the new disk initialization wizard. See the VBox.log for this 
boot here: http://paste.ubuntu.com/1071277/

In this screenshot, I had booted the Windows VM, then attached the drive 
to a port on its SATA controller; notice that Disk Management is showing 
the correct volume size (2538.94GB), wmic is showing the incorrect size 
for the volume (527133519360 bytes), and gdisk is showing an incorrect 
total volume size (490.9GiB) and the correct partition size (2.5TiB). 
http://imagebin.org/219211

The same situation in KVM: http://imagebin.org/217124

The data corruption issue is causing serious problems for me, and using 
the SCSI controller could be a workaround if it supported hotplugging.

Some additional reading:
Mentions a situation in which Windows can hit a black screen with no 
cursor while booting:
http://blogs.msdn.com/b/ntdebugging/archive/2007/06/19/how-windows-starts-up-part-1-of-4.aspx

Talks about storage drivers incorrectly accessing disks larger than 2TB:
http://support.microsoft.com/kb/2581408

A discussion in which a 2TB limit on ICH8 is discussed, although it's 
only mentioned specifically in the context of the controller's RAID mode:
http://www.tomshardware.com/forum/page-216247_30_50.html

Thanks in advance...

Matt

-- 
*Matthew Coleman*
Developer :: Datto Inc. :: www.dattobackup.com :: (203) 710-4470
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20120702/39ee67d9/attachment.html>