Windows VM's locking up the sounds cards of the host

[Mastiff]

This is driving me nuts! I have two identical Windows Server 2008 R2 hosts (one at home and one at my cabin) that runs several VM's, two of them Windows (7). I was using VMWare Player, but had the same problem there. The Windows guests will lock up three or all of the 12 sound cards in the hosts (I use four Sound Blaster Audigy cards witth the kX Drivers to get what Windows sees as three separate sound cards from each of them). It may be something with either a motherboard BIOS update or a Windows 2008 R2 update from after last summer, since I have never had this problem on any of my earlier builds, and I really can't remember having it when I set up these servers. I decided to try VirtualBox to see if that could rid me of the problem (I'm rather system agnostic, as long as it works, but the two Windows guests has to be Windows because of the programs I rund in them, and the server hosts has to be it too for the same reason).

The servers run my whole house (and whole cabin) audio system with J.River Media Center as playback for my local library and one Foobar for each zone as Internet radio players. It doesn't matter what program that I try to play with when it occurs, none of them will work. And the Windows Sound control panel app will not play a test sound either, saying that the sound card is in use by another application. The only thing I have found (I think it works, I got the idea today, and it has worked for 12 hours now) is to have an extra instance of J.River Media Center running a loop of a one hour long file which cross fades on repeat, so there's never nothing playing, with the volume turned all the way down. But this is about the ugliest band aid I've ever seen or made!

So if anbody has an idea about what this can be, or how I can find the reason, I'd much appreciate it!

[mpack]

I wish people would understand that VirtualBox is not some magical incantation. It's a perfectly normal application running on your host. It has no direct access to the hardware of your audio card, it just calls host OS APIs like any other app does (VMWare for example), and therefore if you have a problem with the sound drivers locking up then best look to the vendor of the sound card drivers!

[Mastiff]

The vendor doesn't excist. The development and support for kX died four years ago, or so. The latest version came out in 2009, but they still work on all current versions of Windows because of community support. But nobody else has heard about my problem, probably because the drivers are mostly used in home music production on a very clean setup, not with virtual machines on the same computer.

Also it's not the drivers as such, because sometimes only 3 of the 12 cards are blocked, and which three depends on which VM I'm running. I tried to go from VMWare to VB because I hoped that VB could be prevented from accessing the sound cards at all, but it seems like it has the same problem as VMWare. Even with the sound deactivated, or sett to null audio driver, it actually does access the cards. Or do you perhaps have another explanation for a sound card appearing as blocked to Windows with a virtual machine running and beeing unblocked the second that VM stops running? If VB had a switch that made it not see the sound cards, that could very well be a fix, but I haven't found any in my searches. That's why I posted here.

Another thing is of course that Windows should stop an app from blocking the card for other applications, but something in the setup (as I said probably a Windows update somewhere along the line, possibly a BIOS update, but I doubt that) messed up that. And the totally crazy way Hyper-V is using network cards (being a hypervisor Type-1, not Type-2, as VMWare and VB) makes it too difficult and annoying to migrate my system to that, since there so much else that can go haywire.

Edit: Oh, btw, I was also hoping that choosing the sound card that was used in VB would fix it, because it doesn't in VMWare, but it turned out (at least as far as I have seen) that VB can not be set up to choose between several sound cards on a host.

Edit 2: Also, no other program that I have been using (and I have a bunch of programs on the pc that uses the same sound cards, for AirPlay, Internet radio, Blu-ray playback, automation feedback and so on) creates any problems. But running a VM can lock up the cards even with nothing but Windows itself running (which I see after a while, sometimes at once, by opening the control panel applet and trying to play back the test sound).

Edit 3: As for magical incanations this has always been my favourite while working on computers, it has come in handy many times during the last 30 or so years of doing that: PC Reparo!

[andyp73]

Before you throw all of your toys out of your pram, if you want to gripe and complain about VMWare or Windows issues then you are very much in the wrong place. If you want help in getting your, unusual, configuration to work with your guests running under VirtualBox then we are going to need more information presented in a calm, measured and technical manner.

As mpack already said, as far as your guests are concerned they have a virtual audio interface which calls (in your case) the Windows 2008 R2 audio API functions which then get passed down to the audio drivers. It is possible that you could have an untested corner case, given your unusual host setup, that an API call isn't being made correctly. As an occasional Windows device driver developer, I can attest that kernel APIs and structures within the OS change - particularly of late with all the changes for Meltdown / Spectre - and so drivers that haven't been updated for 4+ years could well have problems when interacting with software that keeps up with changes to the OS.

That being said, if your guests don't need audio then disable it in the configuration. If you want any chance of anyone looking into the problem then we need a simple and repeatable test case that shows the same results.

-Andy.

[Mastiff]

Thanks, much better answer! I just mentioned VMWare because that's what I have been using up to now, and I hoped theree was enough differenc between the systems to avoid the problem by switching to VB.

Now, I think that test case is pretty much impossible to find since I am probably the only one in the world running this particular combo of OS, sounds cards (mind you, this is not limited to one specialy type of Audigy/Sound Blaster card, the first thing I tried was circulating cards between my home and cabin setup, and that didn't change anything), motherboard, CPU and applications. And if my response to the previous poster didn't seem calm, you really have not been to some of the more lively places for technical discussions on the web. Try to go into one of the overclocking boards and mention that you think one CPU is better than another CPU...

But to make it simple, I can give you my basic setup: Xeon E3-1245 V5 (V6 at home), Asus P10S-X (which is one of very few motherboards that has enough PCI slots for my use) with BIOS 3102 at the cabin and 3103 (latest) at home. Audigy and SoundBlaster cards, but the type does not matter, they all lock up in the same way. PCI-E grapics cards (ATI Radeon HD 5400), Intel Pro/1000 PT Quad Port LP Server NIC, and 32 gigs of RAM (to run VMs in memory, with as little swap file use as possible).

I can as I said run no other applications than the OS and a Windows VM, and after a varying amount of time (from at once the guest is around 50 % of the boot, not before, so I suspect that's when the guest is loading audio drivers until a few days) the audio cards will be blocked.

And finally, as I wrote, I have disabled audio in all my guests, but for some reason this still happens. Not with my two Free BSD and one Ubuntu guest, though. They can be running forever without blocking the sound card, only the Windows guests. And it doesn't matter which of my three Windows guests (I mistakenly said two in the first message, the correct is three) is running.

So is it possible that the OS in the Windows guest is the culprit, so I should do a full re-install of Windows 7? I doubt it, since I did just that a few months ago to try to fix this. But I haven't tried Windows 10 instead of Windows 7, mainly because I have a supply of 7 serials (decomissioned company computers with full lisences, not just OEM) but no Windows 10. Also I don't really like Windows 10, I wish they could have stayed on the totally perfect UI of 7 for about 50 years until I retire (I plan to retire from computers when I'm 102)!

So was that technical info enough, or is there something I have left out that should be there?

[Mastiff]

For some reason it does not really surprise me that there are no actually helpful suggestions when everything is laid out technically. So if "disable audio" in guests (which I of course already had done) is all I can get, I guess I will just have to give up fixing this and use the ugly band-aid with a looped audio file playing at all times.

[mpack]

For some reason it does not really surprise me that there are no actually helpful suggestions when everything is laid out technically.

It doesn't surprise me either that expanding on a question which has already been answered results in no more answers.

I'll remind you of the answer: nothing that VirtualBox does can cause a host OS driver to lock up, because VirtualBox is a host OS app like any other. Nothing you have said subsequently changes this answer.

[Mastiff]

I really don't give a (fill in after own taste) what you think VirtualBox can and can't do. I only care about what it actually does. 100 % reproduceable, no other possible factors fooling me. Not even a developer can know 100 % what his or her program can do accidentally in interaction with different versions and updates of OS, different hardware and other software running. So what you're saying is that andyp73 does not know what he's talking about, but you do, right? There's no possibility for this being

an untested corner case, given your unusual host setup, that an API call isn't being made correctly. As an occasional Windows device driver developer, I can attest that kernel APIs and structures within the OS change - particularly of late with all the changes for Meltdown / Spectre - and so drivers that haven't been updated for 4+ years could well have problems when interacting with software that keeps up with changes to the OS.

Me, I prefer to trust people who says "maybe" to people who says he has the gospel, and no other version can possibly be correct.

So maybe you can explain this? I ran this sequence about 20 times last weekend, with many attempts to change the setup for the sound in both Windows and VirtualBox, (no sound card, null sound, and so on) and the results were as I say 100 % reproduceable:

1. Playback works, no virtual Windows machines running. Playback is stopped. Control panel applet can play test sound.

2. Any one of the virtual Windows machines is fired up.

3. Playback does not work.Control panel applet says the sound card is busy with another application (but of course not which, that would be far too helpful).

4. Virtual Windows machine is shut down.

5. Playback and control panel applet works as normal again the second the virtual machine stops.

So if it quacks like a duck and so on...

I would think that VirtualBox (and VMWare, even if I'm not actually supposed to mention the Dark Side here, apparently), are tapping into WASAPI drivers in an ugly way, forcing exclusive mode, even when audio is not activated in the

[mpack]

I don't know how much simpler I can make this. Even if VirtualBox was full of bugs it can't do anything to the host OS, not if the host OS is any good. The host OS provides an API, and VirtualBox uses that API. If an API call causes a driver to lock up then go complain to whomever wrote the driver.

[Mastiff]

Where did I ever say that the host OS is any good? It's Windows, the world's most unsecure and buggy OS! The wacky and unexpected is like that is kind of the natural state of things. I just have to use it for this application.