[Windows] NPCF Dynamic Boost targets eGPU instead of internal laptop GPU — RTX 5090 stuck at 95W with Thunderbolt eGPU

[zletpm]

RTX 5090 Laptop stuck at 95W when eGPU (RTX 5080) is connected — NPCF Dynamic Boost bug

System:

• MSI laptop, Intel Core Ultra 9 275HX
• Internal GPU: RTX 5090 Laptop GPU (24GB) — PCI bus 01:00.0, SUBSYS 14741462
• External GPU: RTX 5080 (Thunderbolt eGPU) — PCI bus 54:00.0, SUBSYS F3221569
• Driver: 32.0.15.9531 (nvpcf.sys 2026-01-13)
• Windows 11 Pro 26200
• MSI Center: Extreme Performance mode, Discrete Graphics Mode

Problem: When the RTX 5080 eGPU is connected, NPCF (nvpcf.sys) assigns Dynamic Boost to the external desktop GPU instead of the internal laptop GPU. This locks the RTX 5090 Laptop at its base TDP of 95W instead of 175W.

Testing performed:

Condition | 5090 enforced power limit -- | -- eGPU disabled in Device Manager | 175W (correct) eGPU enabled | 95W (incorrect) eGPU enabled + NPCF disabled | 95W (no Dynamic Boost at all) eGPU enabled + NPCF cycled (disable/re-enable) | 95W eGPU enabled + MSI Center profile toggled (Extreme/Balanced/ECO via WMI) | 95W nvidia-smi -pl 175 (admin) | "Changing power management limit is not supported" NVML nvmlDeviceSetPowerManagementLimit | "Not Supported"

Conclusion: NPCF is the sole source of Dynamic Boost for the laptop GPU. When two NVIDIA GPUs are present, it targets the wrong one. The desktop eGPU has its own 360W power supply and does not need Dynamic Boost.

Expected behavior: nvpcf.sys should identify the internal laptop GPU by:

• PCI bus topology (01:00.0 = internal, 54:00.0 = Thunderbolt)
• Subsystem vendor ID (1462 = MSI OEM = internal GPU)
• Or ACPI _DSM presence

and assign Dynamic Boost exclusively to the internal GPU.

Workaround: The only working workaround is disabling the eGPU in Device Manager, which defeats the purpose of having one.

This issue also affects RTX 40-series laptops — see egpu.io thread and GeForce Forums thread.

RTX 5090 Laptop stuck at 95W when eGPU (RTX 5080) is connected — NPCF Dynamic Boost bug

System:

MSI laptop, Intel Core Ultra 9 275HX
Internal GPU: RTX 5090 Laptop GPU (24GB) — PCI bus 01:00.0, SUBSYS 14741462
External GPU: RTX 5080 (Thunderbolt eGPU) — PCI bus 54:00.0, SUBSYS F3221569
Driver: 32.0.15.9531 (nvpcf.sys 2026-01-13)
Windows 11 Pro 26200
MSI Center: Extreme Performance mode, Discrete Graphics Mode
Problem:
When the RTX 5080 eGPU is connected, NPCF (nvpcf.sys) assigns Dynamic Boost to the external desktop GPU instead of the internal laptop GPU. This locks the RTX 5090 Laptop at its base TDP of 95W instead of 175W.

Testing performed:

Condition 5090 enforced power limit
eGPU disabled in Device Manager 175W (correct)
eGPU enabled 95W (incorrect)
eGPU enabled + NPCF disabled 95W (no Dynamic Boost at all)
eGPU enabled + NPCF cycled (disable/re-enable) 95W
eGPU enabled + MSI Center profile toggled (Extreme/Balanced/ECO via WMI) 95W
nvidia-smi -pl 175 (admin) "Changing power management limit is not supported"
NVML nvmlDeviceSetPowerManagementLimit "Not Supported"
Conclusion:
NPCF is the sole source of Dynamic Boost for the laptop GPU. When two NVIDIA GPUs are present, it targets the wrong one. The desktop eGPU has its own 360W power supply and does not need Dynamic Boost.

Expected behavior:
nvpcf.sys should identify the internal laptop GPU by:

PCI bus topology (01:00.0 = internal, 54:00.0 = Thunderbolt)
Subsystem vendor ID (1462 = MSI OEM = internal GPU)
Or ACPI _DSM presence
and assign Dynamic Boost exclusively to the internal GPU.

Workaround:
The only working workaround is disabling the eGPU in Device Manager, which defeats the purpose of having one.

