Fact-checked by Grok 2 weeks ago

INF file

An INF file, or setup information file, is a plain-text used in Windows operating systems to provide instructions for hardware drivers, software components, and device configurations. It directs the operating system on tasks such as copying files to specific directories, modifying the , installing services, and applying device-specific settings to ensure proper functionality. INF files are structured as a series of named sections enclosed in square brackets, such as [Version] for compatibility details and [Manufacturer] for identifying device vendors, with case-insensitive entries that include directives (e.g., AddReg for registry additions) and data values separated by commas. Each section serves a distinct purpose, such as [CopyFiles] for file installation, [SourceDisksNames] for specifying source media, and [Strings] for defining replaceable string tokens like %ManufacturerName% to support multilingual or multi-platform adaptability. Comments begin with a semicolon (;), empty lines are ignored, and line continuations use a backslash (\), allowing for complex, multi-line directives while adhering to a maximum field length of 4096 characters. These files are integral to packages, often generated from intermediate INX files using tools like the Stampinf utility to insert variables for different Windows versions, architectures, or frameworks, enabling a single source file to produce multiple tailored INF variants. Extension INF files allow independent updates to base packages without altering core functionality, supporting modular maintenance for evolving needs. While primarily associated with device installation via the Setup API, INF files can also handle broader setup tasks like updates and event log configurations, making them a foundational element of Windows deployment processes.

Introduction

Definition and Purpose

An INF file, short for setup information file, is a plain-text in an INI-style format used by Windows to provide automated instructions for installing devices and software. It serves as a key component in driver packages, containing essential details such as device descriptions, driver file names, and installation directives that Windows device installation components rely on to configure and bring hardware or applications online. The primary purposes of an INF file include specifying one or more device drivers to support hardware, copying necessary files to system directories, editing the for configuration settings, creating desktop or shortcuts, and facilitating hardware enumeration for (PnP) devices through hardware identifiers. These functions enable seamless integration of peripherals and software without user intervention during setup. For PnP devices, the file maps hardware IDs to appropriate drivers, ensuring automatic detection and installation. For broader software deployments, it orchestrates file placement, registry modifications, and shortcut generation to complete application setup. INF files integrate directly with the Windows Setup API, acting as input to functions like SetupCopyOEMInf, which copies third-party INF files into the system's driver store, and InstallHinfSection, which executes specific sections of the file to perform tasks such as file operations and registry updates. This API-driven approach allows for programmatic control over deployments. In contrast to (EXE) installers, which run compiled code to execute installations, INF files are declarative and fully human-readable, promoting transparency and facilitating silent, scripted, or automated deployments in enterprise environments or during Windows imaging processes.

Historical Development

The origins of INF files trace back to the early days of Windows, where they emerged as setup information files used in installation scripts. In , released in 1992, SETUP.INF served as a key component for guiding the operating system's process, providing details and file copying instructions in a structured text format. This initial use established INF files as a foundational mechanism for , though limited to basic setup tasks. The format was formalized and expanded with the release of in 1995, coinciding with the introduction of () support for hardware devices. INF files became essential for device driver installation, containing hardware identification, file placement, and registry configuration data to enable automatic detection and setup of peripherals without user intervention. This milestone marked the first widespread adoption of INF files for hardware-centric operations, transforming them from setup utilities into core elements of the Windows driver ecosystem. Subsequent evolutions aligned INF files with advancing driver architectures. In , released in 2000, the format integrated deeply with the Windows Driver Model (WDM), mandating a Version section in all INF files to specify compatibility and OS targeting, which facilitated binary-compatible drivers across and NT-based systems. This integration supported signed drivers, enhancing security by allowing verification of driver authenticity during installation. Windows Vista, launched in 2007, imposed stricter validation through mandatory driver signing policies, requiring driver packages—including their INF files and accompanying catalog (.cat) files—particularly for 64-bit systems, to be digitally signed to prevent unsigned kernel-mode code from loading. This enforcement, building on Windows 2000's foundations, reduced malware risks associated with drivers and prompted developers to adopt catalog (.cat) files alongside INF for integrity checks. In and later versions, starting from 2015, INF files extended to support (UWP) applications by enabling driver pairing, where INF directives like AddSoftware link hardware drivers to app packages for seamless integration in modern deployment scenarios. Tools such as MSIX for app packaging further leveraged INF-like structures indirectly through driver extensions, allowing modular updates without full reinstalls. Extension INF files, introduced in , permitted overriding inbox drivers with vendor-specific enhancements, promoting flexibility in the evolving ecosystem. These developments shifted Windows installations from manual, error-prone processes to automated, driver-centric workflows, significantly reducing user intervention and improving system reliability across hardware and software deployments. By prioritizing security and modularity, INF files have remained a cornerstone of Windows compatibility, adapting to decades of hardware innovation.

