[Qemu-devel] Towards Vista RTM compatibility

[Qemu-devel] Towards Vista RTM compatibility

[Maciek Bieszczad]

Beginning with at least the later Beta 2 builds of Windows Vista, any
attempt to boot from the installation DVD comes with an instant blue-screen
in the form:

Stop error: 0xA5 (0x1000B, [addr], addr, 0)

where "addr" points to the signature of the FADT (which is "FACP"). The
origin of the error seems to be the HalpAcpiValidateAcpiTable function in
hal.dll, which basically does the following:

if header[signature] != "FACP"
	return 0
if header[revision] == 0
	return STATUS_ACPI_INVALID_DATA
else if header[revision] == 1
	length = 0x74
else if header[revision] == 2
	length = 0x81
else if header[revision] >= 3
	length = 0xF4
if header[length] >= length
	return 0
else
	return STATUS_ACPI_INVALID_DATA

Looking into the BOCHS BIOS code, the revision field was indeed set to 0.
After changing the value to 1, the boot process gets much further, even past
the default boot screen with the green scrolling bar. 

However, once the video mode changes a final time before what presumably
would be the setup GUI, another stop error immediately shows up with the
following vital data:

PAGE_FAULT_IN_NONPAGED_AREA
*** STOP: 0x00000050 (0x85DDDF66, 0x00000001, 0x8624AFFA, 0x00000002)
*** win32k.sys - Address 8624AFFA base at 86200000, DateStamp 4549aea2

The first error parameter corresponds to the invalid memory accessed, the
"1" indicates it was a write operation, and the third refers to the address
of the fatal instruction. This is extremely strange, considering 0x85DDDF66
seems to be a perfectly plausible address for the driver's relocated data
segment.

Unfortunately, the WinDbg/serial-pipe patches out there seem to be broken
ATM, and I can't get the debugger to connect (after hitting F8, and
selecting "Debugging mode" which should open a session with the highest
enumerated serial port). Disassembly of win32k.sys doesn't help much, other
than indicating the write takes place in a function involved with the SDPVTL
TrueType instruction.

For the record, I am currently testing with the final Vista RTM build and a
fresh CVS checkout of QEMU and BOCHS BIOS (other than the fix I mentioned).

Any ideas?

Maciek

[Qemu-devel] Towards Vista RTM compatibility

[Maciek Bieszczad]

Beginning with at least the later Beta 2 builds of Windows Vista, any
attempt to boot from the installation DVD comes with an instant blue-screen
in the form:

Stop error: 0xA5 (0x1000B, [addr], addr, 0)

where "addr" points to the signature of the FADT (which is "FACP"). The
origin of the error seems to be the HalpAcpiValidateAcpiTable function in
hal.dll, which basically does the following:

if header[signature] != "FACP"
	return 0
if header[revision] == 0
	return STATUS_ACPI_INVALID_DATA
else if header[revision] == 1
	length = 0x74
else if header[revision] == 2
	length = 0x81
else if header[revision] >= 3
	length = 0xF4
if header[length] >= length
	return 0
else
	return STATUS_ACPI_INVALID_DATA

Looking into the BOCHS BIOS code, the revision field was indeed set to 0.
After changing the value to 1, the boot process gets much further, even past
the default boot screen with the green scrolling bar. 

However, once the video mode changes a final time before what presumably
would be the setup GUI, another stop error immediately shows up with the
following vital data:

PAGE_FAULT_IN_NONPAGED_AREA
*** STOP: 0x00000050 (0x85DDDF66, 0x00000001, 0x8624AFFA, 0x00000002)
*** win32k.sys - Address 8624AFFA base at 86200000, DateStamp 4549aea2

The first error parameter corresponds to the invalid memory accessed, the
"1" indicates it was a write operation, and the third refers to the address
of the fatal instruction. This is extremely strange, considering 0x85DDDF66
seems to be a perfectly plausible address for the driver's relocated data
segment.

Unfortunately, the WinDbg/serial-pipe patches out there seem to be broken
ATM, and I can't get the debugger to connect (after hitting F8, and
selecting "Debugging mode" which should open a session with the highest
enumerated serial port). Disassembly of win32k.sys doesn't help much, other
than indicating the write takes place in a function involved with the SDPVTL
TrueType instruction.

For the record, I am currently testing with the final Vista RTM build and a
fresh CVS checkout of QEMU and BOCHS BIOS (other than the fix I mentioned).

Any ideas?

Maciek