This issue also affects RTX 40-series laptops — see egpu.io thread and GeForce Forums thread.

[dsull111]

I am having the same issue with a 5070ti Laptop GPU and an external RTX 3090

[ilajifa240]

Third independent report of this bug — RTX 5080 Laptop stuck at 80 W of a rated 175 W whenever an external NVIDIA GPU is attached. Same signature as @zletpm's 5090 and @dsull111's 5070 Ti + RTX 3090.

I disassembled the shipped nvpcf.sys to find where the selection actually goes wrong, and I think the fix is small. Short version:

NPCF identifies candidate GPUs solely by DEVPKEY_Device_Service == "nvlddmkm". An internal laptop GPU and an external NVIDIA eGPU both satisfy that test, so both enter NPCF's device table and the tie is broken by enumeration order. The Dynamic Boost budget goes to the eGPU — which has its own PSU and reports zero boost headroom, so the budget is not just misdirected, it is discarded.

Everything below is measured, with the eGPU enabled/disabled as the control.

System

Laptop	MECHREVO YAOSHI X6AR55xY (Yaoshi 16 Ultra), BIOS N.1.18MRO24 (2025-08-06)
CPU	Intel Core Ultra 9 275HX
Internal GPU	RTX 5080 Laptop, VBIOS 98.03.5e.00.5c, PCI 0000:02:00.0
eGPU	RTX 3090, GIGABYTE AORUS Gaming Box, Thunderbolt 3, PCI 0000:05:00.0
Driver	610.88 (KMD 610.88, CUDA 13.3)
OS	Windows 11 Pro 26200

Rated TGP for this model is 175 W (vendor spec: CPU 125 W + GPU 175 W, liquid-cooling module).

Measurements

nvidia-smi -q -d POWER:

	eGPU enabled	eGPU disabled in Device Manager
Current Power Limit	80.00 W	175.00 W
Default Power Limit	80.00 W	80.00 W
Max Power Limit	175.00 W	175.00 W

The limit flips immediately, no reboot required.

Under compute load (fp16 matmul 8192×8192, PyTorch, 100 % utilisation):

	eGPU enabled	eGPU disabled
Power draw (peak)	80.7 W	176.3 W
SM clock	1065–1537 MHz	2077–2340 MHz
Memory clock	9001 MHz	14001 MHz
Memory bandwidth (2 GB D2D, fp16)	482 GB/s	706 GB/s
Temperature	37–42 °C	48–56 °C
Throttle reason	SW Power Cap	SW Power Cap

HW Thermal Slowdown and HW Power Brake Slowdown are inactive in both cases — liquid cooling holds 56 °C at full load, so there is no thermal component. With the eGPU attached the internal GPU loses 2.2× power, 77 % core clock and 46 % memory bandwidth.

The decisive control

With the enclosure still connected and 12 of its devices enumerated normally (Thunderbolt router, ASMedia controllers, LED controller), disabling only the GPU raises the limit 80 → 175 W instantly. Nothing about power delivery, cabling or the enclosure changes between those two measurements. It is the presence of a second NVIDIA GPU, not the eGPU chassis.

Root cause, part 1 — firmware provides no NPCF↔GPU association

The ACPI device sits directly under \_SB, as a peer of the PCI host bridges rather than a child of either GPU:

LocationPaths = ACPI(_SB_)#ACPI(NPCF)
Parent        = ACPI_HAL\PNP0C08\0

The DSDT confirms it: AML references the fully-qualified path \_SB.NPCF.CTGP, and CTGP is a Name(CTGP, 0) data cell the driver writes into, not a callable method. _DSM UUID 36b49710-2483-11e7-9598-0800200c9a66 is present.

This matches the placement described in #1162. So the firmware expresses no association, and the driver must choose a GPU at runtime.

Root cause, part 2 — the driver never derives one either

Disassembly of the shipped nvpcf.sys (version 32.0.16.1051, 309480 bytes, signed Microsoft Windows Hardware Compatibility Publisher). Linear sweep with recovery over .text, 60 171 instructions. Addresses relative to default image base 0x140000000.

The device-arrival handler is at 0x140004020. For each arriving device it:

1. walks to the base PDO — IoGetAttachedDeviceReference (0x140004126), then IoGetDeviceAttachmentBaseRef (0x140004132);
2. queries DEVPKEY_Device_Service (GUID a45c254e-df1c-4efd-8020-67d146a850e0, pid 6) via IoGetDevicePropertyData (0x140004182);
3. compares it against the UTF-16 literal nvlddmkm using RtlEqualUnicodeString (0x1400041c1);
4. on match, records the device into a 16-slot table — presence flags at [base + 0x1a0 + i*8], device objects at [base + i*16 + 0xa8], capacity check cmp dword ptr [rdi+0x98], 0x10 at 0x1400041e8.

That is the entire discriminator. Both GPUs run under nvlddmkm, so both match and both enter the table. There is no subsequent internal/external test — no bus-depth check, no subsystem-ID check, no removability check. I found 301 accesses to those table offsets across dozens of functions and no discriminating constant among them.

Suggested fix

Every property needed to tell the two apart is already available on the same PDO, at the exact call site where NPCF queries the service name — no extra enumeration, no new interface:

property	internal GPU	eGPU
DEVPKEY_Device_LocationPaths	PCIROOT(0)#PCI(0200)	full chain of Thunderbolt switch ports
DEVPKEY_Device_RemovalPolicy / PCIe hot-plug capability	not removable	removable
subsystem ID	OEM SUBSYS_60411D05	generic PCI\VEN_10DE&DEV_2204

One additional property query in that handler, preferring the non-removable GPU closest to the root complex, would fix this class of bug on every affected machine. As a safety net, a GPU reporting power.default_limit == power.max_limit (as every desktop eGPU does — mine reports 350 W for both) has no Dynamic Boost headroom and should never be selected as the boost target.

Not a recent regression

Windows had kept five nvpcf.inf packages in the DriverStore. I bound the NPCF device to each with devcon update, verified the bound version by reading DEVPKEY_Device_DriverVersion back, and measured with the eGPU enabled:

nvpcf.sys	package date	Current Power Limit
32.0.15.7262	2025-02-26	80 W
32.0.15.9531	2026-01-13	80 W
32.0.15.9071	2026-01-20	80 W
32.0.16.1029	2026-04-05	80 W
32.0.16.1051	2026-06-02	80 W

Identical across 16 months of NPCF builds. Only the NPCF software device was rebound; the display driver was untouched and the original version restored afterwards.

Tested and does not help

Each measured with the eGPU enabled, each reverted afterwards:

attempt	result
nvidia-smi -pl 175 (elevated)	Changing power management limit is not supported
nvidia-smi -lmc 14001 / -lgc 2400,2400	accepted, then ignored under load — the power cap overrides
Restarting the NPCF device	80 W
Disabling NPCF entirely	80 W — no Dynamic Boost at all, strictly worse
Binding order: eGPU off → NPCF rebind → eGPU on	175 W → 80 W the instant the eGPU is re-enumerated
Re-enumerating the internal GPU last	80 W
EnableCoproc / EnableMsHybrid / EnableRuntimePowerManagement / RM1774520	80 W
Capping the eGPU to its minimum 100 W	80 W
Windows per-app GPU preference	80 W
NVIDIA Control Panel → Prefer maximum performance	80 W
OEM control panel: Turbo + Extreme Performance + GPU Overclocking	80 W
High interrupt priority on both GPUs (MSI already enabled)	80 W
Merging both GPUs into one INF and one install section	80 W

The binding-order line is the informative one: NPCF re-evaluates and reassigns the budget the moment the eGPU is enumerated, even though it had granted the full budget to the internal GPU a second earlier. That rules out the whole class of "let NPCF bind first, then attach the eGPU" workarounds.

The last line is worth noting too: both GPUs were successfully brought onto a single modified package and the same install section (Section271, driver 32.0.16.1088), verified after a clean boot — still 80 W. So the split across notebook (nvtfi.inf) and desktop (nv_dispi.inf) packages is not what drives the choice either.

MUX is already discrete: the internal panel is attached to the 5080 (display_attached: Yes), the iGPU drives nothing.

Summary

• The internal GPU loses 2.2× power, 77 % core clock and 46 % memory bandwidth whenever a second NVIDIA GPU is enumerated.
• Firmware provides no NPCF↔GPU association, and the driver never derives one — it matches on DEVPKEY_Device_Service == "nvlddmkm", which both GPUs satisfy.
• The budget handed to the eGPU is discarded — it has its own PSU and power.default_limit == power.max_limit == 350 W.
• Identical across five NVPCF builds spanning 16 months, so this is long-standing rather than a regression.

