Page 1 of 1
Help troubleshooting unresponsive Windows guests
Posted: 23. Jul 2019, 19:14
by DaveC29
Hi,
I'm having difficulty running any Windows server guest O/S which has the "desktop experience" enabled. At some point in time (undetermined length of time as yet), the guest simply becomes unresponsive, as evidenced in the attached sample log at approx the 30 minute mark. Thus far, in terms of devices, I've tried disabling audio and setting USB back to 1.0 (from 3.0). I've tried to ensure NOT using config items which were not the defaults for a Windows Server guest O/S, but please let me know if I've inadvertently used a bad/inconsistent setting? I've tried brand new instances of several Windows Server O/S, including 2008 R2, 2012 R2, and 2016. None of the guests are configured to actually provide or perform any role or service - the guest system was simply left running (doing essentially nothing) when it became unresponsive to the heartbeat. I'm left with no choice but to power off the guest after that point in time.
I do NOT experience this issue with any of the following guests:
- Windows Server (2012 R2 or 2016) running SERVER CORE (no desktop)
- Windows 7
- Windows 10 (builds 1803, 1809, 1903)
- Ubuntu 18.04.2
The sample logs are from a 2008 R2 guest, but I can reproduce this (and provide logs) for others if needed. Hoping the logs might hold a clue for someone to provide guidance?
Thank you very much for any time spent,
DaveC
Re: Help troubleshooting unresponsive Windows guests
Posted: 23. Jul 2019, 19:18
by DaveC29
Apologies...I neglected to mention one other item which I tried --> inside the guest O/S, in "power options", I configured the display to NEVER power off. I thought perhaps this might have been related, but the change in setting did not make a difference.
-DaveC
Re: Help troubleshooting unresponsive Windows guests
Posted: 24. Jul 2019, 11:21
by mpack
What type of device is drive B: on the host? I have not seen a drive B in use since the 1980s! (but I'm pretty sure this isn't a 1.2MB floppy drive).
In fact the entire folder structure of this VM is off. B:\VirtualDisks? B:\VirtualBoxSnapshost? It looks like this was created by someone who has been reading up on the obsolete (by a decade) VirtualBox v3 folder structure. VirtualBox v4 and later keeps virtual disks in the VM folder, and with snapshots, logs and everything else. Otherwise it's a nightmare to back up.
If the problem was that the virtual drive was uncomfortably large for an SSD, then why not simply move the entire VM folder to a secondary drive? VirtualBox v6 even has a custom GUI manager command to do this for you easily: Machine|Move....
Re: Help troubleshooting unresponsive Windows guests
Posted: 24. Jul 2019, 19:56
by DaveC29
Hi mpack - thanks for your reply
The B: volume on my host system represents an SSD drive with plenty of available storage space. I can't provide much of an explanation why I chose to label it 'B'
I wasn't a VBox user until rather recently, so was not aware of the older documentation to which you're referring. I suppose what I've done here is used this 'B' drive as a secondary drive, but did not configure that within Virtual Box itself as you recommend below. Presently all of my virtual disks (and any snapshots) are stored on this B: volume. Only the Windows Server [with Desktop] guests have the reported issue, but I'm happy to get this folder structure back to standard, and will use that VBox feature you mention...
Thanks,
DaveC
Re: Help troubleshooting unresponsive Windows guests
Posted: 27. Jul 2019, 16:43
by DaveC29
Quick update:
Normalizing the folder structure for these VMs [using the tool to move related files to my desired disk volume] is a much appreciated method - thank you.
Unfortunately the original issue remains as is. VMs running Windows Server O/S with desktop experience still become unresponsive for an unknown reason. If anyone has any additional advice, please let me know.
Thanks,
DaveC
Re: Help troubleshooting unresponsive Windows guests
Posted: 28. Jul 2019, 00:52
by fth0
Since nobody has seen a real problem in the log files so far (me neither, but I'm no expert on them), it maybe is not even a VirtualBox related problem. So my advice is to momentarily ignore the fact that the Windows Server OS is running in a VM, and examine the Windows Server OS itself ... like on a phyical PC.
Re: Help troubleshooting unresponsive Windows guests
Posted: 28. Nov 2019, 15:34
by DaveC29
Sorry for the delayed follow up to this thread.
The guest VMs I'm testing with are about as vanilla as can be - no customization post install, beyond adding the VirtualBox Guest Additions.
I took a slightly different route in troubleshooting. I can run any Windows Server VM guest with "desktop experience" under Hyper-V or VMWare Workstation Pro. There is no issue with the guest O/S at all in those instances. But the same issue [as described in my first post] persists in VirtualBox, now at v. 6.0.14. I've no idea what else to look for and am afraid I'll have to abandon VirtualBox at this point; which is unfortunate
-DaveC29
Re: Help troubleshooting unresponsive Windows guests
Posted: 28. Nov 2019, 20:11
by socratis
DaveC29 wrote:But the same issue [as described in my first post] persists in VirtualBox, now at v. 6.0.14.
Since you've upgraded to 6.0.14, can you provide a fresh ZIPPED VBox.log?
Re: Help troubleshooting unresponsive Windows guests
Posted: 1. Dec 2019, 23:58
by DaveC29
Thanks for offering to have a look at this. I'm attaching two different logs (explanation below)...
2012.VBox.log: a Windows 2012 R2 guest with desktop experience. Became unresponsive after about 5 hours and then had to power off.
2016.VBox.log: a Windows 2016 guest with desktop experience. Became unresponsive three times during the course of this log file, but logged a bugcheck and reset itself after each occurrence. After the third one I PAUSED the VM, for no special reason, and then just shut it down.
Both VM guests are configured by default to write a dump file and reset upon system failure, but only the 2016 VM appears to be doing that, so I thought it might be useful to mention. That guest does have a memory.dmp file which seems to correspond with the last failure, which I can send along if anyone's interested or able to debug it, etc.
Thanks again,
DaveC