As a regular reader of forums discussing technical problems with Windows components, I have been interested in the number of problems reported with connections to SMB file shares. I did not have the problem myself and I could not think of a way to reproduce and troubleshoot the problem(s).
There is a
Microsoft article entitled “Mapped network drive may fail to reconnect in
Windows 10, version 1809” which says:
Microsoft is working on a
resolution and estimates a solution will be available by the end of November
2018. Monitor the mapped drive topic in the Windows 10 1809 Update History KB
4464619.
The referenced KB article does not contain any relevant
information about progress on the problem.
It may seem irrelevant as this stage, but there was a
discussion on the answers.microsoft.com forum in 2020 about the “UseOptions”
value in the registry key HKCU\Network\<DRIVELETTER> - it seemed to be
causing problems with persistent connections and the value seemed to have been
introduced in Windows 10,
version 2004.
The authoritative source of information about SMB is the
Microsoft specification "[MS-SMB2]: Server Message Block (SMB) Protocol
Versions 2 and 3".
Section "3.2.4.2.2 Negotiating the Protocol" of
this document says:
When a new connection is
established, the client MUST negotiate capabilities with the server. The client
MAY<111> use either of two possible methods for negotiation.
The first is a multi-protocol
negotiation that involves sending an SMB message to negotiate the use of SMB2.
If the server does not implement the SMB 2 Protocol, this method allows the
negotiation to fall back to older SMB dialects, as specified in [MS-SMB].
The second method is to send an
SMB2-Only negotiate message. This method will result in successful negotiation
only for servers that implement the SMB 2 Protocol.
The reference <111> says:
The Windows-based client will
initiate a multi-protocol negotiation unless it has previously negotiated with
this server and the negotiated server's DialectRevision is equal to 0x0202,
0x0210, 0x0300, 0x0302, or 0x0311. In the latter case, it will initiate an
SMB2-Only negotiate.
It seems that older SMB servers (NAS devices and Windows
Server 2003) don’t expect a new connection to start with an SMB2-Only
negotiate. They can behave in various incorrect ways, such as returning an
error message, not responding at all, breaking the connection, etc., and this
results in different error messages being shown to the user.
It is often mentioned that there are anomalies when
referring to the file share by server name or server IP address – this is
caused by a dependency on which version of the path to the share has “remembered”
SMB2 capabilities.
There are many reasons why it might be necessary to “reconnect”
to a file share: the transport connections have an “idle timeout”, the client
may move between different networks or many other types of network interruption
may cause the connection to a file share to require reconnection. This means
that problems can occur at unpredictable times.
Another reason to “reconnect” a share is to restore
persistent file shares when a user logs in. The change in Windows 10, version 2004 seems to have been to “persist”
the knowledge of the server capabilities to the registry (rather than just
in-memory data structures in mrxsmb.sys). When persisting a share, Windows now
queries the attributes of the share with a call to NtQueryInformationFile, with
a FILE_INFORMATION_CLASS of FileRemoteProtocolInformation and stores this
information in the UseOptions value of the key HKCU\Network\<DRIVELETTER>.
The information returned by NtQueryInformationFile is a FILE_REMOTE_PROTOCOL_INFORMATION
structure and the ProtocolMajorVersion member contains the negotiated SMB major
version number. This enables Windows to decide whether it can use SMB2-Only negotiation.
struct FILE_REMOTE_PROTOCOL_INFORMATION
{
USHORT StructureVersion; // 1 for Win7, 2 for Win8 SMB3, 3 for Blue
SMB3, 4 for RS5
USHORT StructureSize; // sizeof(FILE_REMOTE_PROTOCOL_INFORMATION)
ULONG
Protocol; // Protocol (WNNC_NET_*) defined in
winnetwk.h or ntifs.h.
USHORT ProtocolMajorVersion;
USHORT ProtocolMinorVersion;
USHORT ProtocolRevision;
USHORT Reserved;
ULONG
Flags;
struct {
ULONG Reserved[8];
} GenericReserved;
union {
struct {
struct {
ULONG Capabilities;
} Server;
struct {
ULONG Capabilities;
ULONG CachingFlags;
UCHAR ShareType;
UCHAR Reserved0[3];
ULONG Reserved1;
} Share;
} Smb2;
ULONG Reserved[16];
} ProtocolSpecific;
}
Registry storage of remembered mapped network drives
The “remembered” mapped network drives are stored in the
registry under the key HKCU\Network. For each “drive letter” subkey under this
key, the following information can be stored:
ConnectFlags: a
REG_DWORD value containing a bit mask of values constructed from some of the CONNECT_*
definitions in winnetwk.h; in particular CONNECT_REQUIRE_INTEGRITY, CONNECT_REQUIRE_PRIVACY
and CONNECT_WRITE_THROUGH_SEMANTICS.
ConnectionType: a
REG_DWORD value containing a value taken from the RESOURCETYPE_* definitions in
winnetwk.h; in particular RESOURCETYPE_DISK.
DeferFlags: a REG_DWORD
value indicating whether interaction with the user is needed to restore the
connection (e.g. to obtain a password); the value 1 means that a password from
the user is needed, a value of 2 means that a password from the user might be needed and a value of 4 means
that default/stored credentials can be used (i.e. no need to ask the user for a
password).
ProviderFlags: a REG_DWORD value representation of a Boolean value
(0/1), indicating whether the RemotePath refers to a DFS root. If the
RemotePath is not a DFS root, this value is normally omitted.
ProviderName: a
REG_SZ value containing the provider name; in particular “Microsoft Windows
Network”.
ProviderType: a
REG_DWORD value containing a value taken from the WNNC_NET_* definitions in wnnc.h;
in particular WNNC_NET_SMB.
RemotePath: a
REG_SZ value containing the UNC path of the mapped network drive.
UseOptions: a
REG_BINARY value containing a sequence of Tag/Length/Value elements. The only “Tag”
that I have observed is “DefC”, the value of which is a FILE_REMOTE_PROTOCOL_INFORMATION
structure.
UserName: when
needed, a REG_SZ value containing the username; when not needed, a REG_DWORD
value containing 0.
Setting ProviderFlags as a partial workaround
Many reports can be found in the Internet that setting
ProviderFlags to 1 for a remembered mapped network drive can help and this
appears to be true. When ProviderFlags is set to 1, indicating that the
RemotePath refers to a DFS root, more DFS operations take place. The DFS driver
initially rewrites the RemotePath, replacing the share name with “IPC$” and
then asks the SMB driver to connect to this path so that a FSCTL_DFS_GET_REFERRALS
request can be sent to the server – the “remembered” SMB capabilities of the
server are not made available to the SMB driver for this call, so the SMB
driver performs a “multi-protocol negotiation”. The FSCTL_DFS_GET_REFERRALS request
fails with STATUS_FS_DRIVER_REQUIRED (if the RemotePath is not a DFS root) and
the SMB connection process continues – but, by now, the protocol has been
negotiated (via multi-protocol negotiation) and the network drive is
successfully mapped.
Most of the registry values for remembered mapped network drives
are updated when used – except the ProviderFlags value: it is only created/set
if the RemotePath is a DFS root. This allows misleading “workaround” information
(ProviderFlags = 1) to persist in the registry.
Invisible references to an SMB server
Unfortunately, deleting all references to a SMB server from
user mode is not guaranteed to remove
all recollection of the server from mrxsmb.sys. Under these circumstances,
attempts to unload mrxsmb.sys also fail/hang (such unload attempts normally
succeed). The unload attempt gets stuck here:
nt!KeWaitForSingleObject+0x233
rdbss!RxSpinDownOutstandingAsynchronousRequests+0x9d
rdbss!RxUnregisterMinirdr+0x1fc
mrxsmb!MRxSmbInitUnwind+0x123
mrxsmb!MRxSmbUnload+0x4e
nt!IopLoadUnloadDriver+0xdc065
The WPP ETW provider for mrxsmb.sys allows the reference
count for the SrvEntry for the server to be tracked, so it is possible (if
difficult) to check whether “hanging” references to a SrvEntry are preventing
the known workarounds from being effective.
Verifying whether this issue is active
One way of verifying whether this issue is active is to try
the following:
Issue the command:
logman start why -ets -p Microsoft-Windows-SMBClient Smb_Info -o why.etl
Try to access the
mapped network drive.
Issue the command:
logman stop why -ets
Issue the command:
wevtutil qe /f:text /lf:true why.etl | findstr "SMB.send SMB.receive"
The final command will show selected items from the trace
data; if there is a repeated sequence of “SMB send[0]: [NEGOTIAT]” items, then
the client is repeatedly trying SMB2-Only negotiation, failing and retrying –
this is the main characteristic of this problem.
Prospects
This problem affects Windows 2003 (among other SMB servers)
and there is no doubt in my mind that (parts of) Microsoft is fully aware of
the problem, its causes and its potential remedies. There is, however, a dearth
of authoritative information on this topic easily findable in the Internet.
The common workarounds for these problems include deleting
and recreating shares when problems occur, setting ProviderFlags to 1 and
deleting the UseOptions value for persistent shares (whenever it is
(re-)created). Without an option to disable the “SMB2-Only” optimization, there
are no ideal solutions.