Happy to run additional diagnostics, provide full ACPI dumps or nvidia-smi -q output, or test a candidate fix on this machine.

[IamLumae]

Reproducible Windows root-cause proof: an eGPU becomes the NPCF Dynamic Boost candidate instead of the internal laptop GPU

I can reproduce and reversibly control the 95 W / 175 W state without modifying
nvpcf.sys, the NVIDIA display driver, the GPU vBIOS, or the EC.

Test system

• MSI Titan 18 HX Dragon Edition Draco Epic A2WJ
• Windows 11 Home 10.0.26200, build 26200
• NVIDIA display driver 610.74 (32.0.16.1074)
• NVIDIA Platform Controllers and Framework driver 32.0.16.1051
• C:\Windows\System32\drivers\nvpcf.sys
  • size: 319,312 bytes
  • SHA-256: F4D49848837FF32DF09E5B77FC0699D338C002903070DEB581B7BDE771FC2803
• internal GPU: RTX 5090 Laptop GPU
  • PCI ID: VEN_10DE&DEV_2C18&SUBSYS_15001462
  • PCI BDF: 00000000:02:00.0
  • PnP location: ACPI(_SB_)#ACPI(PC00)#ACPI(RP01)#ACPI(PXSX)
• external GPU: RTX 5080 through a Thunderbolt 5 eGPU adapter
  • PCI ID: VEN_10DE&DEV_2C02&SUBSYS_89DE1043
  • PCI BDF: 00000000:8D:00.0
  • PnP location includes ACPI(TBP3)
• NPCF device instance: ACPI\NVDA0820\NPCF

Both NVIDIA display devices expose:

DEVPKEY_Device_Service = nvlddmkm

Baseline symptom

With only the internal GPU selected by NPCF, its reported ceiling is 175 W. After
the external RTX 5080 is present when NPCF initializes, the internal 5090 Laptop
GPU is left at its 95 W default:

nvidia-smi -i 00000000:02:00.0 -q -d POWER

GPU Ceiling Power Limit
    Current Power Limit : 95.00 W
    Default Power Limit : 95.00 W
    Max Power Limit     : 175.00 W

Minimal reversible A/B/A procedure

This must run as SYSTEM, because the relevant value is below
HKLM\SYSTEM\CurrentControlSet\Enum. Administrator alone may not have write
access. The device instance IDs and BDFs must be discovered for each machine;
the values below are specific to this test system.

1. Confirm that the active eGPU is healthy and that its service property is
   nvlddmkm.
2. Persist its original Service value for recovery.
3. Change only the eGPU's live Enum value from nvlddmkm to a non-matching
   temporary string.
4. Read DEVPKEY_Device_Service back independently with both
   CM_Get_DevNode_PropertyW and SetupDiGetDevicePropertyW.
5. Confirm that the exact eGPU still has PnP status OK and still answers NVML
   queries by its fixed PCI BDF/UUID.
6. Restart only ACPI\NVDA0820\NPCF.
7. Read the internal GPU's power ceiling again: it changes from 95 W to 175 W.
8. Restore the eGPU's Service value to nvlddmkm and verify it through the
   registry, CfgMgr32, and SetupAPI. Do not restart NPCF at this point. The
   eGPU remains loaded and usable, while NPCF retains the internal GPU as its
   selected Dynamic Boost target.
9. For the final A step, restart NPCF once more after the property has been
   restored. With both GPUs again visible as nvlddmkm candidates, the internal
   GPU returns to 95 W on this system.

The essential mutation/reinitialization sequence is:

# Run as SYSTEM. Hardware-specific values shown here.
$egpuInstance = 'PCI\VEN_10DE&DEV_2C02&SUBSYS_89DE1043&REV_A1\BE495C8DD72DB04800'
$egpuKey = "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\$egpuInstance"
$npcfInstance = 'ACPI\NVDA0820\NPCF'

$original = Get-ItemPropertyValue -LiteralPath $egpuKey -Name Service
if ($original -ne 'nvlddmkm') { throw "Unexpected original service: $original" }

try {
    Set-ItemProperty -LiteralPath $egpuKey -Name Service -Value 'nvlddmkm_npcf_masked'

    # Gate: independently read DEVPKEY_Device_Service through CfgMgr32 and
    # SetupAPI here and continue only if both return nvlddmkm_npcf_masked.
    # Also verify the exact eGPU by PCI BDF/UUID before touching NPCF.

    pnputil.exe /restart-device $npcfInstance
    Start-Sleep -Seconds 3

    nvidia-smi -i 00000000:02:00.0 -q -d POWER
    # Observed Current Power Limit: 175.00 W
}
finally {
    Set-ItemProperty -LiteralPath $egpuKey -Name Service -Value $original
}