File Format

Overall Syntax

An INF file is a file, encoded in either ANSI or Unicode (UTF-16 LE) format, with Unicode preferred for better internationalization support. The file's structure consists of sections delimited by square brackets, such as [SectionName], where each section contains zero or more lines of key-value pairs in the format key=value or directive statements that reference other sections or provide installation instructions. Section names and keywords are case-insensitive, allowing flexible authoring while ensuring consistent parsing by the Windows Setup API. Parsing follows strict line-based rules to maintain compatibility across Windows versions. Comments begin with a semicolon (;) and extend to the end of the line, ignored by the parser unless enclosed in quotes; empty lines or those starting with a are skipped. Strings containing spaces or special characters, such as file paths, must be enclosed in double quotes ("), and to include a literal or within a quoted string, it is escaped by doubling it (e.g., "" for a quote). Lines can be continued onto the next by ending with a (\), which is particularly useful for multi-line values like registry entries or file lists, where the continuation line begins immediately after the backslash without spaces. Supported data types in INF files include strings (either literal or tokenized as %strkey% for from the [Strings] section), numeric values in or format (prefixed with 0x, such as 0x01 for flags), and references to other sections (e.g., [DestinationDirs] to specify directories). Multi-line values are handled by the entire entry and using backslashes for continuation, ensuring complex data like script blocks remains intact during parsing. Field lengths are limited to 4096 characters before and after string substitution, including the terminator. The Windows Setup API processes INF files with built-in error tolerance: malformed lines are ignored, but warnings are logged to aid , while validation tools enforce stricter rules like prohibiting duplicate keys within a to prevent ambiguous installations. Duplicate names are merged rather than treated as errors, combining their contents sequentially. Every INF file must include a [Version] , conventionally placed first, to declare compatibility and metadata; the required Signature="$WINDOWS NT$" entry (case-insensitive, with literal dollar signs) signals support for modern Windows operating systems, distinguishing it from legacy formats. For Plug and Play (PnP) device drivers, this section must also include required keys such as Class, ClassGuid, Provider, and DriverVer for device classification, vendor identification, and versioning.

Sections and Directives

