win7/x64 installer hangs on startup with 0x0000005d.

Bug #921208 reported by Paweł Sikora
84
This bug affects 16 people
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Unassigned
qemu (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

hi,

during booting win7/x64 installer i'm observing a bsod with 0x0000005d ( msdn: unsupported_processor ).

used command line: qemu-system-x86_64 -m 2048 -hda w7-system.img -cdrom win7_x64.iso -boot d

adding '-machine accel=kvm' instead of default tcg accel helps to boot.

installed software:

qemu-1.0
linux-3.2.1
glibc-2.14.1
gcc-4.6.2

hw cpu:

processor : 0..7
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
stepping : 7
microcode : 0x14
cpu MHz : 1995.739
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 3992.23
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual

Revision history for this message
Paweł Sikora (pluto-pld-linux) wrote :

more info: virtualbox-4.1.8 boots this win7/x64/ultimate iso without any problems.
i can provide more info if you need....

Revision history for this message
Paolo Bonzini (bonzini) wrote :

Please try "-cpu kvm64" (yes, even if you are using TCG).

Revision history for this message
Paweł Sikora (pluto-pld-linux) wrote :

'-machine accel=tcg -cpu kvm64' doesn't work == bluescreen.

Revision history for this message
Alexandre Derumier (aderumier-odiso) wrote :

I could you try with "-cpu host,level=2"

I see you have a westmere cpu, and maybe this is related:

I'm developper on the proxmox distribution.

We are using kvm git, and one of our user can't boot guest win7x64
with -cpu host. (but it's working with linux guest).

It's working fine with -cpu host,level=9

but not with -cpu host,level=10 or level=11.

We also try with new Westermere cpudefs in target-x86_64.conf
(see redhat patches from february 2012)

[cpudef]
   name = "Westmere"
   level = "11"
   vendor = "GenuineIntel"
   family = "6"
   model = "44"
   stepping = "1"
   feature_edx = "sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu"
   feature_ecx = "aes popcnt sse4.2 sse4.1 cx16 ssse3 sse3"
   extfeature_edx = "i64 syscall xd"
   extfeature_ecx = "lahf_lm"
   xlevel = "0x8000000A"
   model_id = "Westmere E56xx/L56xx/X56xx (Nehalem-C)"

That also doesn't without change level < 10.

User also report that "-cpu host" was working fine with qemu 0.15.

I see that other intel cpudefs in target-x86_64.conf have level=2, maybe does it need to be the same for westmere ?

Best Regards,

Alexandre Derumier

Revision history for this message
Paweł Sikora (pluto-pld-linux) wrote :

the westmere cpudef with level 2,9,10,11 doesn't work for win7/x64.

Changed in qemu:
status: New → Confirmed
Revision history for this message
Luigi Tarenga (luigi-tarenga) wrote :

Hi,
I almost identical problem so i post here my comment.
I'm trying to use qemu 1.1.0 to run some vm on a RHEL5.8 _without_ kvm accelaration
(the host have 24 cpu core, I can't install kvm module on the server, policy problem,
but I still want to exploit some cpu power).

I compiled qemu 1.1.0 with default options (just --prefix=...) and it works with linux
guests (very few try, ttylinux, Oracle Linux, all seems fine.) but I'm not able to start
any Microsoft Windows guest (tried installed guest from virtualbox and iso installation cd).
Here the systems I tried:

Windows 2008 R2 x64:
qemu-system-x86_64 -m 2048 -cdrom win2008r2x64.iso -hda /work.local/vm/test.win2008.qcow2
blue screen:
*** STOP: 0x0000005D (0x

Revision history for this message
Luigi Tarenga (luigi-tarenga) wrote :

Hi,
I almost identical problem so i post here my comment.
I'm trying to use qemu 1.1.0 to run some vm on a RHEL5.8 _without_ kvm accelaration
(the host have 24 cpu core, I can't install kvm module on the server, policy problem,
but I still want to exploit some cpu power).

I compiled qemu 1.1.0 with default options (just --prefix=...) and it works with linux
guests (very few try, ttylinux, Oracle Linux, all seems fine.) but I'm not able to start
any Microsoft Windows guest (tried installed guest from virtualbox and iso installation cd).
Here the systems I tried:

Windows 2008 R2 x64:
qemu-system-x86_64 -m 2048 -cdrom win2008r2x64.iso -hda test.win2008.qcow2
blue screen:
*** STOP: 0x0000005D (0x00000000078BFBF9,0x0000000000000000,0x0000000000000000,0x0000000000000000)

Windows 8 ConsumerPreview 32bit:
qemu-system-i386 -m 2048 -cdrom Windows8-ConsumerPreview-32bit-English.iso -hda test.win8-32.qcow2
black screen:
Your computer needs to restart.
Please hold down the power button.
Error Code: 0x0000007F
Parameters:
0x0000000D
0x00000000
0x00000000
0x00000000

Windows 8 ConsumerPreview 64bit:
qemu-system-x86_64 -m 2048 -cdrom Windows8-ConsumerPreview-64bit-English.iso -hda test.win8-32.qcow2
Your computer needs to restart.
Please hold down the power button.
Error Code: 0x000000C4
Parameters:
0x0000000000000091
0x000000000000000F
0xFFFFF80169728880
0x0000000000000000

Windows XP SP3 32bit:
qemu-system-i386 -m 512 -cdrom /work.local/software/WindowsXP-SP3/Win_XP_Pro_SP3.iso -hda /work.local/vm/test.winXP.qcow2
Hang on a black screen

the host have 2.6.18-308.el5 kernel and cpus are:
# cat /proc/cpuinfo | tail -24
processor : 47
vendor_id : GenuineIntel
cpu family : 6
model : 47
model name : Intel(R) Xeon(R) CPU E7- 4807 @ 1.87GHz
stepping : 2
cpu MHz : 1864.694
cache size : 18432 KB
physical id : 3
siblings : 12
core id : 25
cpu cores : 6
apicid : 243
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx pdpe1gb rdtscp lm constant_tsc nonstop_tsc arat pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm
bogomips : 3729.51
clflush size : 64
cache_alignment : 64
address sizes : 44 bits physical, 48 bits virtual
power management: [8]

I tried the same ISOs on a netboot with kernel vanilla 3.4.2 and core 2 duo cpu:
with kvm (-enable-kvm):
Windows 2008 R2 x64: boot ok
Windows 8 ConsumerPreview 64bit: boot ok
Windows 8 ConsumerPreview 32bit: boot ok
Windows XP SP3 32bit: hangs with black screen as in bug #1013888
(https://bugs.launchpad.net/qemu/+bug/1013888)

without kvm: all fails

regards
Luigi

Revision history for this message
zappacor (zappacor-l) wrote :

Hi Stefan,

also experiencing this issue after installing PointSec:
1) installed win7 64bits (by manually decompressing the .WIM installation files and making the disk image file bootable)
2) installed PointSec FDE (Full Disk Encryption => http://www.checkpoint.com/products/full-disk-encryption/index.html)
3) now, whatever qemu parameters I use, I get either:
   A) the BSOD: 0x0000005D (0x0000000078BFBF9,0x0000000000000000,0x0000000000000000,0x0000000000000000)
or:
  B) a "KVM internal error. Suberror: 1 / emulation failure" and a qemu dump like this one:
