Opened 5 years ago
Last modified 4 years ago
#18784 new defect
Windows guests hang exactly once after each host reboot
| Reported by: | rokopt | Owned by: | |
|---|---|---|---|
| Component: | other | Version: | VirtualBox 5.2.32 |
| Keywords: | Cc: | ||
| Guest type: | Windows | Host type: | Windows |
Description
At some point during the 5.2.x series (I don't remember exactly which version), I started consistently experiencing the following problem with VirtualBox on my (64-bit) Windows 10 host. It occurs only with my Windows (10) guests, not with my (Manjaro) Linux guest.
Whenever I reboot the host, after restarting VirtualBox and my VMs, each Windows guest (but not the Linux one) will freeze exactly once, very soon after its first startup. When it freezes, if I try to close the window, which causes the "power off / send reset / etc." dialog box to come up, then whatever I choose, nothing happens; instead, that dialog box also freezes. If I choose "power off", for example, the guest window does not close. Then I click the 'x' to close either the dialog box or the host window, and it simply disappears (leaving the guest in the aborted state).
After I restart the guest, it remains up for a very long time. It never freezes again on the second or ensuing startups, until after I reboot the host again.
This has been happening on all 5.2.x versions since the first one on which it happened (alas I don't remember which one that was). I'm unable to use 6.0.x because of ticket #14366, so I'm not sure whether the bug also exists there or not. I think I have had at least one VM freeze on 6.0.10 while checking to see whether ticket #14366 still existed there (it does), so perhaps this bug does still exist on 6.0.x, but I didn't run long enough (because of ticket #14366) to confirm that it was the same behavior (i.e. successful long-term operation on the second and ensuing guest reboots, with the problem recurring only after the next host reboot).
Attachments (4)
Change History (10)
follow-up: 2 comment:1 by , 5 years ago
- It's usually better and faster, if issues get first addressed in the VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved in the forums, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of.
- You were supposed to follow these steps when you filed the bug, and provide a VBox.log:
comment:2 by , 5 years ago
Replying to socratis:
- It's usually better and faster, if issues get first addressed in the VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved in the forums, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of.
Plus a discussion and analysis on the bug tracker is going to help me, you, and potentially a future drive-by user or two. Not so in the forums, many more tend to benefit...
Please, open a new thread in the VirtualBox on Windows Hosts section of the forums. Please be sure to mention that you came from the bug tracker and include the ticket number.
- You were supposed to follow these steps when you filed the bug, and provide a VBox.log:
Attach a (full) log file ("Machine" menu/"Show Log" in the main VirtualBox Manager window) straight away to save time for you and for us. The log file contains a lot of useful information about both the host and the guest systems as well as information about what happened during a particular machine run. Please do not cut and paste it.
I can't obtain a log by using "Machine"/"Show Log" because the GUI also hangs until I close the hanging VM.
by , 5 years ago
| Attachment: | Drobo Windows Corporate-2019-07-26-11-47-11.log added |
|---|
previous log 1 of 3
by , 5 years ago
| Attachment: | Drobo Windows Corporate-2019-07-26-11-45-42.log added |
|---|
previous log 2 of 3
by , 5 years ago
| Attachment: | Drobo Windows Corporate-2019-07-26-11-35-39.log added |
|---|
previous log 3 of 3
comment:4 by , 5 years ago
A forum user pointed out where to find logs from the three previous machine starts, which are retained in addition to the current one, so I have attached those. I am not certain which of them corresponds to a run which ended up freezing, but I think at least one of them most likely does.
by , 5 years ago
| Attachment: | Drobo Windows Corporate-2019-07-27-10-25-35.log added |
|---|
log after correcting (recently-introduced) extension pack mismatch
comment:5 by , 5 years ago
A forum user pointed out that after I'd recently tested 6.0.10 to see whether it would fix either this bug or ticket #14366, followed by a downgrade back to 5.2.32 since 6.0.10 didn't fix the problems, I'd left the extension pack for 6.0.10 installed. So I reverted that to 5.2.32 as well, then reproduced the problem. I've attached a new log.
comment:6 by , 4 years ago
6.1.0 might have fixed this for me, though I'm seeing a number of segfaults and hangs with slightly different properties (specifically, in that powering off actually does work, instead of hanging itself and requiring the VM to be killed via Task Manager), so I'm not quite positive that this bug is fixed as opposed to manifesting differently on 6.1.0. I'll file reports for the remaining or new problem(s) when I can. Thanks.