INF files are structured using named sections enclosed in square brackets, with directives within those sections specifying actions. Standard sections provide essential and mappings, while directives handle tasks like operations and registry modifications. These elements enable the declarative description of processes, particularly for device drivers on Windows systems. The [Version] section is mandatory and contains metadata such as the file's signature, class, provider, and driver version. It must include a Signature key, typically set to "Windows NT" for Windows compatibility, along with required entries for PnP drivers such as Class for device category, ClassGuid for the class identifier, Provider for the vendor name, and DriverVer in the format "MM/DD/YYYY,version.number". For example: 
[Version]
Signature="$Windows NT$"
Class=USB
ClassGuid={36fc9e60-c465-11cf-8056-444553540000}
Provider=%ManufacturerName%
DriverVer=01/01/2025,1.0.0.0
This section validates the INF for use on Windows 2000 and later. The [Manufacturer] section serves as a , mapping vendor names to corresponding [Models] sections. It lists entries like %CompanyName%=CompanyModelsSection, where %CompanyName% is a localized and CompanyModelsSection references the models for that vendor. This structure allows INF files to support multiple manufacturers. The [Models] section, required for each manufacturer entry, associates hardware IDs with installation sections. Entries follow the format %DeviceDescription%=InstallSection,HardwareId, where HardwareId is a device identifier like PCI\VEN_1234&DEV_5678, and InstallSection points to a DDInstall section. This enables hardware-specific installations. For instance: 
[CompanyModels]
%USBDevice%=USBInstall,USB\VID_1234&PID_5678
The [Strings] section is required in every INF file and defines string tokens (%strkey%) used for localizable text such as device and manufacturer names. Entries are in the format strkey="string value", allowing substitution throughout the INF for . For example: 
[Strings]
ManufacturerName="Example Corp"
USBDevice="Example USB Device"
This enables support for multiple languages by using language-specific INF variants or external string files. The [DestinationDirs] section defines target directories for files copied during installation, using numeric IDs (e.g., 10 for %SystemRoot%\system32\drivers). It supports default paths and overrides, such as DefaultDestDir=10 for drivers. This section is required when CopyFiles directives are used. [SourceDisksNames] and [SourceDisksFiles] sections manage source media. [SourceDisksNames] identifies disks with entries like 1="Installation Disk",,\path\to\files, assigning IDs to media sources. [SourceDisksFiles] maps files to these IDs, e.g., driver.sys=1, ensuring the installer locates files from the correct media. Both are required for file-based installations. Core directives within sections perform specific actions. The CopyFiles directive references a section listing files to copy, using the syntax CopyFiles=FileSectionName; this transfers files from source media to destinations specified in [DestinationDirs]. For example, in a DDInstall section: CopyFiles=DriversSection. The AddReg directive adds or modifies registry entries by referencing an add-registry section. Entries use the format HKLM,subkey,value-name,flags,data, where HKLM denotes HKEY_LOCAL_MACHINE. Flags specify types like 0x00000000 for REG_SZ (). An example in a registry section: 
[RegSection]
HKLM,%ServiceRoot%,"DisplayName",0x00000000,"My Device"
HKLM,%ServiceRoot%,"ErrorControl",0x00010001,1
Here, %ServiceRoot% expands to a path like System\CurrentControlSet\Services, and 0x00010001 indicates REG_DWORD. This directive is essential for configuring properties. DelReg performs the opposite, deleting registry entries via a similar syntax in a del-registry section, such as DelReg=OldEntriesSection. It is used for cleanup but is not supported in universal INF files for Windows Driver Packages. AddService installs services by referencing a service-install section, with syntax AddService=ServiceName,Flags,ServiceSection; flags like 0x00000002 ensure 32-bit handling on 64-bit systems. This is critical for kernel-mode drivers. UpdateIniFields updates legacy INI files, specifying sections like UpdateIniFields=IniSection for adding or modifying fields, though its use has diminished with the shift to the registry. Device-specific sections include [DDInstall], which outlines core installation steps like file copies and registry updates, often containing directives such as CopyFiles and AddReg. It is referenced in [Models] for matching, e.g., %HardwareId%=DDInstallSection. Platform variants like [DDInstall.NT] handle OS-specific logic. The [DDInstall.Services] subsection, nested under [DDInstall], configures driver services with directives like AddService. It is required for and later to define service parameters such as start type and error control. Hardware ID matching in [Models] routes to these sections for targeted execution. Registry operations in AddReg support HKEY_LOCAL_MACHINE for system-wide changes, with structures allowing subkey creation and value assignment. Flags like 0x00000000 (REG_SZ) denote string data, while 0x00010001 (REG_DWORD) handles numeric values. Examples include appending to multi-string values or setting , ensuring precise without overwriting existing entries unless specified. Conditional directives enable logic-based installations. The If directive applies actions based on conditions like processor architecture or OS version, e.g., [IfIA64] CopyFiles=IA64Files. UpdateIniFields can also incorporate version checks for legacy compatibility. These allow INF files to adapt to diverse environments.

Usage

Device Driver Installation

INF files are integral to the Windows Plug and Play (PnP) architecture, enabling the automatic detection and installation of device drivers by matching hardware identifiers (IDs) from newly connected devices to predefined sections in the INF file. The PnP Manager, upon device arrival via a bus driver (such as USB or PCI), queries the device's hardware IDs—vendor-defined strings like PCI\VEN_8086&DEV_1234 for a PCI device—and compatible IDs, then searches the driver store for matching INF files that declare support for these IDs in sections such as [Models]. This matching process ensures the correct driver package is selected without user intervention, triggering the loading of the appropriate kernel-mode or user-mode driver components. As of May 2025, Microsoft announced the deprecation of legacy device metadata formats, urging the use of INF files for modern driver packages, with access to old formats restricted after December 2025. The installation flow begins with the notifying the PnP Manager of the new , followed by ID enumeration and INF file matching. Once matched, the PnP Manager processes the INF's DDInstall section, executing directives like CopyFiles to copy driver binaries and supporting files to the system directories, AddReg to configure registry keys for device parameters, and AddService for installing required system services. For programmatic control, applications or installers leverage SetupDi functions from the SetupAPI, such as SetupDiInstallDevice, to initiate INF-based installations, enumerate devices, or handle custom installation logic while adhering to the PnP sequence. This structured process minimizes conflicts and ensures devices are fully operational post-installation. Driver security relies on digital signing enforced through the Windows Hardware Quality Labs (WHQL) certification process, where approved INF files are bundled with catalog files (.cat) containing cryptographic hashes and signatures to validate the integrity of all package files against tampering. environments block unsigned drivers to prevent malicious code, but developers can enable test signing mode via boot options (e.g., bcdedit /set testsigning on) to install and test non-certified packages, displaying a on the as a visual indicator. For driver updates, the Device Manager uses INF files to upgrade existing installations by matching improved hardware IDs or compatible IDs, re-executing relevant directives while preserving user configurations where possible. Uninstallation is supported through optional [DDInstall.Uninstall] sections in the INF, which invoke DelFiles to remove installed files and DelReg to clean up registry entries, often triggered manually via or programmatically with SetupAPI calls like DiUninstallDriver. This ensures clean removal without residual artifacts that could affect system stability. A representative example of hardware ID mapping appears in the [Models] section for a USB device, as follows: 
[Models]
%USB\VID_045E&PID_00B.DeviceDesc% = USB_Install, USB\VID_045E&PID_00B
Here, USB\VID_045E&PID_00B is the hardware ID (with VID for vendor ID and PID for product ID), mapped to the USB_Install section for installation instructions, and %USB\VID_045E&PID_00B.DeviceDesc% references a localized device description string.

