UHD 620 (Coffee Lake): libmfxhw64.dll present but SetHandle(D3D11) returns -6 with driver 31.0.101.2141

[miguelandradedotcom]

=== My Software -- Full QSV/MFT Investigation Report ===
Date: 18/05/2026
Hardware: Lenovo IdeaPad 330, Intel i7-8xxx (Coffee Lake), UHD 620
OS: Windows 10 Build 26200 (25H2)
Secondary GPU: NVIDIA GeForce MX150 (variant 1D12, NO NVENC)

================================================================================
EXECUTIVE SUMMARY

Goal: implement QSV (Intel Quick Sync Video) encoder in My Software
to eliminate the 4% dropped frames observed in long recording sessions
in Software mode (OpenH264) on i7-8xxx / UHD 620.

Day result: QSV did not work on this specific machine due to incomplete
Intel runtime. MFT H264 software encoder found but parameters rejected.
Full diagnosis performed -- clear path defined.

Recommended solution: QSVWrapper.dll modeled after AmfWrapper.dll (AMD),
with cascading fallback for maximum universal compatibility.

================================================================================
FULL TEST CHRONOLOGY -- QSVProbe

--- QSVProbe v1 (first version) ---
Initial problem: MFXVideoENCODE_Init returns -15 (MFX_ERR_INVALID_VIDEO_PARAM)
Approach: progressively test parameters (11 combinations)
Discovery: MFXVideoENCODE_Query returns -2 (MFX_ERR_NULL_PTR) on all tests
Cause: MFXVideoParam struct with #pragma pack(1) -- incorrect layout
Result: failed all tests

--- QSVProbe v2 ---
Fix attempted: change to #pragma pack(8)
Result: MFX_ERR_NULL_PTR persisted -- pack was not the root cause

--- QSVProbe v3 ---
New: dump struct sizes before any test
CRITICAL DISCOVERY:
mfxFrameInfo = 68 bytes (expected: 72) -- 4 bytes MISSING
mfxInfoMFX = 136 bytes OK
mfxVideoParam = 1056 bytes (expected: 1052) -- 4 bytes extra
Bonus: Query(NULL, &out) returned 0 (OK) -- driver and session working
Result: failed, but incorrect struct identified as cause of NULL_PTR

--- QSVProbe v4 ---
FIX 1: mfxFrameInfo -- reserved3 field was a single mfxU16
SDK 1.35 has reserved3 + reserved4 (two separate fields)
68 bytes -> 72 bytes CORRECT
FIX 2: mfxInfoMFX -- removed LowPower/BRCParamMultiplier
These fields only exist in API 1.16+
This DLL is API 1.0 in compatibility mode
140 bytes -> 136 bytes CORRECT
FIX 3: mfxVideoParam -- ExtParam as native x64 pointer caused misalignment
Fixed to mfxU32[2] (8 fixed bytes)
1056 bytes -> 1052 bytes CORRECT
Result: structs correct, MFX_ERR_NULL_PTR RESOLVED
New behavior: all Init calls return -15 -- real problem exposed

--- QSVProbe v5 ---
Hypothesis: driver requires valid D3D11 device for MFXVideoENCODE_Init
Implementation: create D3D11 device via LoadLibrary("d3d11.dll")
D3D11 HARDWARE device created OK (FeatureLevel=0xB000)
SetHandle(D3D11_DEVICE=19) = -6 (MFX_ERR_INVALID_HANDLE)
Result: device created but handle rejected -- MFX session degraded

--- QSVProbe v6 ---
5 hypotheses tested simultaneously:
A) Without SetHandle: ret=-15 on everything
B) MFX_IMPL_VIA_D3D9: ret=-15
C) MFX_IMPL_SOFTWARE: -3 (ERR_UNSUPPORTED) -- no SW runtime in libvpl 2.6
D) SetHandle type=0 and type=19: both -6 (ERR_INVALID_HANDLE)
E) libvpl.dll version: 2.6.0.0
DECISIVE DISCOVERY: libvpl.dll 2.6 = modern oneVPL API 2.x
MFXInit() in this version is a compatibility shim -- session degraded
The correct API is MFXLoad + MFXCreateSession (API 2.x)

