CI: stop overriding the UMDF version pinned in MttVDD.vcxproj

[a-struzhanskyi]

Problem

The "Detect UMDF version" step in the build workflow auto-selects the highest UMDF minor version folder found on the runner's WDK install and force-passes it to msbuild, overriding the UMDF_VERSION_MINOR already set in MttVDD.vcxproj.

A recent run picked UMDF 2.35, which is not a released version:

https://github.com/VirtualDrivers/Virtual-Display-Driver/actions/runs/27986913997/job/82830479936

Using UMDF version: 2.35 (minor=35) from C:\Program Files (x86)\Windows Kits\10\Include\wdf\umdf\2.35

Installing the resulting artifact produces this in the Windows Event Log:

UMDF driver service MttVDD failed to load because it was compiled using a pre-release version of the Windows Driver Kit(WDK). The driver should be recompiled using a release version of the WDK. Driver's function table count is 287 and the expected count is 287.

This causes two separate problems:

1. As above — if the runner has header/lib folders for a UMDF version ahead of what any released Windows build recognizes at runtime, the resulting driver fails to load with the error above.
2. Even when the auto-picked version is an officially released one, it can still be newer than what MttVDD.vcxproj intends — silently narrowing OS compatibility without anyone noticing, since the build succeeds either way.

Why this matters beyond the immediate error

UMDF version compatibility is one-directional — a driver built against version X requires framework X or newer on the host, it does not run on anything older. Per Microsoft's own UMDF Version History:

UMDF version	Initial release	Drivers using this version run on
2.35	Not released in any WDK yet	—
2.33	Windows 11 21H2 WDK; WDK for Windows Server 2022	Windows 11 21H2 and later; Windows Server 2022 and later
2.31	Windows 10, version 2004 WDK	Windows 10, version 2004 and later
2.27	Windows 10, version 1809 WDK	Windows 10, version 1809 and later
2.25	Windows 10, version 1803 WDK	Windows 10, version 1803 and later
2.23	Windows 10, version 1709 WDK	Windows 10, version 1709 and later

The 2.35 header/lib folder exists on the runner because the WDK ships headers for upcoming UMDF minor versions ahead of the matching OS-side framework component actually being released — the folder being present on disk doesn't mean any shipped Windows build recognizes a driver built against it. Picking "highest folder found" conflates the two.

MttVDD.vcxproj currently pins UMDF_VERSION_MINOR=25 — this is already the deliberate, broad-compatibility choice (Windows 10 1803+). Letting CI auto-substitute a newer version, released or not, would either break loading entirely (as seen above) or silently cut compatibility down to a much narrower set of Windows versions, with no failure anywhere in the pipeline to flag the regression.

Fix

Remove the "Detect UMDF version" step and the /p:UMDF_VERSION_MINOR override from the msbuild call. The version declared in MttVDD.vcxproj is used as-is; CI is only responsible for pointing msbuild at where the SDK/WDK live, not for choosing which UMDF version to target.

Testing

• Built with the override removed (local + patched CI) — driver compiles and functions correctly.
• Confirmed the vcxproj's declared version (2.25) matches what's documented as intentional broad compatibility per the table above.