Section 12: Symbolic Links and Device Namespace

The Big Picture: Real Names and Nicknames

At work, a person may have an official employee ID (E-004217) and a friendly nickname everyone uses ("Sam from accounts"). Both point to the same person. The ID is exact and unchangeable. The nickname is easy to remember.

Windows treats devices in the same way. Every device has an official internal name inside the kernel, and one or more friendly nicknames that programs use. The nickname is called a symbolic link.

All these names live in the Object Manager namespace: a big tree of names inside the kernel, a bit like a folder tree, but for kernel objects (devices, drivers, events, and so on). You can browse it with the free Microsoft Sysinternals tool WinObj.

 \                          (root of the object namespace)
 ├─ Device\                 real device objects live here
 │    ├─ HarddiskVolume3
 │    ├─ Harddisk0\DR0
 │    ├─ KeyboardClass0
 │    └─ ...
 ├─ Driver\                 driver objects (disk, kbdclass, ...)
 ├─ GLOBAL??\               symbolic links for programs (also reachable as \DosDevices)
 │    ├─ C:           ──►  \Device\HarddiskVolume3
 │    ├─ PhysicalDrive0 ─►  \Device\Harddisk0\DR0
 │    └─ ...
 └─ ...

12.1 Device Object Names (\Device...)

What it is: When a driver creates a device object (Section 4.4), it may give it a name inside the \Device\ folder of the object namespace. This is the official kernel-level name.

Examples:

Important notes:

• Names like HarddiskVolume3 are not stable: after adding a disk, the numbering may change. That is one reason Windows uses drive letters and volume GUID paths for users.
• Not every device object has a name. Many layers in a stack are unnamed. (Naming a device makes it easier for any program to attempt to open it, so careful drivers name only what they must and protect it with security settings.)
• A device name is for the kernel. A normal program can't open \Device\... directly with the usual Win32 calls. It needs a nickname (12.2).

12.2 Symbolic Links (\DosDevices, Drive Letters)

What it is: A symbolic link is an object that says "this name means that other name." Programs use these nicknames. In the namespace they live in a folder called \GLOBAL??. Windows also keeps a legacy alias called \DosDevices, which points to the same place (older documents and drivers use this name). They are the "DOS device names" Win32 programs know.

The best example of all is your drive letter:

  C:   ──symbolic link──►   \Device\HarddiskVolume3

C: is not a real thing. It is a nickname (a symbolic link) for the volume object \Device\HarddiskVolume3. When you ask for C:\Windows, Windows replaces C: by the real device name and sends the request to the file system on that volume. If you plug in a USB stick, Windows makes a new link, for example E: → \Device\HarddiskVolume9.

More examples:

Two special prefixes in Win32 paths:

Both \\.\ and \\?\ actually just point into \GLOBAL??, so \\.\PhysicalDrive0 really means \GLOBAL??\PhysicalDrive0, and that link leads to the device object.

Who makes the links? Often the driver (or the Mount Manager, a system component that handles drive letters) creates them when a device or volume appears. Removing the device removes the link.

See it (safe, read-only): Download WinObj from Microsoft's Sysinternals site (a free, official tool). Run it as administrator, open GLOBAL?? and find C:. Double-click it: the "SymLink target" shows \Device\HarddiskVolumeN. Alternatively, in a normal Command Prompt:

fsutil volume list

(that one may need admin rights) or, in PowerShell, to see the mapping of C: to its device:

(Get-CimInstance Win32_Volume | Where-Object DriveLetter -eq 'C:').DeviceID

This shows the volume GUID path, the permanent name of your C volume.

12.3 How Applications Open a Device via CreateFile

What it is: In Windows, everything that behaves like a file is opened with the same function: CreateFile. It opens real files, but also disks, serial ports, USB devices, pipes. The name decides which one.

Here is the journey of a program that opens \\.\PhysicalDrive0:

 1. Program:  CreateFile("\\.\PhysicalDrive0", ...)
        │
        ▼
 2. Win32 layer turns this into the kernel path  \GLOBAL??\PhysicalDrive0
        │
        ▼
 3. Object Manager follows the SYMBOLIC LINK ──► \Device\Harddisk0\DR0
        │
        ▼
 4. The I/O Manager finds the DEVICE OBJECT with that name,
    and from it the owning DRIVER OBJECT (Section 4)
        │
        ▼
 5. It builds an IRP_MJ_CREATE (Section 9) and sends it down the stack
    Security check: is this user allowed?   (the "access check")
        │
        ▼
 6. Success ──► the program gets back a HANDLE (a small number)

The handle is the program's ticket. Later calls use it:

DeviceIoControl deserves a special word. It is the "everything else" call: format a disk, eject a disc, read the temperature, ask a disk for its geometry. The program passes a control code (an agreed number) and the driver decides what it means. This is how programs talk to drivers in custom ways.

For devices without a fixed name. Many modern drivers (USB, HID, and so on) register a device interface: a GUID-based public name (class {GUID}) that programs can look up with the SetupAPI/CfgMgr functions. Windows then provides a symbolic link, such as \\?\HID#VID_046D&PID_C31C#..., which the program passes to CreateFile. This way, programs don't need to know the internal \Device\ names.

Security: The access check at IRP_MJ_CREATE is why a normal user can't open \\.\PhysicalDrive0 and read raw sectors. It requires administrator rights. A driver whose device object is too open can be a security hole, which is why drivers must set strict permissions on their device names.

Summary