KVM internal error. Suberror: 1
emulation failure
EAX=00000130 EBX=00000000 ECX=00014000 EDX=00050000
ESI=00000000 EDI=00000000 EBP=00008e3f ESP=0001802d
EIP=000006d3 EFL=00017087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0048 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
CS =25a1 00025a10 0000ffff 00009b00 DPL=0 CS16 [-RA]
SS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA]
DS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA]
FS =0130 00300000 ffffffff 00c09300 DPL=0 DS [-WA]
GS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= 00028050 00001dd8
IDT= 00029e40 00000188
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Code=00 8e c0 b8 30 01 8e e0 66 b9 00 00 00 00 66 ba 00 00 00 00 <66> 26 67 8b 9a 00 00 05 00 66 64 67 89 1a 66 83 c2 04 66 41 66 81 f9 00 80 01 00 75 e3 0f

My system info:
root@RJZ-LNX:/home/rjz# cat /proc/cpuinfo | tail -24
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i5 CPU M 480 @ 2.67GHz
stepping : 5
microcode : 0x2
cpu MHz : 1199.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt lahf_lm ida arat dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 5319.72
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

root@RJZ-LNX:/home/rjz#

and qemu (Ubuntu distribution) info is:

root@RJZ-LNX:/home/rjz# qemu-system-x86_64 --version
QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard

