Hanging Windows 10 VM

[hoytr]

Hello,

I have a windows 10 VM that I recently created. I'm running Lubuntu 16.04, VirtualBox 5.0.18. I have 5 VMs running, 4 are linux and one is this Win10 one. I seem to hardly be able to make it 12-16 hours and the host freezes. There's nothing in the log that looks of interest:

04:00:48.222083 RTC: period=0x10 (16) 2048 Hz
24:35:10.378394 Changing the VM state from 'RUNNING' to 'SUSPENDING'

The 24:35 is when I saw it was hung and closed the VM. It appears the VirtualBox thinks the VM is running successfully, but I can't interact with it (either in the VM, with Remote Desktop, or web services which I have running on it). After I start the VM back up, it goes directly into Win10, it doesn't show me a "this desktop crashed, do you want to go to safe mode" dialog. I'm not too versed in Win10, but I assume something that like would happen if I powered off a device when it was running.

Any idea on what I could check for? Thanks!

[socratis]

There's nothing in the log that looks of interest

You never know if someone with more experience discovers something. So, please ZIP the VBox.log from the Win 10 failed VM and attach it to your reply.

I can't interact with it (either in the VM, with Remote Desktop, or web services which I have running on it).

Have you tried to use the VM directly, i.e. non-remote? I just want to make sure that a remote access app is not responsible for the freeze.

I have 5 VMs running, 4 are linux and one is this Win10 one.

Are these running concurrently? I will need to see the rough specifications of the host and all of the VMs. For the first go, just list the amounts of RAM and CPUs that the host and the VMs have allocated. Example:
• Host Lubuntu 16.04: 64 GB RAM, 8 CPUs. <-- I'm going to see that in the VBox.log, but please include it.
• VM1 Ubuntu 12.04: 4 GB RAM, 1 CPU.
• VM2 Fedora 20: 2 GB RAM, 2 CPUs.
etc.

[hoytr]

You never know if someone with more experience discovers something. So, please ZIP the VBox.log from the Win 10 failed VM and attach it to your reply.

Valid point. Attached is the log.

Have you tried to use the VM directly, i.e. non-remote? I just want to make sure that a remote access app is not responsible for the freeze.

Sorry that wasn't clear. I typically am accessing it directly, however, I tried RDP via Windows thinking that perhaps the VM session was just non-responsive.

Are these running concurrently? I will need to see the rough specifications of the host and all of the VMs. For the first go, just list the amounts of RAM and CPUs that the host and the VMs have allocated. Example:
• Host Lubuntu 16.04: 64 GB RAM, 8 CPUs. <-- I'm going to see that in the VBox.log, but please include it.
• VM1 Ubuntu 12.04: 4 GB RAM, 1 CPU.
• VM2 Fedora 20: 2 GB RAM, 2 CPUs.
etc.

Yes, they all run concurrently.

0 - Host: Serv01-master - RAM: 24GB, 8 CPUs.
1 - Serv01 - Lubuntu 16.04 32 bit - RAM: 2GB, CPUs: 1
2 - Serv01-ownCloud - Lubuntu 14.04 32 bit - RAM: 1GB, CPUs: 2
3 - Serv01-vpn - Lubuntu 14.04 32 bit - RAM: 512MB, CPUs: 2
4 - Serv01-web - Lubuntu 14.04 32 bit - RAM: 512MB, CPUs: 1
5 - Serv01-win10 - Windows 10 64 bit - RAM: 4GM, CPUs: 4

I had jacked around with the CPUs a bit recently. These VMs are usually running sub 5% on the CPUs, but I added a few to see what would happen when running some processor intensive apps inside various VMs. Thanks!

[mpack]

You are using the Ubuntu fork, you aren't actually using VirtualBox. You need to either install the official VirtualBox package from the Downloads area, or get support on the Ubuntu forums.

[socratis]

You definitely need to do what mpack tells you about updating to the official VirtualBox package. But, here is some advice that can be used for future reference:

• The sum of the resources on your running VMs (RAM, CPUs), should always be less than the ones available on your host. Otherwise something's gonna give. In your case the Win10 VM, most probably.
• You have 3GB assigned in your Win10 VM, not 4GB as stated in your previous message.
• You have a VDI mounted which seems/sounds a little out of the ordinary '~/VMs/serv01-win7/googleDrive.vdi'. I'm just raising a flag (caution) in case this file is used by multiple VMs. If it is, we need to discuss it more, in not, forget I ever mentioned it.
• Finally, this VM's log ended prematurely. If it's the one that crashed, it's understandable. If not, it's best if you first shut down the VM and then post its log.

[hoytr]

You are using the Ubuntu fork, you aren't actually using VirtualBox. You need to either install the official VirtualBox package from the Downloads area, or get support on the Ubuntu forums.

You're saying that because of the version part that ends with _Ubuntu? I just installed VirtualBox recently on this host when I rebuilt it and think I did it through the Ubuntu repository I think, so I guess I'll do this first.

