Opened 6 years ago
Last modified 5 years ago
#18322 new defect
Shared folders hang while R/W access
Reported by: | makc | Owned by: | |
---|---|---|---|
Component: | shared folders | Version: | VirtualBox 6.0.2 |
Keywords: | hang | Cc: | |
Guest type: | Windows | Host type: | Linux |
Description
Host lsb_release -a
is
Distributor ID: Debian Description: Debian GNU/Linux 8.11 (jessie) Release: 8.11 Codename: jessie
I'm using shared folders in Windows 7 x86 guest and Mentor Expedition PCB hangs if I try to open project, placed on shared disk.
This behavior is not observed if I replace guest additions with version 5.2.22. Versions 6.0.0 and 6.0.2 show exactly the same behavior.
Other read/write operations doesn't show any problem (at this time).
I've tried to investigate hanging I/O operation in Expedition PCB and with the Process Monitor (Sysinternals) found, that last unfinished call was QueryDirectory. This event description from ProcMon is
Date & Time: 17.01.2019 14:58:38 Event Class: File System Operation: QueryDirectory Result: Path: \Device\VBoxMiniRdr\VBOXSVR\VM_Shared\KiberLock-NET\20190115\KibLck-NET_v1p0\PCB\.lck_dir\*.lckreq TID: 4996 Duration: Filter: *.lckreq
Call stack (reported by ProcMon) is
0 fltmgr.sys FltRequestOperationStatusCallback + 0xe8f 0xca0b3df7 C:\Windows\system32\drivers\fltmgr.sys 1 fltmgr.sys FltGetIrpName + 0xc56 0xca0b6d38 C:\Windows\system32\drivers\fltmgr.sys 2 fltmgr.sys FltGetIrpName + 0x116f 0xca0b7251 C:\Windows\system32\drivers\fltmgr.sys 3 fltmgr.sys FltGetIrpName + 0x162e 0xca0b7710 C:\Windows\system32\drivers\fltmgr.sys 4 ntkrnlpa.exe IofCallDriver + 0x64 0xe323c117 C:\Windows\system32\ntkrnlpa.exe 5 ntkrnlpa.exe NtSetEvent + 0x2c1 0xe3439f12 C:\Windows\system32\ntkrnlpa.exe 6 ntkrnlpa.exe NtQueryDirectoryFile + 0x5b 0xe3444528 C:\Windows\system32\ntkrnlpa.exe 7 ntkrnlpa.exe ZwYieldExecution + 0xf4e 0xe3242b8e C:\Windows\system32\ntkrnlpa.exe 8 ntdll.dll NtQueryDirectoryFile + 0xc 0x77825acc C:\Windows\System32\ntdll.dll 9 KernelBase.dll FindFirstFileExW + 0x276 0x7598b355 C:\Windows\System32\KernelBase.dll 10 KernelBase.dll FindFirstFileA + 0x4a 0x7599a956 C:\Windows\System32\KernelBase.dll 11 xf_Os.dll xf_Os.dll + 0x4f3d 0x10004f3d C:\MentorGraphics\7.9.5EE\SDD_HOME\common\win32\lib\xf_Os.dll
And another similar hang event from ProcMon and another process, tried to call the WriteFile:
Date & Time: 17.01.2019 16:02:08 Event Class: File System Operation: WriteFile Result: Path: \Device\VBoxMiniRdr\VBOXSVR\VM_Shared\KIBERLOCK-NET\20190115\KIBLCK-NET_V1P0\database\cdbsvr\log\2019-01-17 16.02.07-1536\2019.01.17.txt TID: 2648 Duration: Offset: 6,109 Length: 82 Priority: Normal
Call stack is very similar to the QueryDirectory one:
0 fltmgr.sys FltRequestOperationStatusCallback + 0xe8f 0xca0b3df7 C:\Windows\system32\drivers\fltmgr.sys 1 fltmgr.sys FltGetIrpName + 0xc56 0xca0b6d38 C:\Windows\system32\drivers\fltmgr.sys 2 fltmgr.sys FltGetIrpName + 0x116f 0xca0b7251 C:\Windows\system32\drivers\fltmgr.sys 3 fltmgr.sys FltGetIrpName + 0x162e 0xca0b7710 C:\Windows\system32\drivers\fltmgr.sys 4 ntkrnlpa.exe IofCallDriver + 0x64 0xe323c117 C:\Windows\system32\ntkrnlpa.exe 5 ntkrnlpa.exe NtSetEvent + 0x2c1 0xe3439f12 C:\Windows\system32\ntkrnlpa.exe 6 ntkrnlpa.exe NtWriteFile + 0x6fe 0xe3480994 C:\Windows\system32\ntkrnlpa.exe 7 ntkrnlpa.exe ZwYieldExecution + 0xf4e 0xe3242b8e C:\Windows\system32\ntkrnlpa.exe 8 ntdll.dll ZwWriteFile + 0xc 0x7782659c C:\Windows\System32\ntdll.dll 9 KernelBase.dll WriteFile + 0x5f 0x759875ad C:\Windows\System32\KernelBase.dll 10 kernel32.dll WriteFile + 0x4e 0x768d56e4 C:\Windows\System32\kernel32.dll 11 msvcr90.dll lseeki64 + 0x56b 0x71cc99ad C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\msvcr90.dll 12 msvcr90.dll write + 0x9f 0x71cc9d37 C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\msvcr90.dll 13 msvcr90.dll fdopen + 0x1c0 0x71c8fea2 C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\msvcr90.dll 14 msvcr90.dll fflush_nolock + 0x1c 0x71c8fef0 C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\msvcr90.dll 15 msvcr90.dll fflush + 0x30 0x71c90030 C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\msvcr90.dll 16 iCDBNetServer.exe iCDBNetServer.exe + 0x47fe6d 0x87fe6d C:\MentorGraphics\7.9.5EE\SDD_HOME\common\win32\bin\iCDBNetServer.exe
Change History (13)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
Can confirm the buggy behaviour. Same here for ubuntu host and both windows7 and windows10 guests.
follow-up: 4 comment:3 by , 6 years ago
This is a duplicate of about a dozen open tickets.
As it has been said time and time again, VirtualBox's Shared Folders present a very simplified file system implementation, just enough to read/write files from/to the guest. Many applications can error when using Shared Folders, because they expect advanced features, for example file locking, access controls, etc., which don't exist as a concept for Shared Folders.
I would use a a true network share (SaMBa).
Finally, it's usually better and faster, if issues get first addressed in the VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved over there, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of. For example, yours is most probably a duplicate and someone from the developers has to deal with it and close it as "Duplicate".
follow-up: 5 comment:4 by , 6 years ago
@sokratis: This is a regression and has nothing to do with the "very simplified file system". It works with 5.2.X and does not work with 6.0.2.
BTW: I have not found any duplicates of this bug. If this is already reported, give the other ticket number and we close this one.
Replying to socratis:
This is a duplicate of about a dozen open tickets.
As it has been said time and time again, VirtualBox's Shared Folders present a very simplified file system implementation, just enough to read/write files from/to the guest. Many applications can error when using Shared Folders, because they expect advanced features, for example file locking, access controls, etc., which don't exist as a concept for Shared Folders.
I would use a a true network share (SaMBa).
Finally, it's usually better and faster, if issues get first addressed in the VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved over there, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of. For example, yours is most probably a duplicate and someone from the developers has to deal with it and close it as "Duplicate".
follow-up: 7 comment:5 by , 6 years ago
Replying to olaf:
This is a regression and has nothing to do with the "very simplified file system". It works with 5.2.X and does not work with 6.0.2.
I'm sorry, I missed the "It worked with 5.2.22" part. :(
So, if you downgrade to 5.2.x, it works? Whatever you're doing works? If that's the case then it's definitely not a duplicate.
comment:7 by , 6 years ago
Replying to socratis:
So, if you downgrade to 5.2.x, it works? Whatever you're doing works? If that's the case then it's definitely not a duplicate.
I've tried several combinations and got following results:
- VBox 5.2.26 with its own additions (5.2.26) and extensions - works flawlessly.
- VBox 6.0.4 with additions from 5.2.26 and new 6.0.4 extensions - works flawlessly.
- VBox 6.0.4 with its own additions (6.0.4) and extensions - doesn't work, hangs and Windows can't even shut down properly.
- VBox 5.2.26 with its additions from 6.0.4 and extensions 5.2.26 - doesn't work, hangs and Windows can't even shut down properly.
As I've mentioned earlier, additions downgrade solves all problems. So it seems, that this bug is connected to this modifications in SharedFolders code:
--- VirtualBox-5.2.24/src/VBox/Additions/WINNT/SharedFolders/driver/info.c 2019-01-14 17:54:14.000000000 +0300 +++ info.c 2019-01-14 17:42:20.000000000 +0300 @@ -110,6 +112,12 @@ Log(("VBOXSF: MrxQueryDirectory: Query single entry\n")); fSFFlags |= SHFL_LIST_RETURN_ONE; } + if ( RxContext->QueryDirectory.RestartScan == TRUE + && RxContext->QueryDirectory.InitialQuery == FALSE) + { + Log(("VBOXSF: MrxQueryDirectory: Restart scan\n")); + fSFFlags |= SHFL_LIST_RESTART; + } if (Template->Length) {
comment:8 by , 6 years ago
Replying to boxer01:
Looks like #18151? But big thanks for extensive debugging.
This is not my case. There is no time delay before shared folder access hangs:
- I run application;
- open project from shared folder;
- opening process hangs exactly at 13% and project window doesn't respond;
- process couldn't be killed even through task manager;
- shared folders access lost (network drive is inaccessible);
- Windows enters endless loop while rebooting (hangs).
comment:9 by , 6 years ago
I see really no big difference here. You don’t know how many times your program access the project and it’s parts on the shared folders and how many bytes a transferred. So you see no time delay, but probably this 13 % is your time delay. It’s always 13%, but this could by a measure or display error or simply a coincidence. The only important thing here: this glitch happens not immediately, but after some time, and this time span is different between different systems. The only real difference between your situation and mine: I can start my VM without troubles, even if I couldn’t shutdown it properly really often in this case and have to kill it. But I don’t have an endless loop or some hanging here. The check of the virtual HDD also brings no error.
Meanwhile, socratis found the same issue on his Windows VMs. Let us hope that this would accelerate the cure for this trouble.
comment:10 by , 5 years ago
I've tried VirtualBox 6.0.6 r130049 with GA 6.0.6 r130049 and it solves my issue. All is working right expected: no hangs, no broken projects.
This ticket should be closed.
comment:11 by , 5 years ago
This bug exists in 5.2.32. I get the hang when attempting to open an attachment in Outlook from a Windows 7 VM running on Oracle Linux 7.6 physical machine. The hang doesn't always happen when I open an attachment, just once in a while. When it happens, I have to abort the machine, it will not shut down normally.
comment:12 by , 5 years ago
I encountered the same problem in 6.0.10 in Windows 10 guest under Fedora 30 64bit host
Update: tried exactly the same VM with 5.2.24 and it's guest additions - all is Ok, works perfectly.