Vše se zpomalí a nakonec to zdechne... to nezní jako že "se náhle potkal motor s motorem", spíš něco sežralo všechnu paměť nebo procesor, eventuelně může přihnívat disk (buď kabel nebo samotná mechanika/médium tzn. vadné sektory). Toto by mělo být pozorovatelné a rozlišitelné. Třeba já jsem přestal používat Firefox pod Windows proto, že zejm. při větším množství tabů má sklon občas uletět ve spotřebě RAM a poslat OS do kotrmelců. Widle se prostě během pár desítek sekund uswapujou do té míry, že nezbývá, než je násilím restartovat (v lepším případě stihnete zabít FF a pak widle restartnout se všemi lichotkami a poctami, protože ta RAMka je zřejmě i tak už dost zfragmentovaná nebo co).
Kolik má ten stroj RAMky?
Taky si vybavuju situace, kdy běžící Windows Update service (nebo co) nemá svoji spotřebu řádně zohledněnu ve Správci Procesů - prostě se to tváří, jako že RAMky je dost, přestože reálně se ten stroj už dusí. Onehdá jsem už koukal, kde je schovaný nějaký rootkit apod. parazit, ale nakonec jsem naznal, že to jenom Windows Update přepočítává databázi závislostí, odmocňuje pí nebo co a tak podobně. Podobně se může chovat počáteční indexace zabudovaného fulltextového vyhledávání, nebo třeba pravidelný antivirový sken... Taky jsem zejm. s menším objemem RAM v určitých situacích pozoroval, že má microsoftí "engine pro správu databáze závislostí" v rámci Windows Update sklon, divergovat do jakéhosi podivného limba, kdy prakticky nešáhne na disk, ale žere celé CPU jádro a poměrně dost paměti, a když ho necháte, tak v téhle zfetované nirváně vydrží neomezeně dlouho (klidně přes víkend, tzn. obvykle do tvrdého restartu). Sice byly v průběhu let nějaké updaty, které to měly řešit, pokaždé "tentokrát už doopravdy", ale vídám to od dob Win7 skrz Win8 (zejm. před 8.1) až po některé konkrétní updaty Win10... Nebo se to pravidelně stane v případě, kdy
použiju DISM na úklid WinSXS - nezávisle na objemu RAM.
Pod Windows býval standardní součástí systému prográmek "resource monitor" = resmon.exe. Tuším v novějších windowsech (10 a nové servery) se velká část dříve unikátních schopností Resmonu překlopila i do standardního "správce procesů" - jako třeba schopnost sledovat disk I/O transakce per proces, taky tuším nově jde vidět spotřeba jednotlivých servisek (nikoli pouze svchost.exe jako celek) apod. Takže doporučuji nastartovat na té vzdálené ploše resmon nebo jeho moderní ekvivalent a nechat běžet na liště. V momentě, kdy "se všechno zpomalí", rychle ho otevřít a podívat se, co se přesně děje, než to celé padne na hubu.
Rozlišit "disk se fláká, nejde na něj skoro žádný provoz" od "disk se nefláká, ale drhne, a proto si bere už jenom čůrek provozu" se dá nejsnáz pohledem na activity LEDku disku. Což předpokládá, že ten vzdálený počítač nějakou diskovou LEDku ještě má, a že je poblíž někdo, kdo by se podíval. Případně
pro Windows existuje port smartctl.exe z balíku Smartmontools - ten taky ledacos ukáže. Neukáže sice activity LEDku, ale obsah SMART tabulky disku včetně logu chyb taky není k zahození :-) Bohužel to není až tolik užitečné na flashky/SSDčka.
A pokud to končí modrou, a podstatou není havárie v oblasti přístupu na disk, měl by na disku zůstat "bobek" zvaný crashdump. Ze kterého např. nástroj
WhoCrashed dokáže zjistit aspoň driver, který modrou údajně hodil. Pokud je to pokaždé jiný driver, tak je problém ještě kdesi o kus dál = buď v HW nebo v jiném driveru, který hnojí náhodně kolem sebe.
Přeji úspěšný lov.