SYS File Documentation


Summary

A .sys file is a Windows System File, and on modern Windows it is almost always a kernel-mode device driver: low-level code that lets Windows talk to hardware. It is a Portable Executable binary (like an .exe or .dll) that starts with the bytes MZ, lives in C:\Windows\System32\drivers, and is loaded automatically at boot. You do not open or edit these; a .sys named in a blue-screen (BSOD) message is the driver Windows blames for the crash. Its MIME type is application/octet-stream. Deleting the wrong one can stop Windows booting.

Technical details

FeatureValue
Full nameWindows System File (dominant type: kernel-mode driver)
File extension.sys
MIME typeapplication/octet-stream
Format type (driver)Portable Executable (PE) kernel-mode binary
DeveloperMicrosoft (and hardware vendors)
Introduced1981 (MS-DOS used .SYS; modern NT drivers are PE binaries)
Typical locationC:\Windows\System32\drivers
Loaded byWindows kernel, at boot or on demand (ring 0)
Magic number4D 5A (“MZ”) at offset 0; 50 45 00 00 (“PE\0\0”) further in
Byte orderLittle-endian
Code signingRequired — usually Authenticode-signed, often WHQL-certified
PE subsystemNative (IMAGE_SUBSYSTEM_NATIVE, value 1)
Safe to open/editNo — managed by Windows; deleting one can break boot
Other .sys meaningsReserved blobs (pagefile.sys, hiberfil.sys, swapfile.sys); DOS text (CONFIG.SYS)
Related extensions.dll, .exe, .drv, .inf, .vxd
Specificationlearn.microsoft.com/windows/win32/debug/pe-format
File signature (magic bytes)
4D 5A

Offset 0, ASCII MZ — the DOS header shared by every Portable Executable, so a driver .sys begins exactly like an .exe or .dll. The 32-bit little-endian value at offset 0x3C (e_lfanew) points to the PE header, which starts with 50 45 00 00 (PE\0\0). What separates a driver from an application is the PE subsystem field, set to Native rather than Windows GUI/console. This signature applies only to driver-type .sys files; reserved data files such as pagefile.sys and plain-text CONFIG.SYS have no PE header.

What is a SYS file?

A .sys file is a Windows System File. The extension has marked system-level files on Microsoft platforms since MS-DOS in 1981, so it is not one single format. On modern Windows the dominant kind by far is the kernel-mode device driver: compiled code that runs inside the operating-system kernel and lets Windows communicate with a piece of hardware (a GPU, network adapter, storage controller, USB device) or provide a low-level service. Two other, unrelated things also use the extension: large reserved data files Windows manages for memory (pagefile.sys, hiberfil.sys, swapfile.sys), and legacy plain-text DOS configuration files (CONFIG.SYS, HIMEM.SYS). Because these are genuinely different files that happen to share an extension, this page treats the driver as the main subject and separates the others honestly below.

The practical headline for almost everyone: a driver .sys is not a document you open. Windows loads it. You never double-click it, and editing or deleting the wrong one can stop the machine from booting.

The driver as a Portable Executable

A Windows driver .sys is a Portable Executable (PE), the same binary container family as EXE and DLL files. It opens with the historical DOS header and its MZ magic, then a pointer leads to the PE header proper:

Offset 0x00:  4D 5A ...            DOS header ('MZ'), with a DOS stub program
Offset 0x3C:  e_lfanew (uint32)    little-endian offset to the PE header
[e_lfanew]:   50 45 00 00          PE signature ('PE\0\0')
              COFF file header     machine type, number of sections, characteristics
              Optional header      entry point, image base, Subsystem field
              Section table        .text, .data, .rdata, .reloc, .pdata ...

The field that distinguishes a driver from an ordinary program sits in the optional header: Subsystem. A user application is marked IMAGE_SUBSYSTEM_WINDOWS_GUI or _CUI; a kernel driver is marked IMAGE_SUBSYSTEM_NATIVE (value 1). A driver’s import table also links against kernel exports rather than the usual user-mode libraries: it imports from ntoskrnl.exe (the kernel itself) and from the Hardware Abstraction Layer (hal.dll), and its entry point is a DriverEntry routine that the kernel calls when the driver loads, not a main or WinMain. Because both an .exe and a .sys are PE files, you can inspect a driver’s headers, imports, sections and version resources read-only with a PE viewer such as PE-bear or Resource Hacker. That is analysis, not opening: you are reading the structure, not running or editing the driver.

