Server 2008 R2 BSOD when installing viostor.sys about kvm-guest-drivers-windows

[ladipro]

This is fixed in build 126, package version 0.1.126. Drivers now declare their target OS version which, together with the way they are versioned, makes Windows choose the right one with "Search in subfolders" enabled.

[ladipro]

I have updated the Bugzilla bug:

Closing as NOATBUG because this happens only with an unsupported driver-OS combination (Win8 driver on Win7 basically). The workaround is to point Device Manager to the right directory in the ISO, for example \viostor\2k8R2\amd64 for Windows Server 2008 R2.

https://bugzilla.redhat.com/show_bug.cgi?id=1325078
tracks adding proper version information to driver .inf files so Windows will know which driver to install.

Huge thanks to everybody who reported the issue and sorry it took so long to figure out. I'll post an update when a new build with proper .inf versioning is out.

[pashadee]

What worked for me is a little easier and maybe could help someone. Also on Windows 2008 R2.

Press F8 in the console of your VM to get the "Repair your computer" prompt (along with safe mode, etc)
Chose your language, then chose the "use advanced tools" box (instead of recover), and at this point you will not have any installations listed.
Attach your virtio ISO to the VM then click Load Drivers, navigate to the dvd drive (probably D) viostor folder, 2k8R2 folder and select the INF file. After a few minutes you should have your installation show up as usual.
Click Next and user the command prompt to rename the vistor.sys file in E:\windows\system32\drivers\vistor.sys -- to something like viostor.sys.disabled then copy the file from the iso (d:\xxxx\xx\xxx\viostor.sys) to the E drive (where you just renamed the failing version).

After completing that and rebooting I was able to get back in to the system without any problems.

Hope this helps someone.

[ladipro]

@MikeKulls2 Yes, I'm with you, the ability to install mismatching drivers is definitely a bug. BTW, the fix has just been pushed to the git repo (cbb63c3 is the viostor commit) and a build should be out soon.

[andreslagarcavilla]

I was able to peek the bsod. Once I trigger the driver install it happens even in safe mode. Windows complains about the driver not being signed.

stop code is 0x7e, first 64bit value after stop code is 0xff..f800...03.

The other values seem to be relative addreses, varying with each crash cycle, for what it's worth: 0xf...ff88003684035 0xf..ff88001f73008 0xf..ff88001f72860
is one sample

[andreslagarcavilla]

Clean, straight, no bsod install when using these drivers
https://launchpad.net/kvm-guest-drivers-windows/+download
(20120712 release)

[YanVugenfirer]

Hi Vadim,

Please check this out.

Thanks,
Yan.

On Wed, Feb 20, 2013 at 3:53 AM, Andres Lagar-Cavilla <
[email protected]> wrote:

Got the following iso:
virtio-win-0.1-52.iso

and it bsods on install. The BSOD is flying by too quickly as the VM
reboots. I can see that it is viostor.sys, though.

The block device is set up as
qemu-img create -f qcow2 test.img 128M

kvm -m 1024 -cdrom virtio-win-0.1-52.iso -drive file=win2008.img,if=ide
-boot c -drive
file=test.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
-nographic -vnc :5

(the win2008.img was filled by an install from iso using ide drivers)

It is interesting that
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/ only links
a pre whql driver suite.

—
Reply to this email directly or view it on GitHubhttps://github.com/YanVugenfirer/kvm-guest-drivers-windows/issues/8.

---

Daynix Computing LTD
Yan Vugenfirer, CEO
Email: [email protected]
Phone: [phone]
Web: www.daynix.com

[MvdLande]

this version works OK
virtio-win-0.1-49.iso

[ukyg9e5r6k7gubiekd6]

We're also experiencing this, with a Windows Server 2008 R2 x64 guest and viostor.sys from virtio-win-0.1-52.iso.
None of the Windows recovery options were any help - constant BSODs. Using the recovery options to manually load viostor.sys from virtio-win-0.1-49.iso resulted in an instant BSOD at driver load (not even after a reboot). However I am not sure that Windows was using version 0.1-49 as I told it to - it would be just like Windows to disregard the sysadmin's orders and use some saved-away copy of 0.1-52. I don't know how to tell what it's doing.
Even after changing all storage from virtio to IDE, the guest still BSOD'd at boot.