--- QSVProbe v7 ---
Full implementation of API 2.x (MFXLoad/MFXCreateSession)
Results:
PHASE 1 (API 2.x with HW filter):
MFXLoad() = OK
SetFilter(HW) = -3 (ERR_UNSUPPORTED) -- dispatcher without HW runtime
MFXCreateSession(idx=0) = OK but encoder returns -15 (SW session)
PHASE 2 (API 2.x without filter): same results
PHASE 3 (additional runtimes):
C:\Windows\System32\libmfxhw64.dll: FOUND
Intel MediaSDK Dispatch registry key: NOT FOUND
NEW DISCOVERY: two disconnected Intel runtimes on the system
libvpl.dll 2.6 looks for runtime via registry -- key ABSENT
libmfxhw64.dll present but NOT REGISTERED in dispatcher

--- QSVProbe v8 ---
Critical fix: machine has Intel UHD 620 + NVIDIA MX150 (Optimus/hybrid)
D3D11CreateDevice(adapter=NULL) may select NVIDIA instead of Intel
New approach: enumerate DXGI adapters, explicitly select Intel (VendorId=0x8086)
Enum result:
Adapter[0]: Intel UHD Graphics 620 VendorID=0x8086 -- SELECTED
Adapter[1]: NVIDIA GeForce MX150 VendorID=0x10DE
Adapter[2]: Microsoft Basic Render Driver
D3D11 created on Intel adapter: FeatureLevel=0xB000 OK
Test results:
LEVEL 1 (oneVPL API 2.x + Intel D3D11):
SetHandle(Intel D3D11) = -6 (ERR_INVALID_HANDLE) -- even with correct adapter
LEVEL 2 (libmfxhw64.dll direct + Intel D3D11):
All impl flags tested: SetHandle=-6, Init=-15
DEFINITIVE CONCLUSION: problem is not the adapter, it is the incomplete Intel runtime

--- Post QSVProbe v8 (19/05/2026) ---
Registry key HKLM\SOFTWARE\Intel\MediaSDK\Dispatch created manually
pointing to C:\Windows\System32\libmfxhw64.dll
Result: no change -- SetHandle still returns -6
libmfxhw64.dll version info:
ProductName: Intel(R) Media SDK
ProductVersion: 21.0.1.35 (API 1.35)
FileVersion: 22.05.19.af8448ae
Copyright: 2020 Intel Corporation
Conclusion: runtime from 2020 is incompatible with driver 31.0.101.2141 (March 2026)

================================================================================
FULL TEST CHRONOLOGY -- MFTProbe

--- MFTProbe v1 ---
Approach: use Media Foundation Transform (MFT) instead of MFX
Reason: DXVA2 only has DECODE, not ENCODE; MFT has HW H264 encode
Result:
MFTEnumEx (HW+SW) = S_OK count=0 (no HW encoder)
[WARN] No HW encoder. Trying without flags...
MFTEnumEx (any) = S_OK count=1
[0] H264 Encoder MFT (software)
ActivateObject = S_OK
SetOutputType H264 = 0xC00D36E6 (MF_E_INVALIDMEDIATYPE)
DIAGNOSIS: MFT software encoder present but parameters rejected
HW accelerated H264 not available (confirms Intel runtime problem)
Output parameters need adjustment to accept the SW encoder

--- MFTProbe v2/v3 ---
Fix: reduce SetOutputType to absolute minimum (MAJOR_TYPE + SUBTYPE only)
Result: MF_E_INVALIDMEDIATYPE(0xC00D36E6) persists even with minimal type
D3D11Aware = no
Async MFT = no
Output types available: subtype={34363248-...} (H264 GUID confirmed)
STATUS: under investigation -- encoder announces H264 as available
but rejects SetOutputType. Possible cause: SetInputType must be called
before SetOutputType (inverted order from official documentation).

================================================================================
ROOT CAUSE

THE CORE ISSUE (confirmed after 8 QSVProbe versions + 3 MFTProbe versions):

libvpl.dll 2.6.0.0 (C:\Windows\System32)
-- Modern oneVPL dispatcher
-- Looks for runtime via: HKLM\SOFTWARE\Intel\MediaSDK\Dispatch
-- This key DID NOT EXIST in this installation
-- Key created manually pointing to libmfxhw64.dll: no effect
-- Result: dispatcher cannot find HW runtime

libmfxhw64.dll (C:\Windows\System32)
-- Legacy Intel Media SDK HW runtime
-- PRESENT but incompatible with current driver
-- Version: 21.0.1.35 (2020) -- too old for driver 31.0.101.2141
-- Direct load works for MFXInit but encoder always returns -15