Software Installation

INF files enable the installation of software packages, applications, and components by providing declarative instructions for tasks such as file copying, registry modifications, and shortcut creation, without relying on hardware enumeration processes. These files are processed by the (SetupAPI), which interprets sections like [DefaultInstall] to execute operations during installation. For standalone software deployment, an INF file can specify source and destination paths for files, define registry keys and values, and configure elements, making it suitable for simple or applications. In setup packages, INF files integrate with Installer () packages through custom actions that invoke SetupAPI s to process the INF during the MSI execution sequence. For instance, a custom action in an MSI can call the InstallHinfSection function via rundll32.exe to handle INF-based operations, allowing hybrid installations where MSI manages core application files while the INF addresses supplementary elements like system DLLs or configuration entries. Standalone INF files remain relevant for applications, where they directly manage file deployment and without an MSI wrapper. Broader applications include the historical role of INF files in (setup.exe), where they orchestrate the of operating system components by coordinating file placements and service registrations during initial OS deployment. Modern tools like the (winget) and App Installer employ manifest files with structural similarities to INF, using declarative formats to specify instructions, though they extend beyond INF's scope with support for additional package sources and mechanisms. INF files continue to support hotfixes, security updates, and third-party utilities, often bundling necessary files and registry changes for targeted system modifications. Silent installation of INF files is achieved by invoking the InstallHinfSection function through rundll32.exe setupapi.dll,InstallHinfSection, specifying a section name, installation flags (e.g., 128 to set the default path to the INF file location), and the INF path. For example, the command rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 C:\path\to\app.inf processes the file, with UI behavior depending on the INF content; to minimize prompts, ensure no UI directives are present in the INF. Logging details to %windir%\setupapi.app.log if enabled. MSI extensions can incorporate similar processing via custom actions with msiexec /quiet, ensuring unattended deployment in enterprise environments. Post-Windows XP, INF files for general software have become less prevalent due to the dominance of and MSIX formats, which offer richer features like , patching, and dependency management. However, INF remains viable for lightweight updates, hotfixes, and scenarios requiring precise control over file and registry operations without the overhead of full installer frameworks. A representative example of an INF snippet for software might include a [DefaultInstall] section to copy DLLs and add items: 
[Version]
Signature="$Windows NT$"
Provider=%ProviderName%

[DefaultInstall]
CopyFiles=AppFiles
AddReg=AppReg
ProfileItems=StartMenuItems

[AppFiles]
example.dll,,,COPYFLG_NOPRUNE

[AppReg]
HKLM,"Software\ExampleApp","Version",,"1.0"

[StartMenuItems]
example.lnk,example.exe,%11%\example.exe,,,"Example Application",%IconPath%

[Strings]
ProviderName="Example Corp"
IconPath="%SystemRoot%\system32\shell32.dll"
This configuration copies example.dll to the system directory, adds a registry key under HKLM, and creates a shortcut in the Start Menu's Programs folder pointing to example.exe, using standard directives for file handling and integration.

Creation and Maintenance

Authoring Process

