Debug

Az ‘ahogy azt Móricka elképzeli illetve megérti’ rovatból

Egyszercsak azon kaptam a gépemet, hogy a ha nincs csatlakoztatva töltőhöz, akkor a System folyamat 23-25 százalékot eszik meg a processzorból. Az első pánik után megcéloztam a Google-t a problémával. Három alap válaszfajtát találtam a System CPU zabálására:

1. Az valójában a System Idle Process, teljesen normális, hogy sokat eszik. Ezt főleg ott írták, ahol a probléma megértésére se fordítottak elég gondot, csak osztják az észt.
2. A Thinkpad fórumokon inkább a ‘mindjárt szét fog rohadni’ és az ‘enyém is ezt csinálta mielőtt kigyulladt’ - túlzok, bocsánat - jellegű pánik megy. A hardverhibával kapcsolatos gondolatokat el lehet hessegetni egy más verziójú, működő Windowst bootolva.
3. Az ember végül eljut a SysInternalsra, ahol ott várja Mark Russinovich cikke arról, hogy az ilyen típusú hibákat okát hogyan kell kinyomozni: The Case of the System Process CPU Spikes. Aki hasonló hibától szenved, az kattintson is tovább oda, itt már csak a kalandok leírása következik.

A Russinovich cikk megtalálása után valójában már nem nehéz az ügy. Ha szerencsénk van, akkor a SysInternalsról letölthető Process Explorer beszerzése, a Debugging Tools telepítsése és a Symbol szerver beállítása után lesz ötletünk, hogy mi történik. Vagy legalább arról, hogy milyen threadekre kéne rákeresni.

Nekem az ExpWorkerThread és az ntkrnlpa.exe volt az, ami a CPU-t ette, ezzel a rendszer dolgaira és a driverekre szűkítettük le a problémát, illetve száguldva hagytuk el azt a területet, ahol még értem mi történik. Innentől jött a bicskás hályogkovács üzemmód annak biztos tudatában, hogy a külső winchesteren egy néhány hetes teljes backup ül, amit egy óra alatt vissza lehet állítani rendszerestül, mindenestül.

A Process Explorer által duplakattra kiírt stack infótól nem lettem okosabb, úgyhogy a javasolt Kernrate Viewerrel néztem rá a kernel threadekre. (A -wx kapcsolóval nem zárja be azonnal az ablakot a figyelés megállítása után.) Az első lelet itt is az ntkrnlpa.exe volt, utána viszont következtek olyan nagyfogysztók (igaz csak 8 százalékkal), amit be tudtam azonosítani: ő volt az integrált Intel grafikus mag drivere. Itt ugrott be, hogy valóban nem a Lenovo által megszentelt régebbi videodriver van fent, hanem egy újabb.

Közjáték: miközben nyomoztam, lejött a többi driver legújabb példánya és felkerült egy igazából semmi fontosat nem tartalmazó, de ártani nem árthat osztályú BIOS update is. Ezek valamelyike kikapcsolta az ujjlenyomat-olvasót, amitől egyik ámulatból a másikba estem, de végül egyszerűen vissza lehetett kapcsolni.

A géphez járó ThinkVantage driverfrissítő nem szeret feleslegesen letölteni, az összes szükséges driver megvan többnyire helyben. A Lenovo áldását nem bíró Intel driver lekerült, majd reboot. A visszatéréskor kapott kép nem szép, csuklóból nem a normál felbontásra állt be a gép, viszont akárhogy húzgálom ki a tápot a System folyamat nem kezdi el rágni az erőforrásokat. Ezután felkerült a legfrissebb gyári driver, reboot, és most minden oké.

A legszebb persze az, hogy ez csak az egyik olyan probléma, ami az ntkrnlpa.exe megnövekedett éhségét okozhatja. Más fórumokban a fizikai cím kiterjesztésének (PAE) letiltása segített, ami persze egy 2 gigabájt memóriával rendelkező gépnél több mint vudu lett volna. Megint máshol a Norton Internet Security akadt össze úgy a hálózati driverekkel, hogy ilyen problémát okozott.

Hozzávalók:

• Process Explorer
• Debugging Tools for Windows
• Symbol csomagok, amiből szerencsére nem kell az összes, elég ha Process Explorer be tudja őket gyűjteni
• Kernrate Viewer