AMD GPU D3D query stalls sensor updates under CPU load; disabling LHM GPU polling resolves stalls in FanControl

Summary

FanControl V275 intermittently stopped updating CPU temperature and fan-speed readings during an OCCT CPU test. Three managed stack captures during pauses showed its shared sensor-update path inside LibreHardwareMonitor's AMD GPU D3D query. Disabling only LHM GPU polling eliminated the observed FanControl stalls; restoring it reproduced a >10-second pause within 36 seconds.

Reporting upstream because the captured call is in LibreHardwareMonitor. This was observed through FanControl; it has not been reproduced in the standalone LHM application or a minimal program.

Environment

• Windows 11, 25H2, build 26200.9457.
• FanControl V275, desktop mode, Normal process priority; FanControl service stopped.
• Installed LibreHardwareMonitorLib: file version 0.9.6.0, product version 0.9.6+b35fe14af87fc64207113b84a1f4e1c9e42e8b3b.
• Ryzen 9 7900X with AMD Radeon integrated graphics; AMD display driver 32.0.21043.5001.
• NVIDIA RTX 4070 Ti; NVIDIA display driver 32.0.16.1692. A virtual display driver was also installed (11.30.4.434); its relevance is untested.
• ASUS ROG STRIX B650E-F GAMING WIFI, BIOS 3881, NCT6799D monitoring chip.
• 64 GB DDR5-6000, CL48; CPU in 105 W Eco mode (PPT/TDC/EDC 142 W / 110 A / 170 A).
• OCCT Personal 17.1.3: CPU test, Small data set, Normal, Steady, 24 threads, Auto instruction set selecting AVX2.

Reproduction and comparison

1. Enable LHM GPU polling alongside CPU/motherboard polling in FanControl. NVAPI and ADLX providers were also enabled.
2. Run the CPU workload above with OCCT's normal monitoring enabled.
3. Observe CPU temperature and fan readings stop updating for multiple seconds while FanControl's sensor IPC remains responsive.
4. Disable only Sensors.LibreHardwareMonitorSettings.GPU in a copy of the FanControl profile, then load that profile and refresh sensors. Leave CPU/motherboard polling, NVAPI, ADLX, fan curves and process priorities unchanged.
5. Repeat the workload; restore the GPU-polling setting and repeat again.

Results, without stack-capture instrumentation during these comparisons:

The two clean runs had 258 and 319 FanControl samples respectively, collected roughly every 0.9 seconds. Maximum collection gaps were 1.076 and 1.088 seconds. No CPU calculation errors or Windows WHEA events were observed. Final-run recorded CPU peak was 71.1°C.

Freshness was inferred from the combined Tctl/Tdie, CPU-package and CCD-maximum temperature values; this is a repeated-value duration, not an internal hardware-sample timestamp. The earlier pauses also affected fan readings. Nine minutes of clean comparisons supports this workaround, not a guarantee of long-term reliability.

Stack evidence

All three captures during a separate instrumented run showed this polling-thread path (method names retained, process/thread IDs omitted):

[Native Frames]
LibreHardwareMonitor.Hardware.D3DDisplayDevice.GetDeviceInfoByIdentifier(...)
LibreHardwareMonitor.Hardware.Gpu.AmdGpu.Update()
FanControl.Domain.BackendProviders.LHM.LHMBackendProvider.Update()
FanControl.Domain.ComputerAccessLayer.Update()
FanControl.Domain.ApplicationClock.DoActions()
System.Timers.Timer.MyTimerCallback(...)

Captured using Microsoft's dotnet-stack report. These snapshots identify where the updater was sampled, but do not identify the exact native D3DKMT call, prove a deadlock, or establish an AMD driver defect.

Workaround and remaining limits

Disabling LHM GPU polling in FanControl preserved the CPU/motherboard readings and existing CPU-based fan curves. NVIDIA temperature monitoring remained available through its separate NVAPI provider. This is a sensor-provider setting, not disabling the graphics adapter. Check any GPU-dependent fan curves before using this workaround on another setup.

Disabling OCCT's embedded-controller polling or snapshot polling separately did not eliminate FanControl's pauses. OCCT's main monitoring toggle also did not stop its native sensor collection, so it was not a valid fully-disabled-backend comparison.

OCCT's separate sensor log still had gaps after the FanControl workaround (up to 10.694 seconds in the final run). That issue remains unresolved; the two programs have not been proven to share the same cause.

Is there a known blocking condition in this AMD D3D query path, or a preferred targeted trace/minimal reproduction to distinguish the LHM call from driver delays or competing monitoring software?