Gemini si to myslí taky:
Ahoj! Koukám na to a ta kombinace symptomů je poměrně specifická, zvlášť pro fungl nový stroj. Škoda, že mě tam nepustil firewall Rootu, abych si početla celou diskuzi, ale z toho, co popisuješ, se dá poskládat hned několik velmi podezřelých stop.
Když vynechám klasické IT základy (jako že bez MemTestu86 a Prime95/Cinebench se dál nehneme), hned mě praštilo do očí několik věcí. Tady je můj rozbor, od čeho se odpíchnout, a jsem zvědavá, jestli se na konci trefím do tvé teorie.
1. Stopa nejžhavější: Změna spřažení (Affinity) na E-jádra
Tohle je extrémně podezřelý krok, zvlášť u kritických systémových procesů jako dwm.exe (Desktop Window Manager), csrss.exe (Client Server Runtime Process) a explorer.exe.
Windows 11 a jejich Thread Director velmi úzkostlivě hlídají, kam který proces plánují.
Problém: csrss a dwm jsou kritické pro vykreslování GUI a správu subsystémů. Jakmile v Task Manageru klikneš na řazení podle CPU, Task Manager začne masivně dotazovat systém (přes WMI/NtQuerySystemInformation) na stav všech vláken. Pokud jsi předtím omezil klíčové systémové procesy pouze na E-jádra, mohl nastat Deadlock (uříznutí priorit).
E-jádra sdílejí cache jinak, mají jinou latenci a nižší prioritu. Systémový proces mohl čekat na odpověď od jiného vlákna, které běželo na P-jádru, ale kvůli vynucenému spřažení na E-jádro nedošlo k synchronizaci a GUI kompletně zamrzlo (proto nereagoval ani CapsLock – ten u moderních strojů často obsluhuje softwarově právě kernel přes ovladač klávesnice, nikoli čistý hardware).
2. Stopa hardwarová: WHEA-Logger ID 17 (Samsung 980 Pro)
Chyby WHEA (Advanced Error Reporting) na PCIe endpointu u NVMe disku jsou sice hlášeny jako "opravené" (Corrected Error), ale v idle stavu tam nemají co dělat.
Link State Power Management (ASPM): Moderní notebooky v idle stavu agresivně uspávají PCIe linky (stavy L0s, L1). Samsung 980 Pro je sice skvělé SSD, ale v některých kombinacích s čipsety (Intel/AMD) a agresivním ASPM ve Windows 11 trpí na micro-freezy při probouzení PCIe linky z hlubokého spánku.
Pokud disk na chvíli "odpadl" z PCIe sběrnice zrovna ve chvíli, kdy Task Manager v idle stavu potřeboval zapsat log nebo načíst stránku z pagefile (pokud je na něm), systém šel okamžitě do BSOD – kterou jsi ale neviděl, protože grafický subsystém (dwm na E-jádru) už byl v komatu.
3. Stopa ptydepe: Smart card reader & UICC
Hláška MS UICC Reader odmítla IOCTL power: datová oblast je příliš malá ukazuje na interní eSIM/SIM slot nebo čtečku čipových karet (časté u ThinkPadů, soudě podle další hlášky TP-WMI).
Opět jsme u Power Managementu v idle stavu. Systém se pokusil poslat čtečku karet (nebo WWAN modul) do úsporného režimu (D3), ovladač vrátil nesmyslnou chybu (špatná velikost bufferu pro IOCTL) a power transition selhalo. To samo o sobě málokdy shodí celý OS, ale v kombinaci s rozhozeným ACPI to k nestabilitě přispěje.
4. Stopa hromadná: TP-WMI 1282 (TBS device identifier)
Spousta hlášek od ThinkPad WMI (TP-WMI) týkajících se TBS (TPM Base Services) značí, že se systém neustále dotazoval TPM čipu nebo bezpečnostního koprocesoru. Task Manager (nebo na pozadí běžící HWInfo/HWMonitor) mohl přes WMI cyklit dotazy na senzory, což v idle vedlo k zahlcení WMI repozitáře.
Moje hypotéza, jak se to sešlo:
Notebook přešel po hodině v idle do hlubokého úsporného stavu (modern standby / agresivní link power management). PCIe linka disku Samsung 980 Pro se uspala (WHEA ID 17). V tu chvíli jsi pohnul nově připojenou USB myší, čímž jsi poslal přerušení. Systém se začal probouzet.
Ty jsi kliknul v Task Manageru na řazení podle CPU. Task Manager začal přes WMI (které už předtím cyklilo na TPM/TBS chybách) bušit do procesoru. Klíčové procesy (dwm, csrss), které jsi ručně uvěznil na E-jádrech, nedostaly dostatek procesorového času nebo se zasekly na zámku (locku) v kernelu, protože čekaly na IO operaci z disku, který se kvůli ASPM probral s chybou. Výsledek? Hard freeze, totální vytuhnutí celého managementu napájení a grafiky, pomohlo až hardwarové odříznutí napájení (15s power button).