It took me a while to figure out how to recover from this, so in case it helps anyone else, this is what I did:

1. Shut down the guest.
2. Mounted the partition that contains viostor.sys, which is the second partition in a disk image stored in an LVM2 VM, by getting the partition offset from fdisk, multiplying that by 512 (the sector size) to yield the start offset of 105906176, then doing: mkdir win2k8 ; sudo mount -t ntfs -o loop,offset=105906176 /dev/vgdata/win2k8 win2k8
3. Rename Windows/System32/drivers/viostor.sys to System32/drivers/disabled.viostor.sys.disabled;
4. Similarly renamed both Windows/DriverStore/FileRepository/viostor.inf_amd64_neutral_b5a4b523b42ac3b3/viostor.sys and Windows/DriverStore/FileRepository/viostor.inf_amd64_neutral_e322cb56cfbcc209/viostor.sys to disabled.viostor.sys.disabled as in step 3 (but left them in those same directories);
5. But I left Windows/LastGood/system32/DRIVERS/viostor.sys alone, because I thought Windows might actually have got it right for once, and 'LastGood' might really be the last known good version.
6. Change all storage drivers to IDE;
7. Boot up guest again and check that everything's working, which it was. Recovery seemingly complete.

Then I shut down th eguest again, changed a non-boot, non-system volume to use virtio once more, booted it back up, used "Device Manager" to forcibly install version viostor.sys 0.1-49 from the mounted ISO. That worked.

Now I'm going to attempt to change the boot/system volume(s) to use virtio again.

I'm happy to help debug this issue but I have no idea how.

[demofly]

Confirmed the BSOD in Windows 2008 R2 with 0.1-81
To rollback the problem, I booted from the LiveCD, renamed viostor.sys to random names like "viostor.sys.disabled" in:

• Windows\System32\drivers\
• Windows\System32\DriverStore\FileRepository\viostor.inf_amd64_neutral_e322cb56cfbcc209\

Booted successfully, then installed virtio drivers from ISO 0.1-49 with no issues.
http://alt.fedoraproject.org/pub/alt/virtio-win/archives/virtio-win-0.1-49/

[darkpixel]

Still occurring for me when using the drivers from virtio-win-0.1.112.iso

Subsequent reboots produce stop 0x0000005c. Turning the VM completely off and back on again will re-produce the above stop error.

[YanVugenfirer]

Thanks for the report.

Vadim will look into it.

Best regards,
Yan.

On Tue, Jan 5, 2016 at 9:21 PM, Aaron C. de Bruyn [email protected]
wrote:

Still occurring for me when using the drivers from virtio-win-0.1.112.iso

[image: win2k8r2-bsod]
https://cloud.githubusercontent.com/assets/158380/12125130/6f02ab22-b39e-11e5-813f-cd3dc2d06cb4.png

—
Reply to this email directly or view it on GitHub
https://github.com/YanVugenfirer/kvm-guest-drivers-windows/issues/8#issuecomment-169103032
.

---

Daynix Computing LTD
Yan Vugenfirer, CEO
Email: [email protected]
Phone (Israel): [phone]
Phone (USA): [phone]
Phone (UK): [phone]
Web: www.daynix.com

[vrozenfe]

STOP 0x0000005C (0x0000010B,0x00000003,0x00000000,0x00000000) during reboot is a known problem. Should be fixed in the recent kvm releases.
STOP 0x0000007E (0x80000003,..) is a weird one. Exception code 0x80000003 means STATUS_BREAKPOINT which indicates that a hard-coded breakpoint or assertion was hit, but the system was started with the /NODEBUG switch. Does it happen during a fresh install, or after viostor
driver update?

[darkpixel]

My installs are done using IDE, then we flip the 'data' drive to virtio, install the driver, reboot, and finally switch the system drive to virtio, install the driver and reboot. I've been installing 8-10 new systems per year, and it's only been in the last few months that installing the virtio driver causes the bluescreen. It happens when I install it for the data drive. I can't install it to the system drive because the box stops booting--even when I switch the drive back to IDE. I have to mount the image and find 'virtio' under the Windows folder and delete them, then the box will boot.

[vrozenfe]

Would you mind opening a new bug on this issue at bugzilla.redhat.com assigned to "Community", "Virtualization Tools", "virtio-win"?

