lhm-temp.exe process leak: 646 zombie processes consuming 11GB RAM

[naqoyqatsi83]

Summary

lhm-temp.exe spawns a new process for each hardware monitoring call but the child processes never terminate, accumulating as zombies. On my system this reached 646 concurrent lhm-temp.exe processes consuming 11 GB of RAM and causing system-wide freezes (seconds to minutes).

Environment

• OS: Windows 11 Pro (Build 26200)
• CPU: AMD Ryzen 7 9800X3D
• RAM: 64 GB
• Conky build: commit 011be497 (latest)
• LHM path: C:\Program Files\Conky\LibreHardwareMonitor\lhm-temp.exe
• LHM version: LibreHardwareMonitorLib.dll dated Feb 14, 2026

Steps to Reproduce

1. Install conky-windows with LibreHardwareMonitor integration
2. Run conky with hardware monitoring enabled (temperature/sensor widgets)
3. Leave running for several hours
4. Check Task Manager or run: tasklist /FI "IMAGENAME eq lhm-temp.exe" | find /c "lhm-temp.exe"

Observed Behavior

• Each sensor read spawns a new lhm-temp.exe process
• Processes crash with .NET clr.dll internal error (Event ID 1023 in Application log) but never exit
• After ~2.5 hours: 646 zombie processes, 11 GB total RAM, 36.7 minutes total CPU time
• Event log shows repeated: Application: lhm-temp.exe, Framework Version: v4.0.30319, The process was terminated due to an internal error
• The zombie accumulation causes severe system freezes due to memory pressure and paging

Event Log Evidence

Error 1023 (.NET Runtime): Application: lhm-temp.exe
  Framework Version: v4.0.30319
  Description: The process was terminated due to an internal error

This error repeats hundreds of times — one per leaked process.

Expected Behavior

lhm-temp.exe should either:

1. Be a single long-running process that conky communicates with (not spawned per-query), or
2. Properly terminate after each use, or
3. Conky should detect the stale/zombie processes and clean them up

Suggested Fix

The most likely issue is in how conky launches lhm-temp.exe. Options:

• Use a persistent helper process instead of spawning a new one per sensor read
• Add timeout/kill logic: if a previous lhm-temp.exe is still running when a new one is needed, kill the old one first
• Use named pipes or a local socket for IPC instead of repeated process spawning
• Cap concurrent instances: allow at most 1-2 lhm-temp.exe at any time

Impact

This is a critical issue — it turns a system monitor into a system destroyer. 646 zombie processes and 11 GB leaked RAM caused cascading freezes across the entire system, including unrelated applications.

Workaround

Periodically run:

taskkill /F /IM lhm-temp.exe

Or disable LHM hardware monitoring widgets in the conky config.

[naqoyqatsi83]

Fix applied

Patched launch_lhm_direct() in src/data/os/windows.cc to kill existing lhm-temp.exe processes before spawning a new one:

void kill_existing_lhm_helper() {
  HANDLE snap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
  if (snap == INVALID_HANDLE_VALUE) return;
  PROCESSENTRY32W pe = {sizeof(pe)};
  if (Process32FirstW(snap, &pe)) {
    do {
      if (_wcsicmp(pe.szExeFile, L"lhm-temp.exe") == 0) {
        HANDLE hProc = OpenProcess(PROCESS_TERMINATE, FALSE, pe.th32ProcessID);
        if (hProc) { TerminateProcess(hProc, 0); CloseHandle(hProc); }
      }
    } while (Process32NextW(snap, &pe));
  }
  CloseHandle(snap);
}

bool launch_lhm_direct() {
  kill_existing_lhm_helper();  // <-- added
  // ... existing spawn logic ...
}

This guarantees at most 1 lhm-temp.exe at any time. The root cause was that CreateProcessW spawned a new process without checking if a previous (crashed/zombie) instance was still alive.

Rebuilt and verified — no zombie accumulation after restart.