Error reading from process error when launching application on guest machine

[MikeZnaet]

I have Win7x64 installed on Host and Guest machine.

When I start any application on client side using guestcontrol Ex.:VBoxManage guestcontrol "D:\VMS\VM_TWO\VM_TWO.vbox" execute --image "c:\Windows\System32\calc.exe" --username "uname" - -password "pass" --wait-exit --wait-stdout

VBoxService at client side starts using at least 50% of processor time. After 20-35 seconds I have next error. Ex.: VBoxManage.exe: error: Reading from process "c:\Windows\System32\calc.exe" (PID 2524) failed: VERR_TIMEOUT.

But on client side launched application continue working (in that case it's calc.exe) and VBoxService no use processor any more.

When I use guestcontrol without --wait-stdout, I dont have this error and VBoxService dont use processor so much. In my case I need to use --wait-stdout. Do you have any suggestion, how I can fix this problem.

I have the same problem with version 4.2.4

Log file attached.

Thanks, Mike

[MikeLeonhard]

This bug is disrupting my automated tests. I'm using VirtualBox 4.2.6 on Windows 7 Ultimate 64-bit. The VERR_TIMEOUT error is occurring with these guest operating systems:

• Windows Vista Ultimate 32-bit Service Pack 2
• Windows Vista Ultimate 64-bit Service Pack 2
• Windows 7 Ultimate 32-bit Service Pack 1
• Windows 7 Ultimate 64-bit Service Pack 1
• Windows 8 Pro 32-bit

In some cases, the error occurs and VBoxManage exits before the process on the guest OS has finished.

The error is not occurring with Windows XP Pro 32-bit or 64-bit. All guest OSes have Guest Additions 4.2.6.

Could someone please assign this bug and schedule it for fixing?

[fickludd]

I can confirm this on VirtualBox 4.2.6r82870, with Linux Mint 13 host and Windows 7 64-bit Pro.

> VBoxManage guestcontrol windows exec --image "C:\program files (x86)\proteowizard\proteowizard 3.0.4299\msconvert.exe" --username johant --passwordfile ~/.pwd --wait-exit --wait-stderr -- XXX
VBoxManage: error: Reading from process "C:\program files (x86)\proteowizard\proteowizard 3.0.4299\msconvert.exe" (PID 2684) failed: VERR_TIMEOUT.

Note that this was without --wait-stdout but with --wait-stderr

The process keeps running fine on guest.

[Magnus Madsen]

I think I have found out why this happens; though I am not really able to submit a fix as I am not very proficient in Cpp.

The issue is a combination of three things:

• The way the VboxManage executable loops when waiting for output from a guest process.
• The fact that IProcess->WaitFor flag ProcessWaitForFlag.StdOut doesn't seem to be implemented for at least Windows guests.
• Another error/timeout somewhere in the communication between the Guest Additions and the host machine.

When you have started a process from VboxManage it goes into a loop where it uses IProcess->WaitForArray to wait for some specific flags; this depends on if you have set the --wait-stdout and --wait-stderr arguments.

The problem is, that when a waiting action is not supported by the guest, the WaitFor/WaitForArray functions _immediately_ returns ProcessWaitResult_WaitFlagNotSupported. When this value is returned, VboxManage reads from StdOut or StdErr if this has been specified and this works.

This has been thought of, since there a RTThreadYield(); is present when the WaitFlagNotSupported value is returned but it doesn't seem to be enough.

In my testing with a simple app that does the same, inserting a delay between each call to IProcess->Read solved the issue that the host processes crashes after 35-45 seconds. I used 50ms, but I haven't checked many values so it is very likely that smaller values would work as well.

So to recap, I think this can be solved in three ways:

• Implement the WaitForStdOut/WaitForStdErr flags for Windows GuestAdditions.
• Modify the WaitFor functions to wait until the supplied timeout, or at least a small timeout, even if WaitFlagNotSupported is returned.
• Modify VboxManage to insert a delay if WaitFlagNotSupported is returned.

Method #2 probably makes the most sense to implement, but I leave that up to the developers if they decide to look at it.

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.