But, here is some advice that can be used for future reference:

• The sum of the resources on your running VMs (RAM, CPUs), should always be less than the ones available on your host. Otherwise something's gonna give. In your case the Win10 VM, most probably.

Yeah, I think I had done that at first and upped a few of the CPUs without turning them back down. I'm not sure that's the issue with the Win10 host hanging, but I understand that you're saying it is an issue.

[*]You have 3GB assigned in your Win10 VM, not 4GB as stated in your previous message.

Odd. I certainly have 4GB allocated. Maybe this is the wrong log file, or an old version of it... After I install the correct version of VirtualBox, I'll double check that this is writing out properly.

[*]You have a VDI mounted which seems/sounds a little out of the ordinary '~/VMs/serv01-win7/googleDrive.vdi'. I'm just raising a flag (caution) in case this file is used by multiple VMs. If it is, we need to discuss it more, in not, forget I ever mentioned it.

That was the old version of this VM. I build a new VM named serv01-win10 and associated the googleDrive vdi from the win7 one to this one and then shutdown the win7 one. So it's not actually used by multiple VMs, but I should probably move the file to a better location now.

[*]Finally, this VM's log ended prematurely. If it's the one that crashed, it's understandable. If not, it's best if you first shut down the VM and then post its log.[/list]

Yes, it was in a crashed state when I grabbed the log file. I didn't power-off the VM prior to grabbing the logs.

Thanks for the guidance. I'll put the correct VirtualBox version on and see what I get!

[hoytr]

Alright, I've got the proper VirtualBox install running now. I had <4096 MB allocated to that VM previously, so it was showing as 3GB, I made it exactly 4096 and now it shows 4GB as expected. I changed the CPUs around to be using less than the total of my host. I'll see how things go for a bit and update. Thanks!

[socratis]

I had <4096 MB allocated to that VM previously, so it was showing as 3GB

00:00:00.790990   RamSize           <integer> = 0x00000000fa000000 (4 194 304 000, 3 GB)

Yes, you had 3.91GB allocated (4000MB). I wonder why VirtualBox rounded it up to an integer # GB and not MB. Funny...

[hoytr]

The Win-10 guest hung again. I closed the session and grabbed the log file. Thanks!

[mpack]

Please don't confuse matters: your problem is in the guest, not the host.

I can't see any evidence of problems in the log, the only thing I'd pick up on is that you have no extension pack installed, therefore you are using USB 1.x which is incredibly slow, and you do seem to be doing something with USB right early in the log :-

00:00:26.565679 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices
00:01:56.707901 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices
00:01:56.920894 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices
00:01:57.541340 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices
00:01:57.696394 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices
00:01:57.847213 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices

However I don't know why this would cause a hang 48 hours in... though that number is itself suspicious. Daily backup kicking off?

[hoytr]

Please don't confuse matters: your problem is in the guest, not the host.

You're right, I edited the post. I think of it as a host because it hosts some services, but it's not the VirtualBox host.

I can't see any evidence of problems in the log, the only thing I'd pick up on is that you have no extension pack installed, therefore you are using USB 1.x which is incredibly slow, and you do seem to be doing something with USB right early in the log :-

00:00:26.565679 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices
00:01:56.707901 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices
00:01:56.920894 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices
00:01:57.541340 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices
00:01:57.696394 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices
00:01:57.847213 OHCI#0: Lagging too far behind, not trying to catch up anymore. Expect glitches with USB devices

However I don't know why this would cause a hang 48 hours in... though that number is itself suspicious. Daily backup kicking off?

I don't think the 48 hour mark is when it hung. That's when I logged in and changed something, then restarted the guest (not Windows restart):

48:01:36.400121 Changing the VM state from 'RUNNING' to 'SUSPENDING'
48:01:36.472654 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
48:01:46.936182 Changing the VM state from 'SUSPENDED' to 'RESUMING'
48:01:46.975015 Changing the VM state from 'RESUMING' to 'RUNNING'

The Win10 guest hung sometime between these two spots I think:

48:01:46.975062 Console: Machine state changed to 'Running'
48:01:55.262018 AIOMgr: Flush failed with VERR_INVALID_PARAMETER, disabling async flushes
48:06:34.365644 AIOMgr: Flush failed with VERR_INVALID_PARAMETER, disabling async flushes
50:15:47.540170 AHCI#0: Port 1 reset
51:01:00.465488 AHCI#0: Port 1 reset

I noticed at 65:42 that it was hung and shut it down via VirtualBox. Thanks!

[hoytr]

I actually got a visual error tonight. First time I've seen this dialog (screenshot attached). Thanks!

[mpack]

The crash is a triple fault, which usually means that the guest code tried something nasty. I'd look carefully at any non-native drivers, debug apps or AV apps running in the VM. No, Microsoft are not immune to bugs, but if it was a native app then other Win10 users would be seeing the same problem.