Windows 10 guest crashing regularly

[andyp73]

Any Thoughts?

Dull and boring as it will be, I think you need to incrementally add the GA and the software installed in the original guest and see if there is one in particular that causes it to fail. Sadly, you may just find it is "one of those Windows things".

-Andy.

[TechJack3]

Thanks for the response Andyp73! Suppose this is a good time to make a snapshot of the current new install so i'll be able to go back to it in the future? I figure i'll make a snapshot incrementally as I do as you recommend after each software install. Its only 5 programs that I need to run. What are your thoughts on the procedure?

[socratis]

Suppose this is a good time to make a snapshot of the current new install so i'll be able to go back to it in the future?

Yes, but don't overdo it. Take a snapshot, install a piece of software, test it out. If it works "merge" the snapshot. Take a new one, install another piece of software. And so on and so forth...

[TechJack3]

I didnt get a chance to install any software on the new vm but I ran a little test on the one that was giving me problems. I may have found the culprit. While installing the OS on the new vm, I uninstalled guest addidtions on the old vm, ran it for a while with the usual programs then it crashed after some time.I then ran it with my vpn client only for sometime (2 plus days) and no crashes. I then launched a program called deluge while still running the vpn program and it hung on a BSOD after i believe 6 hours. So with running only those two programs I get a BSOD. I think its deluge. I have attached the log of the last crash (BSOD). I hope you see something in there to validate this claim. In the meanwhile I will run the test again with only those two programs and see if I get a recurring BSOD.
Thanks!

[socratis]

41:35:50.866755 GIM: HyperV: Guest indicates a fatal condition! P0=0xa P1=0x20 P2=0x2 P3=0x0 P4=0xfffff8007dd8a245
41:35:50.880176 GIMHv: BugCheck a {20, 2, 0, fffff8007dd8a245}
41:35:50.880179 IRQL_NOT_LESS_OR_EQUAL
41:35:50.880179 P1: 0000000000000020 - memory referenced
41:35:50.880179 P2: 0000000000000002 - IRQL
41:35:50.880180 P3: 0000000000000000 - bitfield
41:35:50.880180     b0: 0 - read operation
41:35:50.880180     b3: 0 - execute operation
41:35:50.880181 P4: fffff8007dd8a245 - EIP/RIP

You get a BSOD all right, an IRQL_NOT_LESS_OR_EQUAL one. Not sure how VirtualBox gets involved to tell you the truth. Just because an OS/program that runs in the context of VirtualBox has a problem, it doesn't make it a VirtualBox problem necessarily. You're having an issue that has most probably nothing to do with VirtualBox, so my suggestion would be to treat it as such, as a native problem with the OS or the application of the guest.

[TechJack3]

To explain where I came to believe that it was a virtualbox problem I have to start at the beginning. I had a Windows 10 vm with the same programs running on it, run on hyper-v. I then switched hosts for better processing power but due to the new processor not supporting slat I ran virtualbox instead as it seemed as feature rich and compatible with my new setup. I initially converted the vhdx to a vhd to import into virtualbox and that machine kept blue screening/ crashing. I got fed up and decided to start all over with a new vm which is the vm i'm working on in this thread hence the 2.0 in the vm name. So in my inexperience with virtualbox, I defaulted with virtualbox having an issue since the last host was stable as well as the vm. The current host has been and still is stable ( I've owned it for as number of years).

BTW- The vm is still running as a test to see if just running those 2 programs from the previous test will cause a BSOD again.

[socratis]

Just to make it clear. It *could* be a VirtualBox bad interaction. But those are really rare, and if they're reproducible (new VM, just this app), then you should head to the bug tracker and either search for an appropriate bug, or open a new bug report where you'll attach your logs and other vital information.

[TechJack3]

Was reading some of the virtual machine logs and noticed "Audio: Device configuration of driver 'DSoundAudio' has changed" is at the end of all the logs before the machine either freezes or has a BSOD. I tried to do a search but didnt come up with much. Might this have to do with my system crashing? This is the log from the last freeze. The VM ran for 34 ish hours.