Thank you,
Vadim.

[darkpixel]

Filed: https://bugzilla.redhat.com/show_bug.cgi?id=1296633

I can't change the bug assignment.

[vrozenfe]

Done.
Best regards,
Vadim.

[MikeKulls2]

I still get this issue. If I add a disk as virtio, windows asks for drivers, I provide drivers and it bluescreens while installing them. I am using a much newer version than mentioned in the original post so I would have thought this would be resolved now. CD is virtio-win-0.1.102.iso and the version of viostor.sys is 62.72.104.10200. Perhaps it is something I am doing wrong?

[MikeKulls2]

[vrozenfe]

We will need a bit more information from you:

• qemu command line;
• qemu and kvm versions;
• output from Windows systeminfo utility.

Thanks,
Vadim.

[MikeKulls2]

We have 2 servers where we are getting the issue, one running redhat 6.4 and another on redhat 7.2. Data below is for the 6.4 server but we still get the same issue running the 7.2

I didn't setup this system and am no KVM expert. Can I get the qemu command line from "ps -ef | grep qemu"? If so this is it:

qemu 24664 1 99 08:51 ? 12:21:09 /usr/libexec/qemu-kvm -name cws-QV1 -S -M rhel6.6.0 -cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -enable-kvm -m 200000 -realtime mlock=off -smp 32,sockets=2,cores=16,threads=1 -uuid ea794c0c-2f56-9eae-1859-98be632e44df -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/cws-QV1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/kvm/cws-QV1/SAD_SOE_W2008-R2-ENT-x64.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/var/lib/libvirt/images/cws-QV1.img,if=none,id=drive-ide0-0-1,format=qcow2,cache=none -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/var/lib/libvirt/images/cws-QV1-2.img,if=none,id=drive-ide0-1-0,format=raw,cache=none -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/var/lib/libvirt/images/cws-QV1-1.img,if=none,id=drive-ide0-1-1,format=qcow2,cache=none -device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=23,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:81:1e:c7,bus=pci.0,addr=0x3 -netdev tap,fd=24,id=hostnet1,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:8f:39:e5,bus=pci.0,addr=0x4 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x5 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on

Does this give you the version of qemu/kvm?
qemu-img.x86_64 2:0.12.1.2-2.448.el6_6 @rhel-6.4-updates
qemu-kvm.x86_64 2:0.12.1.2-2.448.el6_6 @rhel-6.4-updates

System info here:
systeminfo.txt

[vrozenfe]

Thanks,
Using ps command is fine, but we need the command line of the crashing VM.
You mentioned that both virtio-blk device and viostor device driver were added/installed,
but I don't see virtio-blk-pci device in the provided command line.

[MikeKulls2]

I believe that is the correct command line. The VM doesn't have a virtio device at the moment because that causes it to crash and staff are relying on the box. When it was created it was created with default settings in virt-manager

[vrozenfe]

I see, and what happens after reboot? Does VM still crash with BSOD or crash dump file can be created successfully?
Thanks.
Vadim.

[MikeKulls2]

If I reboot the machine with the virtio installed then it will crash again during boot. I think even if I remove the virtio disk then it will still crash. I need to use recovery console to delete the file viostor.sys as mentioned by someone above.

[vrozenfe]

Thanks,
I will try to reproduce and analyze this problem during the week. Do you have access to
the production virtio-win drivers package, available through RH network channels? If yes,
can you please give them a try?
Vadim.

[MikeKulls2]

We should have access, I will look into it.

[vrozenfe]

Feel free to ping me off-line at [email protected], if you don't have it.

[mkudlacek]

I have the same issue.

ISO version 0.1.113
KVM/QEMU version: 1:2.1+dfsg-12+deb8u5a
Hypervisor: Debian 8.3 Jessie, fully updated
Guest: Windows Server 2008 R2

[crpb]

After an upgrade from Debian Squeeze to Wheezy. The Perfomance with IDE-Drivers was terrible.
And after a bunch of Tests with virtio-driver-versions i got lucky with the virtio-win-0.1-49.iso.
Let's see what an upgrade to jessie will bring :-).

[MikeKulls2]

We solved this problem by migrating to VMWare. I'm hearing lots of good things about KVM but I just don't think it's there yet. Having this issue running over 3 years with no fix doesn't fill me with confidence and I need confidence in my hyper-visor.

