Crash on pause

[fth0]

First of all, thank you for trying several configurations, and also for the additional information regarding the 2nd user account (I'm not decided yet if it is relevant or not).

The new logs show the same behavior as the old ones, maybe because you didn't try the configuration I asked for. I'll try and explain my following statements a little bit more in detail:

If you enable audio input in the VM configurations, do the error messages and the crashes persist?
[...]
Additionally, I noticed that audio input was enabled in the Ubuntu guest and disabled in the Windows XP guest. This combination may very well be the key to reproduce the crashes ...

There are at least three participants in the audio setup: (1) The host OS audio setup (e.g. dsound.dll) typically has both audio input and output enabled (possibly muted). (2) The Virtual Machine Manager (VMM) either attaches to the host audio or not (e.g. Host Audio Driver set to Null Audio Driver), and additionally provides a virtual Audio Controller with the input and/or output path to the guest OS. (3) The guest OS then uses the virtual Audio Controller.

Several messages in the VBox.log files indicate problems in the audio input path, which is enabled between (1) and (2), and disabled between (2) and (3). Since you probably don't want to remove the audio input devices from (1), I suggested to enable audio input between (2) and (3). Another useful test would be to try the Null Audio Driver.

[hakster]

So in the last few months, I have been experiencing something similar. Windows 10 Host 1909 and VirtualBox 6.1.2. A single VM, running Ubuntu 18.04. All are kept up to date, and this problem started a few months back - not sure if an update to one of the above was the cause.

Issue: After Windows 10 Host suspends and then goes to hibernate, upon resume, the VM is either in "Aborted" or paused and won't come back. Process needs to be killed before it can restart.
I've provided logs below, and beyond my depth but sound seems a factor. For testing, I've unticked "Enable Audio" under the VM properties. Is there anything else I can do? I'll report back to see if that makes a difference or not. I personally don't need audio in my VM, but this used to work, so is not a solution, but might be a workaround perhaps for some.


2 types of failure, both logs below.

06:04:34.187580 Audio: Device configuration of driver 'DSoundAudio' has changed
08:24:48.644720 Audio: Device configuration of driver 'DSoundAudio' has changed
08:24:49.384754 Audio: Device configuration of driver 'DSoundAudio' has changed
08:24:50.179587 Pausing VM execution, reason 'host suspend'
08:24:50.182903 Changing the VM state from 'RUNNING' to 'SUSPENDING'
08:24:50.202164 AIOMgr: Endpoint for file 'C:\Users\XXXXXXX\VirtualBox VMs\Mint 19.1\Mint 19.vdi' (flags 000c0781) created successfully
08:24:50.222785 DSound: Stopping capture buffer failed with ERROR_CALL_NOT_IMPLEMENTED 0x88780078
08:24:50.308974 PDMR3Suspend: 125 512 253 ns run time
08:24:50.309001 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
08:24:50.309021 Console: Machine state changed to 'Paused'
23:18:03.898998 Resuming VM execution, reason 'host resume'
23:18:03.899929 Changing the VM state from 'SUSPENDED' to 'RESUMING'
23:18:03.904302 AIOMgr: Endpoint for file 'C:\Users\XXXXXXX\VirtualBox VMs\Mint 19.1\Mint 19.vdi' (flags 000c0723) created successfully
23:18:03.909560 DSound: Starting to capture failed with ERROR_CALL_NOT_IMPLEMENTED 0x88780078


Other times, it looks like this:

03:01:11.853833 Pausing VM execution, reason 'host suspend'
03:01:11.853936 Changing the VM state from 'RUNNING' to 'SUSPENDING'
03:01:11.865942 AIOMgr: Endpoint for file 'C:\Users\XXXXXX\VirtualBox VMs\Mint 19.1\Mint 19.vdi' (flags 000c0781) created successfully
03:01:11.870605
03:01:11.870607 !!! rtR3WinUnhandledXcptFilter caught an exception on thread 00000000000061c4!!!
03:01:11.870632
03:01:11.870632 ExceptionCode=0xc0000005 ExceptionFlags=0x00000000 ExceptionAddress=00007ffeabe88201
03:01:11.870645 ExceptionInformation[0]=0000000000000001
03:01:11.870654 ExceptionInformation[1]=0000000000000021
03:01:11.870663
03:01:11.870663 cs:rip=0033:00007ffeabe88201
03:01:11.870674 ss:rsp=002b:000000000943f240 rbp=00000000077187b0
03:01:11.870683 rax=0000000000000000 rcx=89854fcf43ac0000 rdx=0000000000000000 rbx=0000000008cf34d8
03:01:11.870693 rsi=0000000000000001 rdi=0000000000000021 rsp=000000000943f240 rbp=00000000077187b0
03:01:11.870703 r8 =000000000943eef8 r9 =00000000077187b0 r10=0000000000000000 r11=000000000943f1d0
03:01:11.870712 r12=0000000000000004 r13=000000000943f460 r14=0000000df8475800 r15=0000000000000000
03:01:11.870721 ds=002b es=002b fs=0053 gs=002b eflags=00010206
03:01:11.870731 p1home=0000000000000034 p2home=0000000002080068 pe3home=0000000008cf34d8
03:01:11.870740 p4home=0000000300000104 p5home=0000000000000000 pe6home=0000000000000000
03:01:11.870749 LastBranchToRip=0000000000000000 LastBranchFromRip=0000000000000000
03:01:11.870758 LastExceptionToRip=0000000000000000 LastExceptionFromRip=0000000000000000
03:01:11.870770
03:01:11.870771 Stack 000000000943e140, dumping 0x1ec0 bytes (low=0000000009240000, high=0000000009440000)
03:01:11.870785 000000000943e140/0000: 40 e1 43 09 00 00 00 00-73 74 61 63 6b 6d 61 72 @.C.....stackmar
03:01:11.871886 000000000943e150/0010: 6b 65 72 00 00 00 00 00-00 10 02 00 00 00 00 00 ker.............
03:01:11.871893 000000000943e160/0020: 00 00 00 00 00 00 00 00-50 b7 86 e2 fe 7f 00 00 ........P.......

[ueli]

Several messages in the VBox.log files indicate problems in the audio input path, which is enabled between (1) and (2), and disabled between (2) and (3). Since you probably don't want to remove the audio input devices from (1), I suggested to enable audio input between (2) and (3). Another useful test would be to try the Null Audio Driver.

Here are logs after a crash of the Ubuntu guest with audio in=enabled, out=disabled.
After this, I have changed the audio driver to null and started the guest again. Let's see what happens. I'll post again when I know more about this.

[fth0]

VirtualBox VM 4.3.34 r104062 win.amd64 (Nov 10 2015 21:11:55) release log
00:00:04.248304 Log opened 2016-07-25T15:47:17.966488500Z

Somehow I don't think you've posted the log files you wanted to post.

[ueli]

I'm very sorry, not only because of the mistake, but also because the logs I intended to post are now lost. They have been overwritten by the currently running guest, which uses the audio null driver.
So I'm going to keep this one running for a while. If it crashes some day, I'll post its logs. If it runs without crashing for a few days, I'll stop it and restart with the standard audio driver.

[fth0]

If it crashes some day, I'll post its logs.

Please post the logs also, if the guest does not crash. They might indicate that some of our observations are irrelevant.

[hakster]

Update for my issue below - after several days/tests, disabling Audio in VirtualBox VM properties for the Linux guest VM has prevented the VM freezing or aborting after the Windows host wakes up from sleep and/or hibernate. Hope that helps.

So in the last few months, I have been experiencing something similar. Windows 10 Host 1909 and VirtualBox 6.1.2. A single VM, running Ubuntu 18.04. All are kept up to date, and this problem started a few months back - not sure if an update to one of the above was the cause.

Issue: After Windows 10 Host suspends and then goes to hibernate, upon resume, the VM is either in "Aborted" or paused and won't come back. Process needs to be killed before it can restart.
I've provided logs below, and beyond my depth but sound seems a factor. For testing, I've unticked "Enable Audio" under the VM properties. Is there anything else I can do? I'll report back to see if that makes a difference or not. I personally don't need audio in my VM, but this used to work, so is not a solution, but might be a workaround perhaps for some.


2 types of failure, both logs below.

06:04:34.187580 Audio: Device configuration of driver 'DSoundAudio' has changed
08:24:48.644720 Audio: Device configuration of driver 'DSoundAudio' has changed
08:24:49.384754 Audio: Device configuration of driver 'DSoundAudio' has changed
08:24:50.179587 Pausing VM execution, reason 'host suspend'
08:24:50.182903 Changing the VM state from 'RUNNING' to 'SUSPENDING'
08:24:50.202164 AIOMgr: Endpoint for file 'C:\Users\XXXXXXX\VirtualBox VMs\Mint 19.1\Mint 19.vdi' (flags 000c0781) created successfully
08:24:50.222785 DSound: Stopping capture buffer failed with ERROR_CALL_NOT_IMPLEMENTED 0x88780078
08:24:50.308974 PDMR3Suspend: 125 512 253 ns run time
08:24:50.309001 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
08:24:50.309021 Console: Machine state changed to 'Paused'
23:18:03.898998 Resuming VM execution, reason 'host resume'
23:18:03.899929 Changing the VM state from 'SUSPENDED' to 'RESUMING'
23:18:03.904302 AIOMgr: Endpoint for file 'C:\Users\XXXXXXX\VirtualBox VMs\Mint 19.1\Mint 19.vdi' (flags 000c0723) created successfully
23:18:03.909560 DSound: Starting to capture failed with ERROR_CALL_NOT_IMPLEMENTED 0x88780078


Other times, it looks like this:

03:01:11.853833 Pausing VM execution, reason 'host suspend'
03:01:11.853936 Changing the VM state from 'RUNNING' to 'SUSPENDING'
03:01:11.865942 AIOMgr: Endpoint for file 'C:\Users\XXXXXX\VirtualBox VMs\Mint 19.1\Mint 19.vdi' (flags 000c0781) created successfully
03:01:11.870605
03:01:11.870607 !!! rtR3WinUnhandledXcptFilter caught an exception on thread 00000000000061c4!!!
03:01:11.870632
03:01:11.870632 ExceptionCode=0xc0000005 ExceptionFlags=0x00000000 ExceptionAddress=00007ffeabe88201
03:01:11.870645 ExceptionInformation[0]=0000000000000001
03:01:11.870654 ExceptionInformation[1]=0000000000000021
03:01:11.870663
03:01:11.870663 cs:rip=0033:00007ffeabe88201
03:01:11.870674 ss:rsp=002b:000000000943f240 rbp=00000000077187b0
03:01:11.870683 rax=0000000000000000 rcx=89854fcf43ac0000 rdx=0000000000000000 rbx=0000000008cf34d8
03:01:11.870693 rsi=0000000000000001 rdi=0000000000000021 rsp=000000000943f240 rbp=00000000077187b0
03:01:11.870703 r8 =000000000943eef8 r9 =00000000077187b0 r10=0000000000000000 r11=000000000943f1d0
03:01:11.870712 r12=0000000000000004 r13=000000000943f460 r14=0000000df8475800 r15=0000000000000000
03:01:11.870721 ds=002b es=002b fs=0053 gs=002b eflags=00010206
03:01:11.870731 p1home=0000000000000034 p2home=0000000002080068 pe3home=0000000008cf34d8
03:01:11.870740 p4home=0000000300000104 p5home=0000000000000000 pe6home=0000000000000000
03:01:11.870749 LastBranchToRip=0000000000000000 LastBranchFromRip=0000000000000000
03:01:11.870758 LastExceptionToRip=0000000000000000 LastExceptionFromRip=0000000000000000
03:01:11.870770
03:01:11.870771 Stack 000000000943e140, dumping 0x1ec0 bytes (low=0000000009240000, high=0000000009440000)
03:01:11.870785 000000000943e140/0000: 40 e1 43 09 00 00 00 00-73 74 61 63 6b 6d 61 72 @.C.....stackmar
03:01:11.871886 000000000943e150/0010: 6b 65 72 00 00 00 00 00-00 10 02 00 00 00 00 00 ker.............
03:01:11.871893 000000000943e160/0020: 00 00 00 00 00 00 00 00-50 b7 86 e2 fe 7f 00 00 ........P.......

[ueli]

I've been inactive in this thread for quite some time, but I'm back now. This is what has happened in the mean time:

I configured my Ubuntu guest to use the null audio driver. I used the guest in the usual way for about a week, with NO PROBLEM whatsoever. There is the old wisdom that you may be able to prove the presence of bugs, but you'll never be able to prove their absence. But my experience with the null driver let's me believe that this is the perfect workaround for me.

Then I stopped the guest, reconfigured it to use the Windows DirectSound driver (as before), audio in=on, out=off. It didn't take long to have a crash again. I attach the logs of this crash.

You asked me also for logs of the guest with the null audio driver. At this point I have to apologize: I just forgot to save these logs . But I'm going to restart with the null driver. I expect a perfectly stable VM, and after a few days I'll stop it again and post these logs.

[ueli]

Attached are finally the logs of my Ubuntu guest, with audio settings: driver=null, input=enabled, output=disabled. The VM was up for a few days with no problem whatsoever.
I think with this post I have supplied all the evidence I can offer. I will now make the null audio driver my standard setting and expect continued stability. So I guess this is my last post here.

[Guus]

I have a similar problem. I can't do many things anymore with probably Windows guests on an Ubuntu 18.04 system and the problem seems to get worse. Right now I tried to pause the machine while rebooting in the BIOS screen so at least the disks won't get corrupted. It all started with not being able to shutdown the Windows 2008 guests (I have 2). I tried all kinds of things, but until now I can't find anything.

[ueli]

Guus: I have a reliable workaround: Configure guest audio with the null driver. With the null driver, everything is very stable. If I use the DirectSound driver, I still get occasional crashes (any guest OS). So the stability comes at the expense of audio support for the guests. Seems to be a limitation of vbox ....

[fth0]

@ueli: If you're still around, would you like to try a VirtualBox test build?

---

VirtualBox test build(s) for audio problems

On the VirtualBox test builds page, you'll find the VirtualBox stable branch test build 6.1.23r145004 (or newer). The audio functionality underwent extensive changes, and the VirtualBox developers are interested in getting positive as well as negative feedback regarding audio playback and recording. Please mention the host OS, the guest OS, the Host Audio Driver and the Audio Controller (from the VM configuration in Settings > Audio), and describe any misbehavior as detailed as possible. Thanks in advance.

[ueli]

I am the one who created the initial post of this topic. I'm happy to see that VBox is seeing an improvement.
So I installed VirtualBox-6.1.23-145326-Win on my Win10/64 host.
I have now 3 guests active, 2 of them with audio out enabled, audio in disabled:
- Linux Ubuntu 64 bit, WindowsDirectSound, ICH AC97
- WinXP, WindowsDirectSound, ICH AC97

When I started them, I was notified that a new version of the guest additions is available. This new version is now installed on both guests.

The above 2 guests are paused. As I don't know how to systematically reproduce the original problem, I just leave them and wait to see if I get a crash.
If I get one, I will add a reply. Otherwise I will keep silent and, after 2 weeks or so, assume that all works fine and shut down these 2 guests.

The third guest is one that I need for everyday use. Audio in/out is disabled. It's a Manjaro Linux which doesn't accept the standard guest addition image. Instead I have to install the guest additions from the Manjaro app store. I'm sure it's not the version associated with the VBox test build.

[fth0]

Can you perhaps report back in 1 week or so? The background reason is that I expect VirtualBox 6.1.24 to be released around July 20th 2021, and it will contain the audio-related changes when there is not anything against it.

[ueli]

I have added a reminder to my calendar for July 15.