Too many Guid keys in MountPoint2

[lanopk]

Feature request can skip this form. Bug report must complete it. Check List must be 100% match or it will be automatically closed without further discussion. Please remove this line.

Environment

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

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

When setting CurrentSession when mounting and mounting to Z: using UncPath,
Too many GUID keys are created in \HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2.

These GUID keys are not deleted when unmounting.

Even if I try to delete it, I can't force it because I don't know the related GUID.

What are these GUID keys and why are they created?
How should I manage these GUID keys?

Thank you.

[Liryna]

Dokan does not directly write something in MountPoints2 but the system might indirectly create entries in it as part of the network mount.
I haven't looked at it but each mount of Dokan is using a new device GUID to avoid complications due to previous mounts stale states (like in the registry here). So it might not be crazy to see one new entry in the registry per mount.
After who should be removing it ? Does it stays after restart ? That's another question.

[lanopk]

Rebooting did not delete this GUID-based key.

And, I checked why these GUID keys are generated.

When I connect the drive for the first time after rebooting, only one key ##ServerName#VolumeName is created normally.

However, the problem occurs after the drive disconnects abnormally.

When connecting by setting CurrentSession,
If I do not unmount the drive properly (Process Kill or Crash) after connecting it, the drive will remain in the Disconnected Network Drive state.

In this situation, when I connect with the same drive letter (Z:), the error "Can't assign a drive letter or mount point" occurs. (This is also a problem. It does not resolve over time. I wish it could be removed automatically. .)

When I connect another drive (Y:) it generates a GUID based key.
Even if I specify a different UncPath or a different drive letter or do not specify a Current Session, a GUID-based key is always created for the subsequent connected drives.

