This blog post highlights a very specific detail of Microsoft’s implementation of SMB. It might help those, who try to get rid of SMB version 1 and support staff dealing with inaccessible file shares.

Summary for busy readers (tl;dr)

Windows 10 will offer SMB v1 when establishing a SMB session, even if SMB v1 is disabled. This allows the workstation (SMB client) to identify legacy systems which would only support SMB v1.

A server supporting only SMB v1 will elicit the message “System error 384” on the command line and a slightly misleading message in the Windows explorer.

Offering SMB v1 even if version 1 is disabled?

I know that SMB v1 is disabled on my workstation. Hence, I expect, that my workstation will not send out SMB v1 packets at any time. I was a bit puzzled when I sniffed an SMB session, since the workstation is still offering version 1 in the handshake:

Figure 1 – SMB Handshake

A quick check in the registry showed, that I had followed all the steps described by Microsoft. One page worth a bookmark is “How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server” at https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and

Checking the configuration

Fearing that I did not properly follow the instructions I checked my configuration. Since SMB v1 is controlled by a registry entry the registry editor is the obvious way. One of the lesser known features of Windows is the “Service Controller”. This command line utility gives full control over drivers and services. It turns out, that SMB version 1 is really disabled:

C:\>sc query mrxsmb

SERVICE_NAME: mrxsmb
        TYPE               : 2  FILE_SYSTEM_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

C:\>sc query mrxsmb10
[SC] EnumQueryServicesStatus:OpenService FAILED 1060:

The specified service does not exist as an installed service.

C:\>sc query mrxsmb20

SERVICE_NAME: mrxsmb20
        TYPE               : 2  FILE_SYSTEM_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

The Sysinternals Process Explorer (https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer) offers another way to check the configuration. When running with administrator privileges the Process Explorer can list the DLLs loaded in foreign processes. Pressing Ctrl-D will reveal all DLLs loaded in the selected process. “System” is a pseudo-process that represents the Windows kernel. Instead of DLLs we will see all loaded drivers. Guess what? MrxSmb10, which would handle SMB v1, is not present.

Figure 2 – Process Explorer

System Error 384

I was curious to find out, how my workstation would react to a legacy system. Here is the trace file:

Figure 3 – Workstation Trace

The client offers SMB v1 in the negotiate protocol request. Not knowing about SMB 2 or later the server selects this dialect in the response in frame 21. The workstation repeats the negotiate protocol request and gets the same answer. At this point the client gives up and presents an error message.

On the command line we see a “System error 384”:

Figure 4 – Error 384 on the command line

The Windows explorer unfortunately gives a somewhat misleading error message:

Figure 5 – Explorer Error Message