Current driver: 31.0.101.2141 (30/03/2026)
-- Installed via Windows Update / Intel DSA ("slim" package)
-- Does NOT include the complete Intel Media SDK runtime
-- Does NOT create the registry keys needed by the dispatcher
-- Previous driver on system: 31.0.101.2115

Required for QSV to work:
-- Complete Intel graphics driver package (not the slim Windows Update version)
-- That installs an updated libmfxhw64.dll compatible with the current driver
-- AND creates HKLM\SOFTWARE\Intel\MediaSDK\Dispatch automatically

================================================================================
KEY QUESTION FOR INTEL ENGINEERS

1. Is there a standalone Intel Media SDK runtime package compatible with
   driver 31.0.101.2141 for Coffee Lake (UHD 620) on Windows 10?

2. The libmfxhw64.dll present (version 21.0.1.35, 2020) returns
   MFX_ERR_INVALID_HANDLE for SetHandle(D3D11) with the correct Intel adapter.
   Is this a known incompatibility between the 2020 runtime and the 2026 driver?

3. Is there an alternative registry path or configuration beyond
   HKLM\SOFTWARE\Intel\MediaSDK\Dispatch that the dispatcher checks?

4. The Windows Update "slim" driver (31.x series) does not install the
   Media SDK runtime. Is this intentional for Coffee Lake (8th gen) in 2026?
   Is there still a full package available for download?

================================================================================
SYSTEM INFO (full)

Machine: Lenovo IdeaPad 330
CPU: Intel Core i7-8xxx (Coffee Lake, 8 cores)
RAM: 8 GB (~950 MB available during test)
iGPU: Intel UHD Graphics 620
dGPU: NVIDIA GeForce MX150 (variant 1D12 -- NO NVENC hardware encoder)
OS: Windows 10 Build 26200 (25H2)
Driver: Intel 31.0.101.2141 (30/03/2026)
libvpl.dll: 2.6.0.0 (C:\Windows\System32)
libmfxhw64.dll: 21.0.1.35 / FileVersion 22.05.19 (C:\Windows\System32)
Registry key: HKLM\SOFTWARE\Intel\MediaSDK\Dispatch -- absent (created manually, no effect)

================================================================================
TOOLS DEVELOPED FOR THIS INVESTIGATION

QSVProbe.c (v1 to v8)
MFX/oneVPL diagnostic tool
Tests API 1.x and 2.x, explicit Intel D3D11 adapter, direct libmfxhw64
Build: gcc -O2 -o QSVProbe.exe QSVProbe.c -ld3d11 -ldxgi -luuid -lversion

MFTProbe.c (v1 to v3)
Media Foundation MFT diagnostic tool
Enumerates available H264 encoders, tests input/output configuration
Build: gcc -O2 -o MFTProbe.exe MFTProbe.c -lmfplat -lmfuuid -lole32 -lstrmiids -lversion

All source code available on request.

================================================================================
END OF REPORT

[miguelandradedotcom]

Follow-up: workaround confirmed + three specific questions for Intel engineers

Since opening this issue I continued the investigation inside a screen recorder application (Delphi/Pascal, direct MFX API calls via LoadLibrary + GetProcAddress). I now have new evidence that narrows the problem to a D3D11 device ownership contract change in the driver.

---

What changed since the original report

The full initialization sequence — with explicit fallback logic — was tested and logged:

Step	Call	Result
1	MFXInit(MFX_IMPL_HARDWARE | MFX_IMPL_VIA_D3D11)	MFX_ERR_NONE ✓
2	MFXVideoCORE_SetHandle(MFX_HANDLE_D3D11_DEVICE, pDevice)	-6 (MFX_ERR_INVALID_HANDLE) ✗
3	Close session, reopen with MFX_IMPL_HARDWARE | MFX_IMPL_VIA_D3D9 via libmfxhw64.dll	MFX_ERR_NONE ✓
4	MFXVideoENCODE_Init (no SetHandle, DXVA2 session)	-15 (MFX_ERR_UNSUPPORTED) ✗

The ID3D11Device* passed at step 2 is created explicitly on the Intel adapter (VendorId=0x8086) using D3D11CreateDevice — this is confirmed by the DXGI enumeration logs in the original report (Adapter[0] = Intel UHD 620).

---

Key new finding: ffmpeg h264_qsv works on the same machine

As a workaround, I routed the encode through ffmpeg (h264_qsv -bf 0 -async_depth 1) via a stdin/stdout pipe, sending raw NV12 frames and receiving NAL Annex B output. The result:

