VBox 5.0x unresponsive running VS1015 (or other WPF?)

[wuzzy]

I had installed VBox version 5.0.2 on a Mac OSX machine running 10.10.5.

I created two (one from clean under 5.0.2 and one from clone of a machine installed under 4.3) windows 8.1 guest images each updated with latest windows updates and VBox guest additions.

On each of these I installed Visual Studio 2015.

When run up, Visual studio gets as far as openning the screen, at this point the host machine indicates that the process is fully utilising the four cores it is allocated and the windows machine becomes almost completely unresponsive. I have to power off to shut them down.

I have tried the following:

1) Disable 3d acceleration in the guest definition. 2) enable and disable the Hyper-V integration. 3) Apply the registry setting to disable WPF hardware acceleration usage: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DisableHWAcceleration 4) upgrade to latest build: 5.0.3 (with matching guest additions) same issues. 5) downgrade to build 5.0.0 (with matching guest additions) same issues.

finally downgrading to build 4.3.30.r101610 (with matching guest additions) Visual studio will now run as expected.

All experiments carried out on the same virtual machines.

I have during these experiments concentrated on Visual Studio, though the machines also appeared to occasionally lockup in the same manner with other causes. On one occasion the machine froze with the guest additions prompt on the screen. But on most occassions windows ran sufficiently to start Studio before hanging.

[wuzzy]

Additional information:

The original of the cloned Windows 8.1 machine was running Visual Studio 2013 correctly with all versions of VBox 5.0.0/2/3. This would appear to be related to the newer VisualStudio/.Net version?

I have also successfully run VS2015 in a windows 8.1 guest on a windows 7 host machine with version VBox 5.0.1, so this seems to be related to the OS/X hosting?

[wuzzy]

5.0.4 marks a slight improvement, I appear now to be able to get as far as opening a project in Visual studio before the VM stops responding. Again rolling back to 4.3.30 VM is fully functional.

If there is anything I can supply to help debug this let me know.

[devsk]

I am seeing a similar lock up on a Windows 8.1 Pro VM upgraded to Windows 10. Randomly, the VM just locks up and the mouse and keyboard do not generate any output. Nothing can be clicked or selected. And the windows (e.g. taskmgr) is not being updated.

My host is Linux though.

I think VBox has issues with guests running Windows 8.1 pro and above. Is someone going to look at this?

[Frank Mehnert]

Please attach VBox.log files of VM sessions when you run this guests. This will allow us to verify your VM configuration.

[wuzzy]

Problem still present in 5.0.20 (log attached) System becomes unresponsive if I attempt to open a solution in Visual Studio 2015. Host shows 300-400% cpu usage. Eventually I have to 'Power Off' the VM.

Rolling back to latest 4.3.38 system is stable again.

Log attached!

[mpfj]

I'm seeing the same thing in 5.0.22 (log 'Windows 10-2016-06-24-14-29-23.log' attached).

System unresponsive after loading a solution and I have to select "Reset".

Sometimes the VM even reboots itself ... e.g. from log:-

01:00:11.567238 VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive. Last heartbeat received 4 seconds ago

... and I get a VM reboot.

I'm running Ubuntu 16.04 64bit.

[mpfj]

Might this be related to ticket #15529 ?

[mpfj]

Updated to 5.0.24 and problem seems fixed.

[Denny]

I am still getting this error from time to time. Running Base OS Ubuntu 16.04 with a number of other VM hosted. I have clients that also experience this now as well. Linux Host OS with Windows Server.

[Harry M]

I am seeing what I believe is the same issue. I host VBox on CentOS 6 and run a variety of different guests. Recently, versions of VBox cause mouse control in guests to hang indefinitely. I can use alt-tab in the guest to switch to a command line window, but not always. If alt-tab does happen to work, I can type in the command line window. It seems that it is the mouse that locks up in all cases, and sometimes the keyboard as well.

I have tried rolling back from VBox 5.1 to VBox 5.0 without any relief from this problem. I also tried disabling 3D, turning off the menu in the guest, and I even removed two wireless cards because I was getting some errors in the host system log. None of these ultimately made any difference.

