2.1.0.1000 on Windows 11 hangs Windows Explorer in single thread mode

[dswiss-desktop-app]

Environment

• Windows version: Windows 11
• Processor architecture: x64
• Dokany version: 2.1.0.1000
• Library type (Dokany/FUSE): Dokan mirror

Check List

• I checked my issue doesn't exist yet
• My issue is valid with mirror default sample and not specific to my user-mode driver implementation
• I can always reproduce the issue with the provided description below.
• I have updated Dokany to the latest version and have reboot my computer after.
• I tested one of the last snapshot from appveyor CI

Description

Dokan mirror hangs Windows Explorer (or crashes it) if the following conditions are met:

• single thread mode (-t)
• the source folder has a few images, I used .png files
• Windows Explorer is opened in the mount folder with icons shown and the Details Pane on

If you quickly click through the images, Explorer will hang for several seconds, sometimes indefinitely or crash. When hanging - the system restart may also hang and you need to use the force restart with the power button.

We have experienced the same problem with our app on Windows 11, the app starts Dokan 2.0.4 in single threaded mode. Today I built the dokan mirror example from master (using Visual Studio 2022) and with the -t option I can reproduce the bug very easily, see the video attached.

Parameters used:
mirror.exe -t -l "c:\Users\macie\Desktop\Dokan mirror" -r "c:\Users\macie\test"

Screen Recording (4-11-2024 1-32-03 PM).zip

[Liryna]

Hi @dswiss-desktop-app ,

Thanks for the report but unfortunately this is a known issue (not exactly this case but expected)
https://github.com/dokan-dev/dokany/blob/master/dokan/dokan.h#L147

The usual scenario is that a new request B holds a lock on a file (asked by the system) while a request A tries to complete but it cannot as locking is required. B cannot execute because the thread is busy with A.
On a multiple thread mode, A would unlock when B would have been completed.

I highly suggest not to run in a single thread mode.

A workaround would be to have a pool of thread in the library that takes care of submitting the result to the kernel instead of the single thread. This will allow B to execute on the single thread while another thread is pending for A result submission to go through. This requires some work if anyone is interested to contribute I would be happy to review it.

[dswiss-desktop-app]

Ok, we need to do a few changes to make our wrapper thread safe. But thanks for the explanation. Unfortunately our team has been downsized and we have no capacity to help you with this... ;-(