How Windows 3.11 Disconnects Network Drives

In Microsoft Windows 3.11, specifically Windows for Workgroups 3.11, network drive disconnections were managed through a cooperative architecture between 16-bit graphical interfaces and 32-bit protected-mode network redirectors. When a user or application requested a drive disconnection, the operating system checked for active file locks, sent Server Message Block (SMB) termination packets to the host, updated internal DOS drive tables, and refreshed the interface to release the allocated drive letter.

Initiation Methods

Disconnections were initiated primarily through three methods:

  1. File Manager: Users accessed the "Disk" menu and selected "Disconnect Network Drive," presenting a dialog listing currently mapped remote shares.
  2. Command Line: The MS-DOS prompt allowed users to execute NET USE [drive:] /DELETE.
  3. Application APIs: Programs invoked Windows Network APIs, specifically functions such as WNetCancelConnection or WNetCancelConnection2 exported by USER.EXE and forwarded to network driver dynamic link libraries.

Verification and Open File Handling

Before severing a connection, Windows 3.11 inspected active file locks and open file handles on the target volume. Because Windows 3.11 operated in an environment where MS-DOS handles and Windows protected-mode virtual machines overlapped, an abrupt disconnection could cause data corruption.

If files or executables on the mapped drive were in use, the system triggered a confirmation prompt warning the user that active files would be closed and data could be lost. If the user opted to force the disconnection (or if the /YES flag was passed via the command line), the operating system forcefully closed local file handles associated with that drive letter.

The Redirector and Network Protocol Teardown

Windows for Workgroups 3.11 introduced a 32-bit protected-mode file system architecture driven by IFSHLP.SYS (Installable File System Helper) and VREDIR.386 (the 32-bit network redirector).

Once validated, the process followed these steps:

  • SMB Termination: VREDIR.386 generated an SMB Tree Disconnect (SMB_COM_TREE_DISCONNECT) request. This packet was transmitted over the transport protocol (commonly NetBEUI, NWLink, or TCP/IP via NetBIOS) to the remote server, indicating that the client was relinquishing access to the resource.
  • Session Cleanup: The server acknowledged the request, decremented its active client count for that share, and released server-side resources. If no other shares were mapped to that server, the underlying NetBIOS session was eventually closed.

Modifying the Local Drive Table

After the network-level disconnection succeeded, Windows 3.11 had to update local file system structures:

  • Current Directory Structure (CDS): In the underlying DOS architecture, mapped drives were represented as network flags within the Current Directory Structure table. The redirector cleared the network bit for that drive letter and reset the path buffer.
  • IFS Manager Notification: The Installable File System manager detached the drive letter from VREDIR.386, returning the letter to an unallocated state so it could be assigned to local media or subsequent network connections.

Interface Notification

Finally, Windows broadcast an internal notification signaling the change in drive availability. File Manager captured this event, removed the disconnected drive icon from its drive bar, and closed any active directory windows associated with that path.