‘_ReadWriteBarrier’ : cannot be found in “wdm.h”

by

Summary

A developer building their first kernel driver encounters a build error where _ReadWriteBarrier is not found in wdm.h. This occurs after creating an empty Kernel Mode Driver project in Visual Studio 2022 using the standard WDK installation guide. The root cause is missing or incorrect include paths and target OS version mismatches, which prevents the compiler from resolving critical intrinsic definitions required by the Windows Driver Kit (WDK). The fix involves verifying the WDK installation, correcting project properties, and ensuring Windows SDK alignment.

Root Cause

The error arises from the build environment failing to locate the intrinsic definition for _ReadWriteBarrier—a compiler barrier used for memory ordering in kernel code. This is rarely a bug in the WDK itself but a configuration issue in the Visual Studio project.

  • Missing WDK Include Paths: The Visual Studio project does not include the WDK include directory in its Additional Include Directories. Without this, the compiler cannot find wdm.h or the underlying headers it depends on.
  • Target OS Version Mismatch: If the project targets an older OS version (e.g., Windows 10 20H2) but the installed WDK is newer (e.g., for Windows 11), definitions in wdm.h may be conditionally excluded or aliased differently.
  • Visual Studio Project Template Corruption: The “Empty Kernel Mode Driver” template sometimes fails to inherit global WDK environment variables (like $(KM_FLaPS)) correctly, leaving paths blank.
  • Obsolete or Preview WDK: Using a preview release of the WDK or an outdated SDK can cause header mismatches where intrinsics like _ReadWriteBarrier are defined in a different context or deprecated in favor of C++11 atomics (though legacy code still expects the intrinsic).

Why This Happens in Real Systems

In real-world driver development, build environments are complex and often scripted. This specific error is a symptom of environment drift.

  • Dependency Hell: Kernel development relies on a precise pairing of Visual Studio version, Windows SDK, and WDK. A Windows Update might update the SDK without updating the project configurations.
  • Inheritance Issues: MSBuild projects rely on .props (property sheets) files. If the user.props file is missing or the WDK buildcommon.props isn’t imported correctly, the IncludePath variable becomes invalid.
  • Compiler Evolution: Visual Studio 2022 uses MSVC v143, which handles intrinsics differently than older compilers. If the WDK headers were written for an older compiler, there can be conflicts regarding intrinsic availability.

Real-World Impact

  • Blocked Development: The driver cannot be built, halting all testing and implementation work.
  • Misleading Error Messages: The error points to wdm.h, which suggests a corrupted WDK installation. Often, the WDK is fine, but the IDE simply isn’t looking at the right files.
  • Toolchain Fatigue: Junior engineers often spend days reinstalling the entire WDK/Visual Studio rather than fixing a single path variable, wasting significant engineering hours.
  • Team Onboarding Friction: This is the #1 blocker for new kernel developers, causing frustration and making the learning curve seem artificially steep due to tooling rather than logic.

Example or Code

This error typically manifests in a C++ source file included in a standard Kernel Mode Driver project. There is no functional code to “fix” here, as the code itself is valid. The issue is the environment.

Standard Driver Entry Point (The code that triggers the error):

#include 

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
    UNREFERENCED_PARAMETER(DriverObject);
    UNREFERENCED_PARAMETER(RegistryPath);

    // This intrinsic is referenced by ntifs.h macros
    return STATUS_SUCCESS;
}

How Senior Engineers Fix It

Senior engineers treat this as a configuration issue, not a code bug. They follow a systematic verification of the toolchain.

  1. Verify WDK Installation: Ensure the correct WDK version for the target OS is installed. For VS2022, this is usually the “Windows 11 WDK” or “Windows 10 WDK”.
  2. Check Project Properties:
    • Open Project Properties -> General.
    • Ensure Target OS Version and Target Platform Version match the installed WDK.
    • Verify Configuration Type is set to Driver.
  3. Validate Include Directories:
    • Go to C/C++ -> General -> Additional Include Directories.
    • Ensure $(KM_FLaPS)\Include\um and $(KM_FLaPS)\Include\shared are present. If $(KM_FLaPS) is undefined, the WDK extension for VS is not loaded correctly.
  4. Force Inclusion: As a temporary fix, manually add the WDK include path (e.g., C:\Program Files (x86)\Windows Kits\10\Include\10.0.xxxxx.0\km) to the project settings.
  5. Recreate the Project: If the template is corrupted, create a new project using the Windows Driver Template (WDT) or Empty Driver template to ensure the .vcxproj file is generated with the correct WDK targets.

Why Juniors Miss It

Junior developers often lack the context of how the Windows build system integrates with Visual Studio.

  • Visual Studio Illusion: They assume that creating a “Kernel Driver” project in the IDE automatically configures all necessary paths. They don’t realize the template relies on specific environment variables being set during VS installation.
  • Header Confusion: They interpret “Cannot find X in Y” as a missing file in the source code, leading them to search for _ReadWriteBarrier to download it, rather than checking compiler paths.
  • Version Blindness: They may install the latest WDK (e.g., for Windows 11) but set their project target to “Windows 10” without realizing that header definitions changed between those versions.
  • The Reinstall Trap: They default to uninstalling/reinstalling VS or the WDK, which takes hours, instead of checking a few text boxes in the Project Properties menu.