[socratis]

Funny that I had a conversation over at the IRC with a Win10 user that reported the same (or really close) thing. I'm waiting for the logs, because they mentioned a 48h run time (more or less) until that freeze happens!

Ping me in a day or two to see what's going on. Obviously this is not easily reproducible, to say the least...

[socratis]

UPDATE
The user from IRC (jacky_ZZzz) reported that with build 6.0.5 r128999 (from the Test Builds) there was success, as in not crashing the whole VM, simply all the audio-related apps. Saving the state and restoring it (live), re-enabled the VM to continue play the sounds/video.

Saving a live state is somewhat problematic in 6.0.x, so I won't be suggesting it, it's what worked in that particular case. Something that the developers might find helpful...

[jack_thompson]

I can reproduce the problem at will now (r128999, Host: Win10(64), Guest: Linux)

1. Start video playback in VM.
2. Enter "Sound" in Cortana and select "Manage Audio Devices"
3. Enable or disable any device
4. Immediately the sound buffer will start repeating and the virtual soundcard will not pass any further packages stalling video playback

What is good about r128999 is that the virtualization wont crash completely. I can just create a save state - restart and it will continue as if nothing happened... for a while.

This problem happens also spontaneously when watching videos. In releases other than r128999 (but also in r128999 but not as reliable) it will show 3-4 "Host audio configuration has changed" events all of a sudden (see OP's log) with the same result as 4) (above) - much earlier releases than r128999 will crash then (including the frontend).

So actual changes of audio devices and alleged changes of audio devices seem to "clog up" audio buffers until restart (with save state or not) and stall playback.

Except r128999 I only tried a year old version that used to work best for me... until it didn't. The moment it crashed I had repeated and wrong "Host audio configuration has changed" events in the log (exactly like in the log by OP).

With r128999 i have these wrong "Host audio configuration has changed" events not reliably showing in the log. But the result is the same... audio (the virtual soundcard?) stops working and stalls playback of media containing audio until restart. When i disable the playback of audio in the media player (regardless if it is mpv or vlc) it plays the video fine.

Two problems:

1. receiving events about changing hosts audio devices breaks audio playback until restart.
2. like 1) but the events are fake/wrong/non-existant.

Is there a necessity to even care about these (wrong) events?

[jack_thompson]

Just tried it and same problem exists in r128413.

Real and fake Audio-device-change-events stall audio.

Though both versions don't show these events in their logs anymore.

So here is a log of the 1 year old version that worked best (until it didn't). It shows the same fake events like OPs

EDIT: uploaded

[socratis]

@jack_thompson
Please attach the logs here, locally, ZIPPED.

[jack_thompson]

Okay. Here is a verbose audiodebug log.

I did

- Start video playback in VM.
- Enter "Sound" in Cortana and select "Manage Audio Devices"
- Enable or disable any device
- Sound buffer started repeating and I closed the VM.

Code: Select all

00:01:48.313573 Audio: Device '{0.0.0.00000000}.{630bca04-06d0-42c6-acec-d8464ae0f3b2}' has changed 
                    state to 'unplugged'
00:01:48.313610 Audio: Device configuration of driver 'DSoundAudio' has changed

I guess that is the moment where i send an event using "Manage Audio Devices"
The audiobuffer keeps repeating and stalls all media playback in the vm.

[jack_thompson]

Looks like I found a work-around for the issue.

I have two physical audio devices:

- Soundcard
- HDMI digital audio

The soundcard isn't used in any way. So I just disabled it completely in the "Device Manager".

Now Windows ceased to randomly spam VirtualBox with "Host has changed audio config" events and video playback has been stable ever since.

Apparently (my assumption) Windows does renumber unused devices now and then?

When I manually disabled devices in "Manage Audio Devices" it would renumber devices too and cause crashes.

I am using only the HDMI audio output now. The soundcard is disabled. Everything works.

Other end-users might still run into this issue though until it gets fixed.