[ladipro]

Which directory in the virtio-win iso are you guys installing the driver from? I can repro this by installing the Win8 or Win2012 version of the driver in a Win7 or Win2008R2 VM and it appears to be crashing by design (as stupid as it sounds).

Drivers built for Win8 and newer expect certain security related information to be set by the OS at load time. If the OS doesn't set it because it's not aware of the new feature, they crash. So it is absolutely critical to always match the driver version to the guest OS version.

[MikeKulls2]

Thanks ladipro, I don't have the environment setup any longer. I'm 99% sure we had the correct driver as the directory is 2k8R2. Maybe the automatic features of windows is doing something though? Once you've installed the wrong driver is it possible to then go an install the correct one or does it keep crashing. Our KVM install exists on 3 disks which we might need to boot up to retrieve some data so I will take a look.

With regards to the crashing by design, that is not a good design and should be rectified. I was under the impression it wasn't that difficult to stop a driver being installed on the wrong OS. Isn't it just a matter of editing the inf file?

[vrozenfe]

You can try switching disk type from virtio to ide and see if it works, but it probably will not without changing StartType for virtio storage driver from 0 (Boot start) to 3 in the Registry. It can be done off-line with libguestfs. Otherwise you can try doing it on-line, booting the system into safe mode.
But if you only need to back up some data without running the image itself, you can mount that disk
as a secondary drive on any Windows VM, and it should work.

Regarding to stopping a driver on the wrong OS. Unfortunately it is not as simple. The crash itself happens even before stepping into our own code. Technically, Win7 drivers should run fine on Win7, Win8 and Win10 platforms. This scenario should be supported. What is not supported is building a driver for a later platform and then running it on an earlier platform.

[MikeKulls2]

We never had the boot disk set to virtio. It was always a fresh disk that we added as virtio. If we change it to IDE or remove that disk then it boots ok.

The blue screen I posted above would indicate it has crashed while running code inside viostor.sys

[ladipro]

@MikeKulls2 Agreed that the driver should gracefully fail to install on unsupported OSes. Unfortunately Windows ignores the minimum OS version field in .sys PE header and the .inf also doesn't seem to offer anything that would help here.

For the crash itself, I am pretty sure that your system had the Win8 driver on it. In your screenshot the driver timestamp is 54FF40E8 which is Tue Mar 10 20:07:20 CET 2015 and exactly matches the Win8 build of viostor.sys in version 102. The correct one would have been 54FF42DE.

Same for the BSOD screenshot posted by @darkpixel. Timestamp 5670FFC6 is the Win8 build of 112 viostor.sys. The correct one would have been 56710177.

If the incorrect directory wasn't selected when installing from the ISO, one theory explaining this could be that Windows downloaded the wrong driver from Windows Update. I believe that we've seen virtio-win drivers coming from WU before, @vrozenfe knows more.

[mkudlacek]

@ladipro Your point about Windows picking up a wrong driver from ISO seems to be correct. I don't want to jinx it, but I tried this scenario and it works:

1. A preinstalled Windows Server 2008 R2 in VMWare, image is RAW file
2. Created virtual machine in KVM, image connected by IDE controller (hda)
3. Virtual machine starts fine
4. Created small QCOW2 image and connected it by VIRTIO controller (vda)
5. Virtual machine starts OK, drive cannot be seen because of missing drivers
6. I specifically copied from 0.1.113 ISO only the folder viostor/2k8R2 to desktop and pointed driver installer to this folder
7. Installation of driver went fine a I was able to access the drive immediately
8. Shutdown of the machine, reconfiguration of RAW image with C: drive to connect by VIRTIO controller (as vda, the small QCOW2 moved to vdb)
9. Boot went fine, no issues

So the driver version for Red Hat VirtIO SCSI controller is 60.73.104.11300 (2/3/2016)

I don't remember exactly, but it is possible, that the first time I tried this I pointed the driver installer to whole ISO and checked the "Search in subfolders" option. That could lead to Windows to pick up a driver for Windows 8...

[vrozenfe]