Best regards,
Rolando.

Revision history for this message
zappacor (zappacor-l) wrote :

On second thought, I'll open a new bug for the KVM crash while booting PointSec

Revision history for this message
Valerio Angelini (amailp) wrote :

have you tried with "-cpu kvm64,+nx" ?
The additional parameter enables the No eXecute (NX) bit.

Revision history for this message
Clemens Kolbitsch (kolbitsch) wrote :

We have been discussing this issue on the QEMU mailing list. It is of CPU definition, but none of the current configurations allow QEMU to boot Windows7 64bit WITHOUT KVM. The issue behind it is that the TCG (code generator) might not fully support all CPU bits required by Win7.

There is a patch to bypass this problem, but the OS still does not boot reliably (BSODs occur after a few minutes).

Note that it works with KVM enabled

Revision history for this message
zappacor (zappacor-l) wrote :

Hi Valerio/Clemens,

in my case, Windows 7 alone runs great!

I face this issue after installing PointSec to encrypt the (emulated) disk from the Windows 7 itself.

Playing with above suggested parameters:

1) "-cpu kvm64,+nx -no-kvm" the BSOD:
 0x0000005D (0x0000000078BFBF9,0x0000000000000000,0x0000000000000000,0x0000000000000000)

2) "-cpu kvm64,+nx -enable-kvm" loads, starts and run Windows 7. Now, I install PointSec and then the system reboots, installs PointSec boot code and reboots again. After that, while PointSec is loading, I get the KVM crash:
 KVM internal error. Suberror: 1
 emulation failure
 EAX=00000130 EBX=00000000 ECX=00014000 EDX=00050000
 ESI=00000000 EDI=00000000 EBP=00008e3f ESP=0001802d
 EIP=000006d3 EFL=00017087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
 ES =0048 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
 CS =25a1 00025a10 0000ffff 00009b00 DPL=0 CS16 [-RA]
 SS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA]
 DS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA]
 FS =0130 00300000 ffffffff 00c09300 DPL=0 DS [-WA]
 GS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA]
 LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
 TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
 GDT= 00028050 00001dd8
 IDT= 00029e40 00000188
 CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
 DR6=00000000ffff0ff0 DR7=0000000000000400
 EFER=0000000000000000
 Code=00 8e c0 b8 30 01 8e e0 66 b9 00 00 00 00 66 ba 00 00 00 00 <66> 26 67 8b 9a 00 00 05 00 66 64 67 89 1a 66 83 c2 04 66 41 66 81 f9 00 80 01 00 75 e3 0f

3) Running again "-cpu kvm64,+nx -no-kvm" loads PointSec fine so I type its configured user/passwd in. It then starts to boot Windows and then I get again the BSOD

4) From this point on, either the BSOD for "-no-kvm" or the crash for "-enable-kvm" but NOT before installing PointSec (while, despite of the BSOD for "-no-kvm", "-enable-kvm" worked just fine). Summing up, I either get PointSec to load but a Windows' BSOD after it or I get the KVM crash while PointSec is loading.