Ring 0 execution and mandatory signing

A driver runs in kernel mode, privilege ring 0, with direct access to memory and hardware. That is what makes drivers powerful and also what makes a faulty one catastrophic: a bug in ring-0 code can corrupt kernel memory and halt the whole system rather than crashing a single app. To limit that risk, 64-bit Windows enforces driver code signing. A driver .sys carries an Authenticode digital signature, and hardware drivers are usually WHQL-certified (tested and signed through Microsoft’s Windows Hardware Quality Labs program). You can check a driver’s signature with Properties › Digital Signatures, or with Sysinternals Sigcheck, which reports the signer and whether the signature is valid. A genuine driver is signed by Microsoft or a recognised hardware vendor; an unsigned .sys sitting in an unusual folder deserves suspicion.

Reading a driver name in a blue screen

The most common reason people go looking at a specific .sys is a blue-screen crash (a bug check) that names one. When Windows halts with a message citing a file such as nvlddmkm.sys or storport.sys, it is naming the driver whose code was executing, or was implicated, when the fault occurred. That is a diagnostic clue, not an instruction to touch the file. The resolution is to identify which device the driver belongs to and then update, roll back or reinstall that driver, never to edit the binary. To identify it, right-click the .sys and read Properties › Details for the product and company strings, or search the exact filename. Then manage the driver through Device Manager or the vendor’s installer, and if a recent update triggered the crash, use Device Manager’s roll-back option.

The other .sys files: reserved blobs and DOS text

Not every .sys is a driver, and confusing the kinds causes real mistakes. Two families are worth knowing:

Reserved data files. pagefile.sys is the Windows paging file (virtual memory backing store); hiberfil.sys holds the compressed RAM image written when the PC hibernates; swapfile.sys backs the modern app-suspension mechanism. These are large regions Windows reserves and manages at the root of the system drive. They are not PE binaries, not programs, and not meaningfully “openable”. They also should not be deleted by hand: their size and existence are controlled through Windows settings (virtual-memory configuration and the hibernation feature), not by dragging them to the Recycle Bin.

Legacy DOS text. On MS-DOS and in the compatibility layers that followed, some .sys files are plain text. CONFIG.SYS is a startup script of directives; HIMEM.SYS was a real-mode memory-manager driver. A text-style .sys like CONFIG.SYS opens in any editor and could simply be renamed to .txt to read it, which is never true of a compiled driver.

This split is also why “convert a .sys” questions usually have no answer. A driver .sys and a DLL are both PE files but target different execution environments, so a kernel driver cannot be turned into a user-mode library; nor can it become a runnable .exe. And “convert to text” only makes sense for the DOS text files, which already are text.

Is a SYS file safe? Drivers, rootkits and BYOVD

Most driver .sys files are legitimate, signed Windows components and are perfectly safe. The genuine dangers are two, and both are about handling rather than the file merely existing.

The first is self-inflicted: deleting or editing the wrong driver. Because drivers are loaded during boot, removing one can disable hardware or leave Windows unable to start, and a corrupted driver binary can trigger the very blue screen you were trying to avoid. Let Windows Update and Device Manager manage drivers; do not hand-edit a .sys.

The second is malicious. Because a driver runs in ring 0, it is the deepest foothold malware can get. Rootkits install as .sys drivers to hide below the level ordinary security tools can see. A related technique is BYOVD (bring your own vulnerable driver): an attacker ships a genuine, correctly signed but security-flawed driver, loads it, and exploits its vulnerability to run their own code in the kernel, so the signature check passes yet the driver is abused. The defences are to distrust any unsigned or unexpected .sys in an odd location, to verify the signer (Properties › Digital Signatures, or Sigcheck), and to scan unknown files. A real Windows driver traces back to Microsoft or a known hardware manufacturer.

References