I'm fully agree with Ladi - it was Win8 driver from build 102
0:000> lmi viostor
start end module name
0000000140000000 000000014000b000 viostor (private pdb symbols) viostor.sys
Symbol file: z:\xru\viostor.pdb
Mapped memory image file: z:\xru\viostor.sys
Image path: Z:\xru\viostor.sys
Image name: viostor.sys
Timestamp: Wed Mar 11 06:07:20 2015 (54FF40E8)
CheckSum: 0000E36E
ImageSize: 0000B000
File version: 62.72.104.10200
Product version: 62.72.104.10200
File flags: 8 (Mask 3F) Private
File OS: 40004 NT Win32
File type: 3.7 Driver
File date: 00000000.00000000
Translations: 0000.04b0
CompanyName: Red Hat, Inc.
ProductName: Red Hat VirtIO SCSI controller
InternalName: viostor.sys
OriginalFilename: viostor.sys
ProductVersion: 62.72.104.10200
FileVersion: 62.72.104.10200 <<<<< 62 means that the target kernel is 6.2
FileDescription: Red Hat VirtIO SCSI driver
LegalCopyright: Copyright (C) 2008-2015 Red Hat, Inc.

The crash itself ( viostor!__security_cookie + 2d happens due stepping into int 3 with no WinDbg attached):
viostor!__security_init_cookie [d:\wbrtm\minkernel\tools\gs_support\kmodefastfail\gs_support.c @ 36]:
36 0000000140008000 488b05f9dfffff mov rax,qword ptr [viostor!__security_cookie (0000000140006000)]
43 0000000140008007 4885c0 test rax,rax 43 000000014000800a 741a je viostor!__security_init_cookie+0x26 (00000001`40008026)

viostor!__security_init_cookie+0xc [d:\wbrtm\minkernel\tools\gs_support\kmodefastfail\gs_support.c @ 43]:
43 000000014000800c 48b932a2df2d992b0000 mov rcx,2B992DDFA232h 43 0000000140008016 483bc1 cmp rax,rcx
43 0000000140008019 740b je viostor!__security_init_cookie+0x26 (0000000140008026)

viostor!__security_init_cookie+0x1b [d:\wbrtm\minkernel\tools\gs_support\kmodefastfail\gs_support.c @ 48]:
48 000000014000801b 48f7d0 not rax 48 000000014000801e 488905e3dfffff mov qword ptr [viostor!__security_cookie_complement (0000000140006008)],rax 49 0000000140008025 c3 ret

viostor!__security_init_cookie+0x26 [d:\wbrtm\minkernel\tools\gs_support\kmodefastfail\gs_support.c @ 45]:
45 0000000140008026 b906000000 mov ecx,6 45 000000014000802b cd29 int 29h
00000001`4000802d cc int 3

It is a Win8 code which is different from Win7
0:000> uf viostor!__security_init_cookie
viostor!__security_init_cookie [d:\5359\minkernel\tools\gs_support\kmode\gs_support.c @ 58]:
58 0000000000018008 488b05f1e0ffff mov rax,qword ptr [viostor!__security_cookie (0000000000016100)]
60 000000000001800f 48ba32a2df2d992b0000 mov rdx,2B992DDFA232h 60 0000000000018019 4885c0 test rax,rax
60 000000000001801c 7405 je viostor!__security_init_cookie+0x1b (0000000000018023)

viostor!__security_init_cookie+0x16 [d:\5359\minkernel\tools\gs_support\kmode\gs_support.c @ 60]:
60 000000000001801e 483bc2 cmp rax,rdx 60 0000000000018021 752f jne viostor!__security_init_cookie+0x4a (00000000`00018052)

viostor!__security_init_cookie+0x1b [d:\5359\minkernel\tools\gs_support\kmode\gs_support.c @ 71]:
71 0000000000018023 488d0dd6e0ffff lea rcx,[viostor!__security_cookie (0000000000016100)]
71 000000000001802a 48b82003000080f7ffff mov rax,0FFFFF78000000320h 71 0000000000018034 488b00 mov rax,qword ptr [rax]
71 0000000000018037 4833c1 xor rax,rcx 71 000000000001803a 48b9ffffffffffff0000 mov rcx,0FFFFFFFFFFFFh
71 0000000000018044 4823c1 and rax,rcx 76 0000000000018047 480f44c2 cmove rax,rdx
76 000000000001804b 488905aee0ffff mov qword ptr [viostor!__security_cookie (0000000000016100)],rax

viostor!__security_init_cookie+0x4a [d:\5359\minkernel\tools\gs_support\kmode\gs_support.c @ 81]:
81 0000000000018052 48f7d0 not rax 81 0000000000018055 488905ace0ffff mov qword ptr [viostor!__security_cookie_complement (0000000000016108)],rax 82 000000000001805c c3 ret

Which seems like Microsoft has a some sort of ASSERT code in release Win8 build.

The moral of this story is simple - use the right drivers :)

Best regards,
Vadim.

[ladipro]

I take back my comment about the .inf files though. It looks like TargetOSVersion is exactly what we're looking for:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff547454(v=vs.85).aspx

And we should use it because expecting Windows to automatically figure out what to install when pointed to the root of the ISO is perfectly reasonable, I think.

[darkpixel]

That sounds correct. When loading the virtio drivers from within Windows, I usually specify the path of the CD and Windows then automatically searches for the driver in all subfolders. If TargetOSVersion isn't set, my guess is it picks one (sorta randomly) and uses it. I assumed it always found the correct one.

[Retrofreak]

Argh, its nearly 3.am here, and I'm glad to discover this thread. I have to do a host-change for a charity. Just low costs and so on. So their servers run on a qemu/kvm/libvirt host and since 15 hours I get infrequent bluescreens within the 2008R2 terminalserver. Why did I say "Yes, I can - no its not so expensive as the vm-ware guys told you, no - no problem, we just simply do it using libvirt... No problem - maximum one day to transfer all servers to the new machine..." - Why?... (BTW the server was indeed expensive - 32 core Xeon, 4TB SSD raid) But after reading this thread, and after trying every combination of virtio-drivers etc, I finally installed "4.6.0-0.bpo.1-amd64 #1 SMP Debian 4.6.3-1~bpo8+1" Kernel in Debian-Jessie (which is the servers host system). OMG it seems to run now. Thanks again. Seems that simply the debian-default-Jessie 3.x Kernel is a bit buggy at this point. Perhaps I should look around for other distributions... But how to find out in advance. Now beer and bed.

[hammerg]

You should try to use RHEL or CentOS. The Windows drivers are tested and stabilized against these distributions.

[MikeKulls2]

ladipro, I am not sure I would describe this as not a bug. First it shouldn't be possible to install the wrong drivers if this is the result. Second, there doesn't appear to be a way to get rid of the drivers once they are installed. I tried pointing to the correct directly many many times and it just blue screens again.

[Retrofreak]

@hammerg seems you are right. I am a sick debian fan since lots of years, but after the latest experiences with Jessie (systemd, inittab and now the unbelievable horrortrip regarding libvirt) I think I'll give Red Hat respectively CentOS another try. I am running lots of servers on wheezy base and I have had nearly never problems like this. But I thought, it's time to switch to the next LTS version.
@MikeKulls2 yes, I tried lots of combinations and I am sure I pointed to the correct driver files. The reason was not the driver - it was the host machines kernel.

[mkudlacek]

@Retrofreak I'm running KVM on up-to-date Debian Jessie (kernel 3.6.17-ckt20-1+deb8u4). Never ran into BSOD since I installed the correct VirtIO drivers.

[Retrofreak]

@mkudlacek the mystery is: It runs here too, on 5 VM's without any problems. But the 6th VM crashes. This VM is special, because its a 2008R2 Terminalserver with 24GiB RAM and lots of CPU Cores. When I use the backports kernel (4.6.0-0.bpo.1-amd64 #1 SMP Debian 4.6.3-1~bpo8+1) everything works fine.

[MikeKulls2]

@Retrofreak we had a VM crashing with when we allocated it more 256GB of ram but this turned out to be a windows issue.

[gwes]

Hi All,

I just wanted to add that I am seeing the same issue.

When allowing windows 7 pro 64bit to search from the root of the CD it finds the wrong driver but installs and then blue screens.

Removing the files refereed to above by @pashadee allows the system to boot again.

Forcing windows to look in the win7 folder allowed the driver to be loaded correctly and the system seems (so far) to be stable.

If you are trying to convert your system/boot disk to virtio for performance then the method of adding an additional disk as virtio, installing the driver, reboot, shutdown, remove second disk, chance system disk to virtio, boot. does seem to have worked for me.