Two, three, or even four GUID-based keys are generated.
After doing this several times, I have dozens of GUID-based keys.
(It seems like it's repeatedly checking the situation, creating a new GUID, and trying until it succeeds.)

When using Sandbox, GUID-based keys are always generated, even after reboot. Also, in Explorer, it is displayed as Network Drive, not the volume label I specified.
In this situation, when the volume label is changed in the explorer, _LabelFromReg of ##ServerName#VolumeName is not registered, but _LabelFromReg of one of the GUID-based keys is registered.
Very strange.

[Liryna]

In this situation, when I connect with the same drive letter (Z:), the error "Can't assign a drive letter or mount point" occurs. (This is also a problem. It does not resolve over time. I wish it could be removed automatically. .)

Normally it should resolve over time when the kernel detects the userland is no longer responding. Have you looked at the logs why it fails with "Can't assign a drive letter or mount point" ? (EventLog, user land debug logs etc)

I think here we should learn who is creating those values and why only when the userland is killed, they are not removed.

[lanopk]

When I run in Windows service mode and impersonate, specify CurrentSession and Network Unc Path and mount as Z:, only GUID-based keys are created.

The Z: drive can be used normally, but UncPath is not found.
In Explorer it will say "Network Drive (Z:)".
No volume name or Unc path is displayed.

It seems that the Impersonate permission or Token permission is the problem.
I can't solve it.

Wouldn't it be possible to mount based on LUID like CBFS?
CBFS can be mounted using multiple LUIDs using AddMountPoint(... luid) after CreateStorage.

It's really difficult to mount with CurrentSession in service mode.

[lanopk]

When setting CurrentSession with Impersonation in service mode,
If I look at dokannp's DebugView,

[15980] NPOpenEnum: dwScope 0x00000001, dwType 0x00000001, dwUsage 0x00000000, lpNetResource 0000000000000000
[15980] NPOpenEnum: pCtx 00000000013E13B0
[15980] NPEnumResource: hEnum 00000000013E13B0, lpcCount 00000000012BE440, lpBuffer 00000000013EA8B0, lpBufferSize 00000000012BE4B0.
[15980] NPEnumResource: *lpcCount 0xffffffff, *lpBufferSize 0x4000, pCtx->index 0
[15980] NPEnumResourceCurrentSesstionID: 1
[15980] NPEnumResource nbRead: 1
[15980] NPEnumResource SessionID: 0
[15980] NPEnumResource: Entries returned 0, dwStatus 0x00000103
[15980] NPCloseEnum: hEnum 00000000013E13B0
[15980] NPCloseEnum: returns

As the SessionID is set to 0, it does not match the CurrentSessionID, so the information cannot be found.

Source reference: dokannp.c, lines 609 to 614

This SessionID is obtained through the GetCurrentSessionId function at line 837 of event.c and set at line 868.

In cases like this, is there no way for the user to control it?

It would be nice if you could pass the SessionID.
For example,
Add one int CurrentSessionID to DOKAN Options
If CurrentSessionID is 0, GetCurrentSessionId is used, and if it is greater than 0, the given SessionID value is used.

Also, if the user can pass the SessionID value
Impersonation may not be required in service mode.
The driver will be able to obtain a token using the SessionID value and process it.

However, it could be a problem if the Session ID changes when the user logs out and logs in, or if an additional session is opened.
You may need to handle multiple SessionIDs.
Then you may need the AddSession and DeleteSession functions.

[lanopk]

It seems to be a problem with Google Translate, or my explanation is lacking.

My program runs as a Windows service.
(I wanted to see the Driver's log, but I can't. I don't know how to handle the Driver Log in a service made in C#.)

Set DOKAN_OPTION_NETWORK, DOKAN_OPTION_CURRENT_SESSION and
Set UncPath to "\Servername\ShareName" and
Set Drive Letter to Z:.

A token is obtained using the WTSQueryUserToken function using the SessionID (usually 1) passed from the client.
Impersonation is performed with the obtained token.
Call DokanCreateFileSystem.

Then everything will connect normally.
It also doesn't generate any strange GUID keys in MountPoint2.

These connected drives will appear in the list using the dir z: command in the CMD window.
It also appears fine as dir "\Servername\ShareName".

In a CMD window
explorer z:
Or, the moment I do ProcessExecute("explorer z:\") in my Client Program, multiple GUID keys are created.
[Log 1: After running Explorer]
[9044] NPOpenEnum: dwScope 0x00000001, dwType 0x00000001, dwUsage 0x00000000, lpNetResource 0000000000000000
[9044] NPOpenEnum: pCtx 000000001364ECF0
[9044] NPEnumResource: hEnum 000000001364ECF0, lpcCount 00000000116DECE0, lpBuffer 0000000003E91FF0, lpBufferSize 00000000116DED50.
[9044] NPEnumResource: *lpcCount 0xffffffff, *lpBufferSize 0x4000, pCtx->index 0
[9044] NPEnumResourceCurrentSesstionID: 1
[9044] NPEnumResource nbRead: 1
[9044] NPEnumResource SessionID: 0
[9044] NPEnumResource: Entries returned 0, dwStatus 0x00000103
[9044] NPCloseEnum: hEnum 000000001364ECF0
[9044] NPCloseEnum: returns

These logs appear quickly and repeatedly, and a GUID key is generated for the number of times or similar that appears.
And the list of files on the Z: drive appears properly in Explorer.

When used only in a CMD window, no GUID key is created, but when viewing the drive in Explorer, multiple GUID keys are created.

And, if I disconnect the drive without closing Z:'s Explorer window, several NPOpenEnum messages (see below, occurs 3 times) appear and many more GUID keys appear. (Probably because Explorer searches for the network of the disconnected drive)

[Log 2: Unmount without closing Explorer]
[5196]NPGetCaps11
[5196] WNNC_ENUMERATION
[5196] NPOpenEnum: dwScope 0x00000002, dwType 0x00000000, dwUsage 0x00000000, lpNetResource 0000000000000000
[5196] NPOpenEnum: pCtx 000000004F64B6B0
[5196] NPEnumResource: hEnum 000000004F64B6B0, lpcCount 0000000010CCF0C8, lpBuffer 000000001FB4CB60, lpBufferSize 0000000010CCF0C4.
[5196] NPEnumResource: *lpcCount 0xffffffff, *lpBufferSize 0x4000, pCtx->index 0
[5196] NPEnumResource DokanGetMountPointList failed
[5196] NPCloseEnum: hEnum 000000004F64B6B0
[5196] NPCloseEnum: returns
[5216]NPGetCaps11

If I unmount after closing the Explorer window, no additional GUID keys are created.

For reference, when I run explorer "\Servername\ShareName" in the CMD window, the following log and several [Log 1] appear after that, and only two GUID Keys are created.

[Log 3: When opening Explorer with Unc Path]
[7392] NPGetResourceInformation: NetResource 0000000000E9D990, Buffer 00000000010300F0, BufferSize 0000000000E9D830, System 0000000000E9D828
[7392] NPGetResourceInformation: lpRemoteName \Servername\Sharename, *BufferSize 0x830
[7392] parseServerName: cLeadingBackslashes 2
[7392] NPGetResourceInformation: lpServerName Servername\Sharename - 10
[7392] NPGetResourceInformation: lpAfterName\Sharename
[7392] NPGetResourceInformation: type 2
[7392] NPGetResourceInformation: lpRemoteName: \Servername\Sharename, strings 0000000001030920/0000000001030920
[7392] NPGetResourceParent: lpNetResource 00000000010300F0, lpBuffer 00000000010300F0, lpBufferSize 0000000000E9D9C0
[7392] parseServerName: cLeadingBackslashes 2

I hope this information will help improve Dokan.
Thank you.

[Liryna]

I must say I don't really know what we can do better there. In your logs, the listing of mount point is failing if thats the issue but that's expected because it has nothing to return anymore, the device is gone.

dokany/dokan_np/dokannp.c

Lines 595 to 600 in 7236eec

	PDOKAN_MOUNT_POINT_INFO dokanMountPointInfo =
	DokanGetMountPointList(TRUE, &nbRead);
	if (dokanMountPointInfo == NULL) {
	DbgPrintW(L"NPEnumResource DokanGetMountPointList failed\n");
	return WN_NO_MORE_ENTRIES;
	}

On your last log, NPGetResourceInformation is not listing the existing mount points. It just parse the input and return it without checking its existance which is probably why there is not extra lookup as explorer do.

What is the downside of having Explorer creating GUID ? Can or should we do anything about it ?

[lanopk]

I also think that dokannp is operating normally.

There is no particular problem with too many GUID-based keys being created in MountPoint2, but I am concerned that if this behavior is repeated, hundreds of GUID-based keys will be created in MountPoint2, which may affect the system.

The GUID keys that come up when I disconnect the drive while Explorer is referencing that network drive are not a problem. These GUIDs have fixed GUID keys. This is not a problem.

I think this can solve the problem of referencing the drive again in Explorer after connecting the drive with DOKAN_OPTION_NETWORK and DOKAN_OPTION_CURRENT_SESSION set.

From my perspective, the SessionID obtained through GetCurrentSessionId(IoGetRequestorSessionId) appears to be a Process-based Session.

Therefore, I think that SessionID will be 0 even if the Windows service process performs impersonation.
Because Explorer's SessionID is 1 and GetCurrentSessionId's SessionID is 0, dokannp cannot find it because the SessionID does not match.

I don't know if my guess is correct.
If I'm correct, what I'm suggesting is that it would be nice to be able to pass the SessionID to dokan.
(This seems very complicated since a single Windows user can have multiple SessionIDs, which can be added or deleted.)

I use Google Translate, so please understand if anything is rude or strange.

Thank you.

[Liryna]

I agree that it would be great to have a way to pass which session to target but it would require some changes as we run some code that are thread session specific like https://github.com/dokan-dev/dokany/blob/9aa1570646dcddaa527ca040868c1fa8ea132348/sys/init.c#L814C14-L819
In the meantime, I can only propose to do a CreateProcessAsUser and process the mount in that new process which will have the correct sessionID as a workaround.

I have created #1196 as a feature request

[lanopk]

thank you so much.
If you need my opinion, help, or testing, please let me know.