The authoring process for an INF begins with careful to ensure the aligns with the intended target and requirements. Developers must first identify whether the INF is for a or software application , as this determines the necessary sections and directives. For s, key actions include listing files to copy, registry entries to modify, services to install or configure, and defining IDs to match specific devices. Software installations focus more on file placement and registry operations without -specific elements. This phase involves outlining all required operations to avoid omissions that could lead to incomplete installations. Once planning is complete, writing the INF file follows structured guidelines to maintain compatibility and correctness. The process starts with the mandatory [Version] section, which specifies the Signature (e.g., "Windows NT" for Windows NT-based systems) and other metadata, including the DriverVer for versioning (e.g., DriverVer=01/01/2025,1.0.0.0), followed by the [Manufacturer] section to define device vendors and models. Developers are recommended to base their files on templates from official Microsoft sample drivers, adapting them to the specific needs while preserving standard syntax. All INF files must be saved in Unicode (UTF-16 LE) encoding to support international characters and localization, though ANSI is permitted for legacy compatibility. Standard sections, such as [SourceDisksNames] and [DestinationDirs], should be included with platform-specific variants (e.g., .amd64 for 64-bit systems) to handle multi-architecture deployments. Best practices emphasize modularity and portability to enhance reusability and reduce errors. Sections should be organized modularly, separating platform-dependent logic (e.g., using .ntx86 suffixes) to allow the INF to target multiple environments without duplication. Hard-coded paths, such as absolute directory locations, must be avoided in favor of environment variables like %SystemRoot% to ensure adaptability across systems. Testing the INF on various Windows versions, from current releases back to supported legacy ones, verifies broad compatibility. For localization, the [Strings] section should define replaceable string keys (e.g., StrKey="Localized Text"), referenced elsewhere with %StrKey% to enable easy translation without altering core logic. Common pitfalls in authoring can lead to installation failures or parse errors, underscoring the need for precision. Mismatched hardware IDs in the [Models] section, such as incorrect or product identifiers, prevent Windows from associating the INF with the target device, resulting in failed driver matching. Improper quoting around strings or values (e.g., omitting quotes for paths with spaces) causes syntax errors during . In older Windows versions like , exceeding the 64 KB file size limit could halt processing, though this is less relevant in modern systems with higher limits. The authoring process is iterative, involving manual editing in editors to refine the file structure and . After initial drafting, developers perform dry-run validation to check for syntax issues and logical inconsistencies without executing the . This cycle of , validate, and revise continues until the INF passes all checks, ensuring reliability before deployment.

Tools and Validation

The (WDK), successor to the Device Driver Kit (DDK), provides essential command-line tools for validating and testing INF files during driver development. InfVerif.exe performs syntax checking and verifies compliance with INF requirements and restrictions by the through the operating system's INF parser, reporting errors such as invalid directives or structural issues. As of 2025, InfVerif includes a /h option for WHQL-aligned validation. For comprehensive validation, developers run InfVerif with the /w option to include warnings, and /u to confirm universal INF applicability across architectures and OS versions. ChkInf, a legacy Perl-based script from earlier DDK versions, offers semantic validation by examining INF content for logical consistency, though it has been largely superseded by InfVerif in workflows. DevCon.exe, included in the WDK, enables test installations of drivers via INF files without full deployment, allowing developers to simulate enumeration and driver on a local machine. For example, the command devcon install path_to_inf hardware_id creates a node and applies the INF, facilitating iterative testing before broader integration. Third-party text editors enhance INF authoring with features tailored to the file's INI-like structure. Notepad++ applies built-in INI syntax highlighting to INF files, color-coding sections, keys, and values for improved readability during manual edits. , when extended with WDK integration, offers driver project templates that auto-generate INF files from INX sources, providing IntelliSense for directives and validation during build processes. Validation extends to WHQL compliance testing using the Windows Hardware Lab Kit (HLK), which incorporates INF verification as part of driver package ; formerly known as the Windows Hardware Certification Kit (HCK), it scans for adherence to signing and installation standards before submission. The HLK was updated in May 2025 to support 24H2 and 2025. Developers can simulate INF-based installations programmatically via the SetupCopyOEMInf API, which copies the file to the system INF directory (%Windir%\Inf) and triggers parsing without hardware presence, aiding pre-deployment checks. In contemporary environments, the HLK framework automates driver testing, including INF-driven installations across test harnesses to ensure compatibility with Windows versions. provides inspection capabilities through cmdlets like Get-PnpDevice and Get-WmiObject -Class Win32_PnPSignedDriver, which query installed drivers and reveal associated INF details such as original file paths and signing status. For debugging failed installations, SetupAPI logs in %Windir%\Inf\Setupapi.dev.log capture detailed traces of INF processing, including error codes for issues like directive failures or file mismatches. These logs, enabled by default in and later, support levels from errors-only to verbose output via registry settings, enabling root-cause analysis of deployment problems.