virtualbox.org

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: "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)

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.

Seems like I've found a workaround. By running this command instead:
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.

[引用] 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.

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

Last edited by klaus on 7. Feb 2025, 11:19, edited 1 time in total.
Reason: Moderator edit: adjusted version number to be plausible

Problem does not seem to be present in VirtualBox 7.0.24.

[引用] Note: This reply seems to have been made by a bot. Ignore it, it contributes nothing, it only creates confusion. Please delete the user and all its posts.

Update: After downgrading to Virtualbox 7.0-7.0.24 a month ago, I've had no freezes until today, which is sort of acceptable, much better than several freezes per hour as before. I've also used Windows 11 in this time, so maybe that's the reason, but probably not since I didn't have any freezes using 7.0 earlier using Windows 10.

Anyway, upgrading to 7.1.8 now to see what happens. Maybe it's better than 7.1.4.

[引用] No, it still happens. But I forgot that I'm using the "/k" option for cmd.exe now, and that makes the bug far less likely to happen, so there's probably no difference between 7.1.4 and 7.1.8. This seems to be a very serious bug in VirtualBox, but I guess I'm the only one who hits it regularly.

I can provide the source code for "ConsoleApp1.exe" and all my scripts if any developer wants to try to reproduce.

In case others have the same problem: Using NFS instead of shared folders works without problems. Need windows PRO to get NFS client though.

[引用] Minor update: I've been using SSHFS a couple of days now, and it works much better than NFS (which again was much better than shared folders in virtualbox). I haven't measured transfer-performance, but it seems more than fast enough (wouldn't be surprised if it's faster, although in theory it should be slower because of encryption, but it certainly doesn't feel that way). The big advantage though is it that there's non of those annoying pauses that you often get in NFS (seems like it's reconnecting after a while of inactivity), plus you don't have to wait a long time for it to mount, a billion times easier to set up, and it automatically mounts when starting up the client. In addition, you don't need Windows PRO and you don't need a bridged network instead of NAS. Followed this recipe to set it up: https://www.petergirnus.com/blog/how-to ... on-windows