Very nice video.
Thank you very much.
Jump to content
Posted 06 December 2013 - 04:19 PM
New version: 1.3 Beta 1
Now you can set VMUB to automatically remove the USB drive(s) from the VirtualBox VM after closing. This way it will not show you error if you physically remove the USB drive(s) and start the VirtualBox Manager.
Posted 06 December 2013 - 05:46 PM
If the VM is run from VBox manager, it will run in 'write-protect' mode with the volume still accessible to Windows - this is sometimes very useful (e.g. experimenting with grub4dos menus by overwriting the menu.lst file whilst the VM is running and then rebooting the VM).
Posted 06 December 2013 - 06:18 PM
The new option works only when is checked. It is unchecked by default.
Posted 07 December 2013 - 06:36 AM
Some time ago I said that the VBoxManage.exe problem appears only when it's called from another program using a Windows API function. Well, I found a way to duplicate the problem in a batch file:
@cls @:replay @echo Detaching the drive from the VM... "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" storageattach GUID_of_the_VM --storagectl IDE --port 0 --device 0 --type hdd --medium none @if errorlevel 1 pause @echo Removing the drive... "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" closemedium disk GUID_of_the_vmdk @if errorlevel 1 pause @echo Attaching the drive "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" storageattach GUID_of_the_VM --storagectl IDE --port 0 --device 0 --type hdd --medium "VM_path\VMUBDrive000.vmdk" @if errorlevel 1 pause @echo _ @echo Press any key for a new cycle... @pause > nul @goto :replay
Create a VM with an IDE controller. Leave the first port free.
Run VMUB once without checking the option to remove the drive after closing. This way VMUBDrive000.vmdk will be attached.
Replace GUID_of_the_VM, GUID_of_the_vmdk and VM_path in the text above, create a bat/cmd file, copy the text there and start it.
It should start ok the first time. If not check those 3 mentioned above or the VBoxManage path. Or you were "lucky" to get the error from the first start...
When it says "Press any key for a new cycle..." wait 5 sec .. 1 min and press a key. The tricky part is to get the right "window" of time (on my computer it works with 10 sec). If you find it, the attach command will wait about 30 sec and show you this error:
VBoxManage.exe: error: Failed to create the VirtualBox object!
VBoxManage.exe: error: Code CO_E_SERVER_EXEC_FAILURE (0x80080005) - Server execution failed (extended info not available)
VBoxManage.exe: error: Most likely, the VirtualBox COM server is not running or failed to start.
Posted 08 December 2013 - 12:40 PM
New version: 1.3 Beta 2.
1. If VBoxManage.exe is having problems doing a job, the job is described with a suggestive name in the warning dialog.
2. Also the waiting time of 15 sec was reduced to 3 sec (silently, no progress window). Usually VBoxManage.exe takes about 0.5..1 sec to do the job so 3 sec is enough to know that something is wrong if it gets stuck.
3. The VBoxManage.exe usage in VMUB was decreased to minimum. So less chance for something to go wrong.
Download: link removed, you can find a better version in the next posts...
Posted 08 December 2013 - 06:09 PM
Glad you like it
Now I'm thinking to try make it "kill" the VBoxManage.exe process and try again (all automatically). It closes itself in 30 sec but it's kinda too long...
But the tricky/difficult part is to find which VBoxSVC.exe process is from that VBoxManage.exe (not from VirtualBox.exe or from another VBoxManage.exe) and to "kill" it too...
Edit: since "killing" a process is kinda messy, I tried to send a Ctrl+C/Ctrl+Break to the VBoxManage console instead, but no luck...
Posted 09 December 2013 - 11:15 AM
Steve, on your computer the vboxmanage problems appear if you keep the VirtualBox Manager opened all the time or only if it's closed...?
Posted 09 December 2013 - 11:38 AM
When I made the video, I used a different user account (normal one). Usually I use an Administrator account with disabled UAC.
The issue only seemed to occur when using the standard user account - are you testing as Admin?
Posted 09 December 2013 - 11:46 AM
I'm using XP as an admin and having the problem. But, since VMUB is always started with administrative rights, it should be no difference.
To respond to my question: on my computer the vboxmanage.exe problem appears ONLY if VB Manager is closed.
Posted 09 December 2013 - 12:31 PM
A possible explanation (to why is not having problems when VB Manager is opened all the time):
I tested VMUB with VirtualBox 4.1.28 version: no vboxmanage problems.
At some point Oracle implemented a feature in VirtualBox: the "reuse" of VBoxSVC.exe. If a VirtualBox.exe session (Manager or VM) is reopened before VBoxSVC of a previous session is automatically closed, it is "reassigned" to the new session. Seems a good idea because it will load faster and the memory will be less fragmented.
But unfortunately this does not always function with VBoxManage.exe too. When VBoxSVC is about to be closed or it is closed, VBoxManage.exe sometimes does not load VBoxSVC and shows that error.
When VB Manager is opened all the time it keeps VBoxSVC opened as well and VBoxManage.exe can use it.
Posted 09 December 2013 - 01:36 PM
If this is the cause, unfortunately all I can do is to minimize the "damage" (like I did in 1.3 Beta 2). It's up to Oracle to fix this problem. I reported the bug twice but I got no reply from them each time.
Maybe if you guys will report the bug as well they will fix it...
Until then I will set the "direct update" method to be the default and advice you to keep the VB Manager always opened or to install an old VirtualBox version if you choose to use VBoxManage.exe method.
Posted 10 December 2013 - 11:46 AM
New version: 1.3 Beta 3.
Change: when VBoxManage.exe update method is used, VMUB no longer waits for the previous VM session to be fully closed if it finds VB Manager opened (because it will have no problems with VBoxSVC.exe).
Download: link removed, you can find a better version in the next posts...
Posted 10 December 2013 - 06:09 PM
Well, to continue my "monologue"...
New version: 1.3 Beta 4.
Change: new autodetect option in Options >> VirtualBox >> Method to update. Basically, when VMUB finds one or more VirtualBox.exe sessions (VB Manager and/or VM) opened, it uses VBoxManage.exe to update the VM configuration, otherwise it updates it directly.
Since it's the best choice, it's checked by default.
Download: download link removed, a better version can be found in the next posts.
Posted 11 December 2013 - 01:15 PM
New version: 1.3 Beta 5
Changes: a few optimizations to the newly added option (autodetect).
Download: link removed, you can find a better version in the next posts.
LE: if this version works fine it will be the last Beta version.
Posted 12 December 2013 - 09:21 AM
I notice that often VMUB cannot dismount my USB flash drive and so fails to launch VBox quite often. This usually happened when I quickly restart VMUB after quitting a session. No other user app was running and simply waiting for 20-30 seconds and re-running VMUB worked.
It struck me that this might be caused by my installed AV solution. When VMUB runs and quits, it remounts the USB drive. This would cause the AV s/w to see a 'new' drive and scan it which presumably would lock the USB drive until it had finished scanning. I disabled my AV (Avast) and the problem went away. Not much you can do about this except maybe provide the option to force a dismount of the USB drive on request? Of course I could configure my AV to not scan USB devices too.
Posted 12 December 2013 - 09:29 AM
) You waited until I released the final version to report a problem...
Well, joking aside:
A question: what does VMUB say..? "Unable to lock", "Unable to dismount" or something else?
Posted 12 December 2013 - 12:02 PM
I use Avira and it's make no difference (for VMUB) if it's on or off.
Anyway, forcing an application to stop accessing the USB drive is not always a good idea. Forcing an antivirus is even less good...
I think it's wise to ask about that on the Avast forums too. Maybe they will have a good solution or at least some helpful ideas...
Posted 12 December 2013 - 02:58 PM
Personally (but I know how my ideas are often queer ) I would make a popup window when the program is closed to the effect of:
Hi, since some users have been whining about issues when re-starting this tool very quickly (in conjunction with the Avast antivirus, but it may happen with other ones too) this is a time out to prevent re-starting the app before 30 seconds have elapsed.
This window will close itself in ...29 ...28 ...27
Even "Even electronic brain pancake crystal elderly" might do :
Posted 12 December 2013 - 05:52 PM
I can't seem to get my system to misbehave now - the only way I can repro it is to use a 32GB flash drive and select 'Scan removable media' in the AV GUI - then whilst it is scanning try to Start a VMUB VM and try to boot from it...
Posted 12 December 2013 - 06:10 PM
Not a bad idea Wonko, but it has a problem: the amount of time that is needed is software and hardware dependant. So, in some situations, those 30 sec may be too much, in other situations may be too less.
Steve, on your computer VMUB is set to lock the volumes before dismount...? If not, could you please check the option and see if the progress window appears and delays the dismount..?
Posted 12 December 2013 - 07:40 PM
yes, it was set to lock before dismount.
Don't worry about it now. When I can reliably repro it and find out what is causing it I will let you know.
Posted 13 December 2013 - 03:11 AM
I was curious and I installed the newest Avast version.
I didn't have any problems with VMUB and my 2 USB drives. But I had problems with other programs and had to reinstall Avira...
Offtopic: I tested many VirtualBox versions and forgot to mention: the VBoxManage.exe problem seems to have appeared in 4.2.20 version. So versions <= 4.2.18 are safe to use...
Boot methods & tools →
Boot from USB / Boot anywhere →
Windows Extreme →
FreeDos and Dos →
Project forge →
Project forge →
Community forum →
0 members, 0 guests, 0 anonymous users