Shared folders hang while R/W access

[makc]

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

[makc]

Update: tried exactly the same VM with 5.2.24 and it's guest additions - all is Ok, works perfectly.

[olaf]

Can confirm the buggy behaviour. Same here for ubuntu host and both windows7 and windows10 guests.

[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".

[olaf]

@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, please give the other ticket number and we simply close this one. Thanks.

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".

[Socratis]

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.

[boxer01]

Looks like #18151? But big thanks for extensive debugging.

[makc]

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)
     {

[makc]

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).

[boxer01]

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.

[makc]

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.

[linus100]

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.

[Max Fedotov]

I encountered the same problem in 6.0.10 in Windows 10 guest under Fedora 30 64bit host

[Socratis]

@the_source_him

Can you try the latest Testbuilds?