• ffmpeg initializes QSV successfully on the same hardware and driver
• 60fps 1920x1080 encode with zero dropped frames
• A/V sync drift of 20ms over 34 seconds

The critical difference is that ffmpeg never calls SetHandle with an externally-created device. It creates its own ID3D11Device internally (via libavutil/hwcontext_qsv.c) and passes that to SetHandle. The driver accepts it.

This strongly suggests the regression is not about the adapter selection or the device feature level — it is about who created the device: a device created outside the MFX session is rejected, while a device created by the same process that will call SetHandle is accepted.

---

Three specific questions

1. D3D11 device ownership contract

Did driver 31.0.101.2141+ introduce a requirement that the ID3D11Device* passed to SetHandle(MFX_HANDLE_D3D11_DEVICE) must be created by the same component that initializes the MFX session — rather than being shared from another subsystem (e.g. a screen capture pipeline)?

If so: are there specific D3D11_CREATE_DEVICE_* flags or IDXGIAdapter acquisition methods (e.g. obtained via MFXVideoCore_GetHandle first) that would make the shared device acceptable to the runtime?

2. DXVA2 encode path on Coffee Lake

Even with a clean MFX_IMPL_VIA_D3D9 session opened successfully via libmfxhw64.dll (API 1.35), MFXVideoENCODE_Init returns -15. Is H.264 encode via the DXVA2 path intentionally unsupported on Coffee Lake with driver 31.x? Or does it require a SetHandle(MFX_HANDLE_D3D9_DEVICE_MANAGER) call before EncodeInit that was not required in previous driver versions?

3. Reproducer with the official sample

Is sample_encode from the Intel-Media-SDK/MediaSDK repository expected to work on Coffee Lake / UHD 620 with driver 31.0.101.2141 when invoked as:

sample_encode.exe h264 -i input.yuv -o out.h264 -w 1920 -h 1080 -d3d11 -hw

I will build and run this test and report the output here. If it also returns -6 on SetHandle, it confirms the issue is in the driver and not in the application-level initialization.

---

Summary

The hardware is capable — ffmpeg proves QSV encode works on this exact machine with this exact driver. The failure is specific to the SetHandle call with an externally-created ID3D11Device. A clarification on the ownership contract (question 1) would likely resolve this with a one-line fix on our side.

Happy to provide any additional logs, run custom test builds, or test a patched runtime if that would help.

Environment:

• Hardware: Lenovo IdeaPad 330, Intel Core i7-8xxx (Coffee Lake), UHD 620
• Driver: 31.0.101.2141 (30/03/2026)
• OS: Windows 10 Build 26200 (25H2)
• libvpl.dll: 2.6.0.0
• libmfxhw64.dll: 21.0.1.35 / FileVersion 22.05.19
• ffmpeg build: 75b9c61b9dc88975711392907a4b61a7c8a179542f791ce4480f827106bd4d0c (BtbN win64-gpl)

[miguelandradedotcom]

I own an i7 8th generation with Intel UHD 620. I spent approximately 20 days diagnosing a serious bug introduced by a recent Intel driver update on Windows.
The problem: starting from driver 31.0.101.2141+, the MFXVideoCORE_SetHandle call with a D3D11 handle returns ret=-6 (ERR_INVALID_HANDLE) on Coffee Lake hardware. The DXVA2 path opens a session, but MFXVideoENCODE_Init returns ret=-15 (UNSUPPORTED), completely disabling QSV Legacy — the only hardware encode path available on this generation. The bug is documented in issue #382 of the official intel/vpl-gpu-rt repository on GitHub.
The impact was real: the encoder silently fell back to software (CPU), resulting in over 2,500 dropped frames in 90 seconds of recording. No warning, no error message visible to the user — the hardware simply stops working without explanation.
I opened a ticket reporting the issue. The response was to close it with the justification that the hardware is "legacy" — no technical explanation, no proposed solution, no acknowledgment whatsoever of the regression introduced by your own update.
The fix I found was to work around the bug via FFmpeg, opening the MFX session directly through the DXVA2 path without touching the D3D11 handle. It worked — but it is a workaround for a problem that should not exist, and one that cost me weeks of my time.
8th generation Intel hardware is still widely in use. Dropping support without notice through an update that silently introduces a regression, and then closing user tickets without a technical response, is not the standard users expect from Intel. The bare minimum would be either fixing the bug or clearly communicating the discontinuation — not leaving users to spend weeks debugging a problem you caused.
Miguel
Software Developer