Driver status UNKNOW_PROBLEM — UMDF host rejects driver at level 0 (0xD000000D), Win10 19041, survives full driver/device/registry rebuild

[silty-roach]

Hi, sorry for the AI write up but I'm clueless when it comes to this stuff and claude has been the only way i've been able to troubleshoot and make an error write up with actual details of what my error is.

Driver status UNKNOW_PROBLEM — UMDF host rejects driver at level 0 (0xD000000D), Win10 19041, survives full driver/device/registry rebuild
Environment
Windows 10 Pro N 2004 (build 19041.1415), x64
GPU: NVIDIA GTX 1070 Ti (tested on driver 582.66 and rolled back to 582.28 — identical failure)
ParsecVDisplay v0.45 (driver mm.inf, DriverVer 01/25/2024, 0.45.0.0)
HVCI/memory integrity: off · Driver Verifier: off · Secure Boot machine, Code Integrity log clean
The same driver version worked on this exact machine from 2026-05-15 until the incident below.
Timeline
Driver worked for ~3 months (installed 2026-05-15).
During a period of heavy system-wide RAM/IO load, the UMDF host crashed while a virtual monitor was being attached. Kernel-side provider Parsec Virtual Display Driver logged Monitor creation ... STATUS_SUCCESS and Device attached ... STATUS_SUCCESS, and in the same second Microsoft-Windows-DriverFrameworks-UserMode logged event 10110 ("hosting process has been terminated") + 10111 ("offline due to a user-mode driver crash, Windows will attempt to restart the device 5 more times").
Since then — across many reboots — the device never starts again. ParsecVDisplay shows UNKNOW_PROBLEM.
Failure signature (captured with the DriverFrameworks-UserMode operational log)
Device is ROOT\DISPLAY\0000, Problem Code 31 (CM_PROB_FAILED_ADD), Problem Status 0xC0000001.

Event sequence on every start attempt:

2001/1004 UMDF Host Process started successfully
2003 asked to load drivers for device ROOT\DISPLAY\0000
2004 loading driver ParsecVDA at level 0
2005 (xN) loaded modules: mm.dll, iddcx.dll, WUDFx02000.dll, dxgi, d3d11, d2d1, DWrite, ...
2007 "The UMDF Host failed to load the driver at level 0.
The error reported was 3489660941." <-- 0xD000000D (INVALID_PARAMETER)
1006/2900/2901/1008 host shutdown
Notable: zero ETW events are emitted by either the Parsec Virtual Display Driver publisher (e0dde897-547a-4ab3-afa1-8ab6490f3563) or Microsoft-Windows-IndirectDisplays-ClassExtension-Events during the failing attempt — captured with a full-verbose logman session and with the IddCx Diagnostic channel enabled. The driver dies before its first trace statement, i.e. inside/around IddCxDeviceInitConfig/early DeviceAdd.

Everything ruled out (each verified, most with before/after tests)
Fresh device node + full driver package delete/reinstall (multiple times, incl. via the app)
GPU driver: failure identical on 582.66 and after rollback to 582.28 (the version it worked on for months)
IndirectKmd.sys: loads fine when started manually (sc start → RUNNING) — failure unchanged with it resident
IddCx.dll 10.0.19041.1, signature valid; WUDFx02000.dll 10.0.19041.1151; SFC + DISM RestoreHealth clean
GraphicsDrivers\Configuration + Connectivity stores reset (backed up) — no change
WUDF\Services registry: stale hollow registration of another VDD (MttVDD) removed — no change
Display/Monitor class filters: stock (device UpperFilters = IndirectKmd only)
Windows Font Cache healthy; D2D1/DWrite factories create fine in user session
Third-party interference: DisplayFusion (12.1.1) fully uninstalled + reboot, Sunshine stopped — no change
No Driver Verifier, GlobalFlag 0, CodeIntegrity log clean, volume not dirty
Microsoft's own RdpIdd (declares UMDF lib 2.15) remains registered/loadable, while both third-party IddCx VDDs on the machine (ParsecVDA, MttVDD) show the identical failure — suggesting whatever state is torn only affects drivers requesting newer UMDF library versions (mm.inf declares UmdfLibraryVersion = 2.25.0) or non-inbox IddCx clients generally.
Questions

Is there any known persistent (registry/filesystem) state the vdd or IddCx consults at DeviceAdd that could survive a host crash mid-IddCxMonitorArrival and poison subsequent init with STATUS_INVALID_PARAMETER?
Could the driver log/trace anything earlier in DriverEntry/DeviceAdd so this failure mode isn't silent?
Has this signature (2007 / 3489660941 after a 10110 host crash) been seen elsewhere? Issue #97 shows the same app-level status but had no diagnostics.

Happy to run any diagnostic build or capture additional traces — this machine reproduces the failure 100% of the time.

[nomi-san]

Your Windows 10 2004 (build 19041) supports IddCx 1.5 model and Parsec VDD 0.45 should work fine.

I will trace it later. Try removing the full install of Parsec VDD and the mm.dll inside the UMDF driver store. Run sfc /scannow for sure. Then reinstall the driver and try this build: https://github.com/nomi-san/parsec-vdd/actions/runs/25905168117. You can downgrade the driver to 0.41.

Seems, the #97 has fixed alongside with relevant Windows Server issues but I have closed it earlier.

Q: Is there any known persistent (registry/filesystem) state the vdd or IddCx consults at DeviceAdd that could survive a host crash mid-IddCxMonitorArrival and poison subsequent init with STATUS_INVALID_PARAMETER?

A: Parsec VDD is not designed for persistent way, old ParsecVDisplay v0.45 may break it.
Try my new VoidDisplay, it solved all problems that Parsec VDD facing.

Q: Could the driver log/trace anything earlier in DriverEntry/DeviceAdd so this failure mode isn't silent?

A: Send me the system/hardware event log.

[silty-roach]

Update — regression bisected on my machine:

Followed your steps exactly: full removal (device + all mm.inf packages + the projected drivers\UMDF\mm.dll + WUDF\Services\ParsecVDA registration), sfc /scannow clean, reboot.

• CI build app (v1.0.2-67bb0dd3) + driver 0.45 (fresh install): still fails — identical signature, UMDF event 2007 failed to load the driver at level 0, error 3489660941 (0xD000000D), device CM_PROB_FAILED_ADD / 0xC0000001 (repro at 2026-08-11 14:15 local, in the attached logs).
• Same system, same app, downgraded driver to 0.41: device starts immediately (Status: Started), virtual display works.

So on this Win10 19041.1415 machine: 0.41 loads, 0.45 fails at DeviceAdd — both as clean installs minutes apart. Whatever changed between 0.41 → 0.45 in early device init (IddCx config?) is what my system rejects with STATUS_INVALID_PARAMETER. Happy to test any diagnostic driver build to narrow it further.

Event logs attached (System + DriverFrameworks-UserMode operational, includes both the 0.45 failures and the 0.41 success).