Summary

When building UMDF drivers that must meet the DCHU “Universal driver” requirements, any use of Rust std that touches sys::random causes the binary to fail ApiValidator. The root cause is that Rust std (since rust-lang/rust#121337) calls ProcessPrng from bcryptprimitives.dll, which is not on the UniversalDDI whitelist. As a result, even trivial code that instantiates a default HashMap fails validation, blocking Windows Update publishing.

Why this matters

Universal compliance is required to publish via Windows Update. If windows-drivers-rs is intended for UMDF “Universal” scenarios, users currently must pin Rust to an older toolchain or avoid std features that depend on sys::random, both which are major limitations for production drivers.

Environment

• Driver model: UMDF (C++ host, integrating Rust)
• Windows SDK: 10.0.26100.6584 (25H2)
• ApiValidator: from the SDK above
• Toolchain: x86_64-pc-windows-msvc
• Rust
  • 1.76.0 → passes ApiValidator
  • 1.77.0+ (post Windows: Use ProcessPrng for random keys rust-lang/rust#121337) → fails ApiValidator

Minimal repro

// main.rs
use std::collections::HashMap;
fn main() {
    let _map: HashMap<i32, i32> = HashMap::new();
}

Build & validate:

> rustc main.rs -C target-feature=+crt-static
> ApiValidator -SupportedApiXmlFiles:"C:\Program Files (x86)\Windows Kits\10\build\10.0.26100.0\universalDDIs\x64\UniversalDDIs.xml" -ModuleWhiteListXmlFiles:"C:\Program Files (x86)\Windows Kits\10\build\10.0.26100.0\universalDDIs\x64\ModuleWhitelist.xml" -StrictCompliance:true -BinaryPath:"main.exe"

ApiValidation: Error: main.exe has unsupported API call to "bcryptprimitives.dll!ProcessPrng"
ApiValidation: Binary located at "main.exe" is NOT Universal

Observed behavior

• Rust std randomness on Windows calls ProcessPrng (via std::sys::random::windows::fill_bytes), which leads ApiValidator to flag bcryptprimitives.dll!ProcessPrng as unsupported for UniversalDDIs.
• Code paths that implicitly depend on randomness (e.g. std::collections::HashMap or DefaultRandomState) trigger the failure.

Expected behavior

• Using windows-drivers-rs in a UMDF Universal driver should not cause UniversalDDI violations solely due to std’s RNG choice.
• Ideally, std (or guidance/tooling around it) should use a Universal-allowed API (e.g., BCryptGenRandom from bcrypt.dll) when targeting Universal drivers, or avoid non-universal calls entirely.

Workarounds we found

• Pin Rust to 1.76.0 (pre-change): works, but clearly not sustainable long-term.
• Avoid RandomState by providing an explicit hasher (e.g., hashbrown::HashMap with BuildHasherDefault<...>): helps in some cases, but
  • it’s leaky/fragile (every dependency must avoid default HashMap/RandomState);
  • it doesn’t address other std features that might touch RNG; and
  • it shifts complexity to every user/dependency instead of providing a clean, supported driver profile.

What we’re asking from windows-drivers-rs maintainers

• Acknowledgement & guidance
  • Is this a known limitation for UMDF Universal targets?
  • Are there recommended profiles, feature flags, or crates/configs to ensure UniversalDDI compliance when using Rust?
• Docs or templates for Universal builds
  • A documented “Universal-safe” setup (including Cargo.toml guidance, #![no_std]/alloc recommendations if applicable, hash map alternatives, etc.).
  • A sample UMDF Universal project that validates cleanly with ApiValidator (25H2) using current stable Rust.
• Potential mitigation in this ecosystem
  • A windows-drivers-rs feature (or companion crate) that:
    • provides a Universal-safe RNG shim for getrandom/std (if possible without forking std), or
    • enforces compile-time lints to catch use of RandomState/other RNG-touching std features that would import ProcessPrng.
  • If mitigation must be upstream in Rust (since this lives inside std), would you be open to:
    • coordinating on an upstream issue proposing a Universal-compliant backend for Windows (e.g., falling back to BCryptGenRandom in bcrypt.dll when building for a “Universal” target triple or cfg); and/or
    • documenting the requirement here and linking to the upstream tracking issue?