Custom Query (16363 matches)
Results (2362 - 2364 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #11135 | obsolete | VirtualBox GUI can't close if VM was saved from CLI while the "VM Close" dialog was opened | ||
| Description |
VirtualBox 4.2.0 release on Solaris x86_64 (OpenIndiana oi_151a7): I tried to close a VirtualBox X11 GUI console of a VM with the GNOME window-manager "Close" button, which presented me with the proper dialog to Save or Poweroff the VM. Without closing the dialog, I saved the VM state with command-line VBoxManage utility. The GUI window and dialog did not go away at this moment, as usually happens when I save the VM state with external CLI, with the VM GUI window title bar progressing with Running - Saving - Saved - (window closes itself). Instead, when I picked a "Save VM" option in the VM close dialog, it failed (a dialog popped up and said the VM is already saved - which is true) and changed the title bar to reflect the Saved state. Now the window can not be closed with the window manager close-button, nor does it do anything when I choose the Machine/Close menu item (or press Host+Q); it only responds to "kill -9" of the VirtualBox process. The VM also can not be started (is locked) while this window exists. This is a bad situation; the GUI window should either close itself when the VM is no longer running (as it does in other cases), or at least allow itself to be closed interactively, and thus unlock the VM resources. |
|||
| #11138 | obsolete | At least on VirtualBox Win32 4.0.12, on when hibernating and the disk is full, V.B. actually crashes | ||
| Description |
(I would believe this bug is around also now.) Here's how it works:
From here, you *cannot* resume the hibernation process, nor take any action with the VirtualBox window! All that is to be done is to kill it using the task manager from ctrl+alt+delete . All info in that Virtualbox session has been lost. Lots of people must have this error. |
|||
| #11140 | obsolete | Shared clipboard and shared folders require Windows Explorer | ||
| Description |
I am running VirtualBox 4.2.2 on Windows 7 host with Windows XP guests. The Windows XP guests are running Perl scripts and require no user-interface. I am thus running with VBoxHeadless.exe and have replaced the Windows Explorer shell in the guest with cmd.exe by setting the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System\Shell to "cmd.exe /k C:\startup.cmd".
This setup works fine except that shared clipboard and shared folders won't work. When connecting with VRDP (Windows 7's Remote Desktop Connection), clipboard isn't shared. When trying to access These problems go away as soon as I start Windows Explorer (by typing "explorer" in the cmd.exe prompt). After that, the shared clipboard works fine, as well as the shared folders. The strange thing is that if I kill explorer.exe from Task Manager, shared clipboard and shared folders continue working fine. It seems they don't actually need explorer.exe except for some initialization. I don't think VirtualBox should have a dependency on Windows Explorer like this. |
|||