# Leave NPCF running: internal GPU remains at 175 W while the eGPU service is
# already restored to nvlddmkm and the eGPU remains operational.

Important detail: no attempt is made to set the property through
SetupDiSetDeviceRegistryProperty; DEVPKEY_Device_Service is not generally a
writable SetupAPI property. The proof changes the backing Enum registry value as
SYSTEM, then verifies that the live DevNode exposes the changed value through
two independent read APIs before NPCF is restarted. The RTX 5080 itself is never
restarted or re-enumerated during the B step, so nvlddmkm remains bound and the
card remains usable.

Exact observed A/B/A result

A: both GPUs report Service=nvlddmkm; restart NPCF
   internal RTX 5090 Laptop Current Power Limit = 95.00 W

B: temporarily mask only the TB5 RTX 5080 service property; restart NPCF;
   restore the property without restarting NPCF
   internal RTX 5090 Laptop Current Power Limit = 175.00 W
   external RTX 5080 PnP status = OK and NVML identity unchanged

A: with the property restored, restart NPCF again
   internal RTX 5090 Laptop Current Power Limit = 95.00 W

Reapplying B restores 175 W. A real Windows reboot also reproduced the sequence:
the laptop GPU initially appeared at 95 W, then the same gated SYSTEM task applied
B and restored 175 W automatically.

Workload validation

The power-limit readback also produces the expected application-level change with
the same binary, model, and arguments (llama.cpp commit 29f1482, Llama-2-7B
Q4_0, pp512/tg128, Flash Attention off/on, five repetitions, single-GPU mode):

Test	Broken 95 W state	B state (175 W ceiling)	Change
Prefill, FA off	5,201.10 tok/s	7,027.16 tok/s	+35.1%
Decode, FA off	106.09 tok/s	155.39 tok/s	+46.5%
Prefill, FA on	5,511.96 tok/s	8,129.30 tok/s	+47.5%
Decode, FA on	118.56 tok/s	157.45 tok/s	+32.8%

The restored decode values are again within 0.7% / 0.4% of the public RTX 5090
Laptop reference values (156.5 / 158.1 tok/s). A separate load canary reached
175.84 W on the internal GPU. In a simultaneous independent dual-GPU test, the
external RTX 5080 averaged 94.54% utilization and 252.16 W, while the internal RTX
5090 Laptop averaged 97.24% and 148.56 W with a 175.01 W peak. Both cards retained
approximately 100% of their corresponding sequential single-GPU performance.

Interpretation

The A/B/A result strongly indicates that NPCF's candidate selection includes the
external desktop GPU because it also exposes DEVPKEY_Device_Service = nvlddmkm.
Temporarily excluding only that device during NPCF initialization makes the
internal mobile GPU receive Dynamic Boost again. This is a behavioral inference,
not a claim about NVIDIA's source implementation, but the selection is fully
reversible and deterministic on this machine.

Recovery used during testing

Before changing the value, the original service, instance ID, PCI BDF, and UUID
are persisted. A boot-triggered and a three-minute deadline recovery task restore
the original Service value. If recovery is required:

# Run as SYSTEM.
Set-ItemProperty -LiteralPath $egpuKey -Name Service -Value 'nvlddmkm'
pnputil.exe /restart-device $egpuInstance
Start-Sleep -Seconds 3
pnputil.exe /restart-device $npcfInstance

The complete gated reproducer performs registry + CfgMgr32 + SetupAPI readback,
fixed-device NVML/PnP checks, finally restoration, and boot/deadline recovery.

[IamLumae]

Addendum

Affected generations (prior reports)

This selection bug predates Blackwell. Same symptom signature
(internal dGPU capped at base TGP once an NVIDIA eGPU is present):

• Ada: RTX 4080 Laptop drops 175 W → 115 W with eGPU attached —
  egpu.io report
• Ampere: RTX 3070 Ti Laptop + RTX 3080 eGPU — Dynamic Boost still
  worked on Studio driver 537.42, broken from 537.58 onward
  (GeForce Forums),
  i.e. this is a datable 2023 regression, not a Blackwell-era defect.