I do not recall ever having this problem until about the last rev (5.1.14, and maybe 5.1.12, and 5.0.32 or so, the last update I used on 5.0 series); this seems to be a recently-incurred problem. I note that others here have been experiencing this for over a year, so I am not sure why this has suddenly become a problem for me only recently.

[Harry M]

It appears that selecting "None" for the choice of virtualization cleans up the freezing problem. However, I've noticed that the mouse still gets funny once in a while, where it does not respond to clicks (but it does to movements, updating the screen properly). Even updating back to 5.1.14 still shows proper operation all around, with (maybe) the exception of the mouse problem (which I will continue to track and investigate).

[Harry M]

Alas. No sooner it seems that the problem has gone away, VBox makes a liar of me.

I think I can summarize/characterize the problem generally. Text input continues to work in VMs and on the host. The mouse seems to have just gone away completely. However, shutting down the VM that is locking up (they seem to lock up the mouse one at a time) will bring the system whole again; the mouse will then work properly everywhere (i.e., host and all running VMs).

I am going to roll back to 5.1.10 again to see how long, if ever, until the problem surfaces. Before this most recent update to 5.1.14 (see comment 11, above), I had not seen the problem again. I will continue to avoid KVM as the virtualization method to ensure that does not impact the experiment.

[Harry M]

I would say now, that after 3 days of uptime, no VM has experienced ANY sort of issue related to mouse control.

This may not be the "smoking gun," per se, but it does appear to be suspicious to me. Before I upgrade to the VBox 5.1 series, I had been using VBox 5.0 for some time without incident. When 5.0.32 came out, I upgraded from 5.0.30, as I normally do any time a maintenance release comes out (usually within a day or so of the release). That was about the time I noticed the mouse problems.

After several days of frustration, and having to constantly reboot VMs to free the mouse, and having no resolution to the problem, despite trying many of the solutions offered in various forums online, I thought it might be a good idea to upgrade to Vbox 5.1, because (perhaps) I might get better support from VBox if I were using the most recent version. I upgraded to VBox 5.1.12, as that was the most current at that time, only to discover that the same issue was occurring with the mouse. Again, I tried a variety of different approaches to resolve the problem to no effect.

VBox 5.1.14 was released, and I immediately updated (as I always do, as I said above), but the problem persisted. Even selecting "None" for virtualization method did not help in any of these scenarios (though it certainly did seem to help for a moment there; see my previous posts).

While looking through the change logs for 5.0.32, 5.1.12, and 5.1.14, I noticed that a certain bug was fixed in both 5.0.32 AND 5.1.12: "Linux hosts: automatically disable asynchronous I/O on Linux 2.6.18 kernels as high I/O load may trigger kernel oopses on these kernels if this feature is enabled" There may be other bug fixes common to these, but I found this one particularly interesting. I am wondering, if somehow, someway, maybe this is interfering with the mouse.

One thing that comes to mind is that at least part of the i/o between a VM and host would be the mouse movements (forgive me if my understanding of X window I/O is very incomplete). Maybe some mouse movements are not received by the host on behalf of the VM, or are being queued since async traffic has been disabled. I get it that the same traffic would be redirected via synchronous queues somehow (again, my knowledge is limited here), but perhaps not all such avenues were considered, such as corner cases and the like.

In summary, until 5.0.30, I did not experience the issue with the mouse. Falling back to 5.1.10 in the VBox 5.1 series seems to remediate the problem (given 3 days without issue). My thinking is that maybe that i/o fix that was applied to both 5.0.32 and 5.1.12 is the source of my mouse problem since those were the point releases where the undesirable behavior began. This is only theory, and it's only a thought.

At any rate, I am debating altering one of my VMs -- the one that seemed to be most vulnerable to this mouse problem -- to use KVM paravirtualization instead of "None" on 5.1.10. That way, we can see if using KVM is or is not the/a culprit in this.

[Harry M]

I am reasonably certain that the upgrade to vbox 5.1.12 (and 5.0.32) was the source of mouse lockup. I am running with 5.1.10 for over a week with no issues with the mouse.

I did try, however, to use the KVM driver; I observed some problems with the mouse even with 5.1.10. But without KVM, VBox seems to work well, or at least well enough for my needs.

In conclusion, I believe the patch noted above should be examined and (probably) rolled back. Thank you.

(Sorry for these edits to this post. I wanted to make sure it was accurate and consistent.)