The ticket I opened for this under PointSec is #1063807 because, again, Windows 7 runs fine for me.

Please don't hesitate to ask me for further info,
Rolando.

Revision history for this message
Clemens Kolbitsch (kolbitsch) wrote :

Hi Rolando,

thanks for this detailed report. Since you mention that Windows7 runs
fine for you, you gotten me really curious. Could you please post
the exact command line you are using (e.g., what additional hardware you
are emulating, etc.), the build version, the host system, etc.

I'm pretty sure that the BSOD occurs in some specific (but default)
Windows driver, because I can boot and run Win7 without problems in
safe-mode (where this specific module/driver might not be loaded or
executed). BTW, I'm emulating a 64bit Windows, same for you?

Further, I have actually traced the execution of Win7 to a point where
I even see WHY a BSOD occurs. The code executes a BOUND instruction that is
i386-only, so not available in 64bit mode. A wild guess would be that this happens
because some CPU-ID instruction returned an invalid bit at some point
causing windows to install an invalid driver or go down a wrong path.

A last question: I assume you installed Windows with KVM, right?
Because 1) without it it's just too painfully slow :) and 2) the
installer crashes for me without KVM.

Thanks!
-Clemens

Revision history for this message
zappacor (zappacor-l) wrote :

Hi Clemens,

first of all, thank you for you support!

And my comments for yours are:

>> Could you please post the exact command line you are using
The last one I issued was:
   qemu-system-x86_64 -net nic,macaddr=00:11:22:C0:FF:EE -net tap,script=qemu-ifup -m 1G -alt-grab -localtime -no-kvm -cpu kvm64,+nx $File.overlay.qcow2
Nothing out of this world, as you can see...

>> the build version, the host system, etc.
Posted this info in comment #8 above, not sure if that's enough or if you want me to gather something else though.

>> BTW, I'm emulating a 64bit Windows, same for you?
Correct, mine is Win7 Enterprise 64bits.

>> I assume you installed Windows with KVM, right?
The really tricky part from my side! :-)
And, by the way, this migth help others to get Win7 to run properly too as I think it's just the installation that gets screwed (again, mine doesn't work after PointSec installation but works fine before it)
So, what I actually did was (briefly, could forward more detailed steps):
1) created a file image (qemu-img)
2) partitioned it (fdisk)
3) NTFS formated it (mkfs.ntfs)
4) mounted it in my PC's filesystem
5) mounted a Win7 installation ISO image too
6) decompressed the .WIM installation file from that ISO image into the mounted disk image (7z)
7) unmounted everything
8) installed a MBR into the disk image (install-mbr)
9) started qemu using that image
At this point, Win7 booted, configured itself, set whatever, reconfigured, rebooted and all that kind of things it does :-)
So, finally a nice and running Win7 64bits under QEMU.
But my problems start when I install PointSec: KVM crashes with above shown dump! And, yes, TCG just always gets the BSOD.
However, taking that image into VirtualBox runs fine even after PointSec installation.

In any case, two things: first of all, lot's of thanks to all the people involved in QEMU, it's a great piece of software man!!! And second, please don't hesitate to ask me for further info, I'd really like to see it working successfully!

BR,
Rolando.

Revision history for this message
Cole Robinson (crobinso) wrote :

Just for reference, the qemu-devel thread mentioned in comment #11 is:

https://lists.gnu.org/archive/html/qemu-devel/2012-09/msg00972.html

Revision history for this message
Muelli (ubuntu-bugs-auftrags-killer) wrote :

FWIW: there is a downstream report here https://bugzilla.redhat.com/show_bug.cgi?id=785293

