Shared folder stops working, freezing programs, unable to do clean shutdown of OS.

[Kjetil]

Hi,

I'm using Windows 10, Linux host.
My shared folder is mounted to "G:\", pointing to my home directory on the Linux host.

What I do:

On the host, I run this command:

Code: Select all

VBoxManage guestcontrol Windows10 --username kjetil --password xxxxxxx run -- G:\\dev_stuff\ConsoleApp1.exe  G:\\dev_stuff\filename.cpp 100

"ConsoleApp1.exe" is a program I've written that tells visual studio to open "filename.cpp" at line 100 (in this case). Visual studio then goes on to close all current document before opening "filename.cpp" and scroll the cursor to line 100. This works, if I'll let the system rest.

But! If I press "F4" in Visual Studio right afterwards, maybe within a second of running the command above on the host, it'll make G: stop working, maybe half of the times. (Pressing "F4" tells Visual studio to jump to the next error, in other words opening a file on "G:\".)

I don't know whether running VBoxManage from the guest is necessary to provoke this. I would guess it's happening because lots of things are happening at the same time to G:\ (reading+writing+executing), and that a general stress test would provoke the same, but I don't know.

After this has happened, it seems impossible to kill Visual Studio, and it becomes impossible to do a clean shut down of Windows 10 (have to just power it off). (Note that "G:" is not available to any program on the host after this, the shared folder has completely stopped working.)

This problem started happening after upgrading virtual box to 7.1.6. It did not happen in 7.1.4 or earlier. So I'm going to downgrade to 7.1.4 now. I'll report back if the problem persists after downgrading, or if it seems to fix the problem.

I've attached the VM log.

Running "journalctl -b" on the host doesn't show any relevant lines.

Here's a screenshot of where visual studio freezes (this is the backtrace from another visual studio instance debugging the frozen visual studio instance)

Untitled.png (53.98 KiB) Viewed 11895 times

[Kjetil]

Note: VirtualBox 7.1.14 randomly froze for me, as reported by many others. I haven't seen that happening in 7.1.16, but the freezing in 7.1.14 happened far less often than the shared folder freezing in 7.1.6.

[Kjetil]

Seems like I've found a workaround. By running this command instead:

Code: Select all

VBoxManage guestcontrol Windows10 --username kjetil --password xxxxxxx run -- cmd.exe /k G:\\dev_stuff\ConsoleApp1.exe  G:\\dev_stuff\filename.cpp 100

I.e. run ConsoleApp1.exe via "cmd.exe /k", the freeze doesn't happen. So maybe it's related to "VBoxManage"?
Anyway, not going to downgrade virtualbox to 7.1.14 yet, to check if that helps.

[Kjetil]

Seems like I've found a workaround. By running this command instead:

Code: Select all

VBoxManage guestcontrol Windows10 --username kjetil --password xxxxxxx run -- cmd.exe /k G:\\dev_stuff\ConsoleApp1.exe  G:\\dev_stuff\filename.cpp 100

I.e. run ConsoleApp1.exe via "cmd.exe /k", the freeze doesn't happen. So maybe it's related to "VBoxManage"?

No, this just made it less likely to happen, so I guess it's not related to VBoxManage. Feels like a race condition in the shared folder implementation, causing freeze when reading, writing, and/or executing at the same time.

[spyretrieval]

VirtualBox 7.1.4 randomly froze for me, as reported by many others.