If you run an Ada/Ampere laptop + NVIDIA eGPU and can reproduce the
A/B/A result with the masking procedure, please report back —
hardware, driver version, and the two power readings are enough.

Not this bug: if your dGPU also gets capped by a plain USB-C PD
charger without any NVIDIA eGPU attached (e.g. older Lenovo Legion
reports), that is a different mechanism; the masking will not help.

Persistence status

• Cold reboot: verified — boot task re-applies B automatically,
  175 W restored.
• Modern Standby (S0ix) resume: untested. If NPCF re-initializes
  on resume while the eGPU is enumerated, the system may silently
  revert to 95 W. Check nvidia-smi -q -d POWER after resume.
• Thunderbolt hot-plug mid-session: untested, same caveat.

Risk note (masking window)

If Windows forces a re-enumeration of the eGPU during the brief
masking window (PnP rebalance, driver update), its device node points
at a non-existent service until the value is restored. This is why the
reproducer includes boot-triggered and 3-minute deadline recovery
tasks — keep them in place if you adapt the script.

[IamLumae]

This bug wasnt Solved for 3 Years.

Now it is

<3

[ilajifa240]

Confirmed on a different generation pairing — the masking procedure works here too, and it closes the loop with the static analysis I posted on 10 Aug.

Why this is an independent data point: @IamLumae's system is Blackwell laptop + Blackwell eGPU over Thunderbolt 5. Mine is Blackwell laptop + Ampere eGPU over Thunderbolt 3, and the nvpcf.sys build differs (same version string 32.0.16.1051, but 309,480 bytes here vs 319,312 bytes there). Same behaviour on both.

System

Laptop	MECHREVO YAOSHI X6AR55xY (Yaoshi 16 Ultra)
Internal GPU	RTX 5080 Laptop, VBIOS 98.03.5e.00.5c, PCI 0000:02:00.0
eGPU	RTX 3090, GIGABYTE AORUS Gaming Box, Thunderbolt 3, PCI 0000:05:00.0
Display driver	610.88
NPCF driver	32.0.16.1051, nvpcf.sys 309,480 bytes
OS	Windows 11 Pro, build 26200

The two power readings

nvidia-smi -i 0000:02:00.0 -q -d POWER, eGPU attached and fully operational in both states:

	before (A)	after (B)
Current Power Limit	80.00 W	175.00 W
Default Power Limit	80.00 W	80.00 W
Max Power Limit	175.00 W	175.00 W

After restoring the Service value without restarting NPCF, the eGPU stays at PnP status OK and the internal GPU keeps the 175 W ceiling — exactly as described.

Under real load, not just the reported ceiling

Same workload before and after (LLM inference, qwen3.5:9b on Ollama pinned to the internal GPU, nvidia-smi sampled every 0.4 s, 19 samples above 50 % utilisation):

	80 W state	175 W state
Power draw (peak)	80.7 W	148.6 W
Power draw (mean under load)	—	140.9 W
SM clock	1065–1372 MHz	2167 MHz
Memory clock	9001 MHz	15001 MHz
Temperature	37 °C	52 °C

The memory clock is the part that matters most for my workload — inference is bandwidth-bound, and 9001 → 15001 MHz is a 1.67× step. No thermal component in either state: liquid cooling holds 52 °C, HW Thermal Slowdown and HW Power Brake inactive throughout.

This matches the disassembly exactly

In my 10 Aug comment I traced the shipped nvpcf.sys and found the discriminator: the device-arrival handler at 0x140004020 queries DEVPKEY_Device_Service via IoGetDevicePropertyData (0x140004182) and compares it against the UTF-16 literal nvlddmkm with RtlEqualUnicodeString (0x1400041c1); on match the device enters a 16-slot table. There is no bus-depth, subsystem-ID or removability test anywhere after it.

@IamLumae's workaround masks precisely that comparison, for exactly the window in which the table is built. So the mechanism is now confirmed from both ends — statically from the binary, and dynamically by reversible A/B/A. I had the discriminator and did not think to temporarily change what it sees; credit where it is due.

Not tested here either

• S0ix resume — untested, same caveat as the original report.
• Thunderbolt hot-plug mid-session — untested.
• Cold reboot — not yet exercised on this machine.

I kept the finally restore plus a boot-triggered and a deadline recovery task, as recommended. The masking window was uneventful.

Thanks for chasing this down — three years is a long time, and the fix is small enough that the suggested discriminators (DEVPKEY_Device_LocationPaths, removal policy, subsystem ID) are all already available at the same call site.