Changed in qemu (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Alessandro Pilotti (alexpilotti) wrote :

Hi guys, is there any update on this issue?

Tx

Revision history for this message
Eduardo Habkost (ehabkost) wrote :

Alessandro: see comment #14. If somebody can confirm that Windows 7 works with TCG when using "-cpu kvm64,+nx", I believe we can fix this in qemu64 soon, when we finally make TCG-qemu64 different from KVM-qemu64. If it still doesn't work, that means we still have the same status from comment #11 (TCG not supporting all the features required by Windows 7).

Revision history for this message
Michael Tokarev (mjt+launchpad-tls) wrote :

This prob is still present in current (2.1) qemu, and it is NOT solved by -cpu kvm64,+nx -- win bluescreens the same way.

Revision history for this message
Michael Tokarev (mjt+launchpad-tls) wrote :

I tried running qemu-system-x86 -cpu qemu64 with tcg and kvm, and compared cpu flags. There are 2 flags present in kvm case which are not present in tcg case: de and x2apic, all other flags are identical (nx is present in both). But enabling these two flags explicitly does not help, win still BSODs the same way. Except when I enable only x2apic, it displays the BSOD in much larger font... ;)

Revision history for this message
Clemens Kolbitsch (kolbitsch) wrote :

Michael, this bug cannot be solved with a reconfiguration, it's actually a TCG emulation bug. There is an experimental patch on the QEMU mailing list you should have a look at

Revision history for this message
Lope (lopeonline) wrote :

+1 also having this issue

Revision history for this message
Michael Tokarev (mjt+launchpad-tls) wrote :

I'm not sure I follow. I tried to answer to the last inquiry in this bugreport, Eduardo asked if someone can confirm that +nx solves this problem (it doesn't). Now you say with certainity that it is a bug in TCG (if it is a bug, why only uncertain guesses are present in this bugreport?), mentions some experimental patch on the mailing list without providing any details (maybe you suggest trying ALL patches with the word "experimental" in them?), and also say tha I _should_ have a look at it -- why should I? I never tried to run win7 64bit in tcg until yesterday, and yesterday I tried it just because someone reported a problem with it, pointing to this bugreport...

Thanks,

/mjt

Revision history for this message
Brendan Dolan-Gavitt (brendandg) wrote :

The initial bluescreen is caused because of unsupported CPU feature bits (the DE flag, specifically). The experimental patch Clemens mentioned is here:

http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg01412.html

Past that, however, there is a bug in QEMU's self-modifying code support that causes trouble with PatchGuard and results in a different BSOD. Patrick Hulin did some work debugging and fixing this:

http://lists.gnu.org/archive/html/qemu-devel/2014-08/msg02161.html

After that, 64-bit Windows 7 will run correctly under TCG. However it should be noted that his patch introduces other problems – e.g., running Paint Shop Pro 8.0 on Windows 7 32-bit will now crash on startup.

So there is no proper fix yet, but for some use cases these patches may suffice.

Revision history for this message
Ludovic (leyok) wrote :

Any news regarding this issue ?
I applied the first patch, but I'm unsure how to apply the second patch.
I get either DRIVER_IRQL_NOT_LESS_OR_EQUAL or KMODE_EXCEPTION_NOT_HANDLED during the Windows 7 x64 install.

Revision history for this message
Thomas Huth (th-huth) wrote :

Bug has also been reported here: https://bugs.launchpad.net/qemu/+bug/1012023

Revision history for this message
Thomas Huth (th-huth) wrote :

The patch with CPUID_DE has apparently been included here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=b6c5a6f021f485fc36
So has this issue now been fixed in the current version of QEMU?

Changed in qemu:
status: Confirmed → Incomplete
Revision history for this message
Thomas Huth (th-huth) wrote :

Since there hasn't been a reply within the last 5 months, I assume this has been fixed and thus close now this ticket accordingly.

Changed in qemu:
status: Incomplete → Fix Released
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Yeah, Assuming the commit was the fix that is released since Xenial.

Changed in qemu (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.