Ενα συνηθισμενο προβλημα που εμφανιζεται στα windows ειναι τα random spikes της cpu. Η διαρκεια τους μπορει να ειναι απο 1-2 δευτερολεπτα εως και καποια λεπτα της ωρας. Αποτελεσμα αυτων, τα στιγμιαια κολληματα του υπολογιστη χωρις προφανη λογο. Enter Process Explorer. Προκειται για τον κλασικο task manager των windows με αναβολικα, δημιουργος του οποιου ειναι ο Mark Russinovich.
|
Photo 1 |
Οι πληροφοριες που προσφερει μπορει να προκαλεσουν ευχαριστο πονοκεφαλο. Απο τα DLLs και τα threads που χρησιμοποιει η εκαστοτε process, μεχρι το αν το προγραμμα που εχετε επιλεξει χρησιμοποιει το DEP και το ASLR . Οταν λοιπον το συστημα μας, εμφανιζει συμπεριφορα…λοξιγκα, με ενα απλο ανοιγμα του process explorer θα βρουμε ποιος καταναλωνει τα Ghz μας, σερνοντας απλα τον κερσορα του ποντικιου στο peak της cpu στο σχεδιαγραμμα του System Information και μονο (Photo 2). Τις περισσοτερες φορες τετοια στιγμιαια spikes στη cpu προερχονται απο legitimate προγραμματα κ εχουν λογο υπαρξης, δεν μιλαμε δηλαδη για bugs.
|
Photo 2 |
Ενα scan απο το antivirus (πχ το Eset Antivirus/Smart Security μετα απο καθε update των definitions του, απο default κανει ενα scan των αρχειων που ειναι στο Quarantine), ο searchindexer των windows που ανανεωνει την cache του και αλλα παρομοια μπορουν να προκαλεσουν τετοια cpu spikes.
|
Photo 3 |
Υπαρχουν φυσικα περιπτωσεις οπου καποιο malware ειναι ο ενοχος. Με την ιδια λογικη που ανεφερα πριν, εντοπιζουμε τον υπευθυνο και πραττουμε αναλογως (kill process,ελεγχος των αρχειων/dlls που χρησιμοποιει, malware scan σε safe mode κλπ κλπ). Τελος υπαρχουν και οι εξαιρεσεις. Οπου η cpu καταπονειται απο καποιο process αλλα δεν μπορουμε να δουμε απο ποιο.Μια τετοια περιπτωση ειναι η παρακατω: Ο process explorer μας ενημερωνει πως η cpu χρησιμοποιειται στο 50% και ο υπαιτιος ειναι το process System (Photo 3). Πρωτο βημα μας ειναι να ανοιξουμε τα properties του System (double click στον process explorer) και να παμε στο tab Threads. Εκει- και αφου επιλεξουμε την καταταξη των threads με φθινουσα χρηση της cpu- θα δουμε ποια threads μεσα στο System, προκαλουν το προβλημα.
Σημαντικη σημειωση: Προκειμενου o process explorer να εμφανιζει σωστα τα ονοματα των threads οποιουδηποτε process, θα πρεπει να τον ενημερωσετε με το path των debugging symbols για να κανει σωστα τη “μεταφραση”. Θα πρεπει λοιπον να πατε κατα σειρα στο Options –> Configure Symbols.. και εκει στο Symbols Path να δηλωσετε τον symbol server της Microsoft ως εξης
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Και παλι ομως δεν σημαινει πως ολα τα παραπανω ειναι αρκετα για να βρουμε το “προβληματικο” thread. Εαν ειμαστε τυχεροι το thread με την μεγαλυτερη καταναλωση cpu θα εχει αποκαλυπτικη Start Address, για παραδειγμα την VboxNetFlt.sys+0x29a0. Εαν δεν μας ειναι προφανες τι ακριβως ειναι ο VboxNetFlt.sys, ενα γρηγορο googling θα μας ενημερωσει πως προκειται για καποιο driver του Virtual Box.Στη συνεχεια ψαχνουμε για τυχον ανανεωμενη εκδοση του συγκεκριμενου driver,ριχνουμε μια ματια στα support προγραμματος και ουτε ο καθεξης.Case solved.
|
Photo 4 |
Tι γινεται ομως οταν το προβληματικο thread ειναι της μορφης ntoskrnl.exe!KdPollBreakIn+0x1a0 ή καποιο απο τα παρεμφερη ntoskrnl.exe, ntkrnlpa.exe (οπου ntoskrnl.exe, το kernel image των windows) που τρεχουν κατα δεκαδες στο μηχανημα μας?Εκει η επιλογη Stack του process explorer θα μπορουσε να μας λυσει τα χερια, αλλα κατι τετοιο δεν επιτρεπεται απο την Microsoft (Photo 4). Το System αποτελει protected process των windows και δεν επιτρεπει την προσβαση στα threads και τη μνημη του.Ας ειναι καλα το DRM καθως αυτος ειναι ο σκοπος των protected processes.
Σ αυτη την περιπτωση λοιπον, αφηνουμε τον process explorer και παμε σε ενα αλλο tool της Microsoft το Windows Performance Toolkit. Το εργαλειο που θα χρησιμοποιησουμε ειναι ενα command line utility, το xperf.exe. Η εγκατασταση του γινεται μεσω του web installer του Windows SDK και επιλεγοντας μονο τα Win32 Development Tools, οπως φαινεται και στη photo 5. Στη συνεχεια θα πρεπει να παμε στο φακελο
C:\Program Files\Microsoft SDKs\Windows\v7.0\bin οπου και θα βρουμε μεταξυ αλλων 3 διαφορετικα .msi, τα wpt_ia64.msi,
|
Photo 5 |
wpt_x64.msi και wpt_x86.msi, εκ των οποιων κανουμε εγκατασταση αυτο που ταιριαζει με την αρχιτεκτονικη του OS μας (x64 για 64bit windows, x86 για 32bit και ia64 για windows itanium) –Edit:Οπως παρατηρησε ο Nitrah, απο το .net 4 και μετα υπαρχουν καποιες μικροαλλαγες στους φακελους εγκαταστασης και στον installer, αναφερομαι σε αυτες στο 2ο σχολιο— Σε περιπτωση που το συστημα μας ειναι x64, θα πρεπει να προχωρησουμε σε μια ακομα ρυθμιση προκειμενου να τρεξει σωστα το xpref. Θα πρεπει να αλλαξουμε ενα κλειδι στη registry. Πηγαινουμε στο
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
και εκει αλλαζουμε το DisablePagingExecutive απο 0 σε 1. Εαν δεν υπαρχει το συγκεκριμενο dword, το δημιουργουμε χειροκινητα. Restart και ειμαστε ετοιμοι να χρησιμοποιησουμε το xperf. Ανοιγουμε ενα command prompt με administrative rights, πηγαινουμε στο root καποιου απο τους δισκους μας (cd \ ή d: κλπ) και με την εντολη
xperf -start perf!GeneralProfiles.InBuffer
|
Photo 6 |
ξεκιναμε το capture της αποδοσης του συστηματος μας, το οποιο θα συνεχιστει εως οτου το σταματησουμε χειροκινητα. Προκειμενου να εντοπισουμε το προβλημα στην περιπτωση που αναφερομαι ποιο πανω, θα πρεπει να εχουμε το xperf να τρεχει στο backround μεχρι να παρατηρησουμε τα spikes στη cpu, ετσι ωστε οι απαραιτητες πληροφοριες οσον αφορα τα spikes, να υπαρχουν μεσα στο capture που πραγματοποιουμε. Ενα tricky σημειο που προεκυψε καθως εγραφα αυτο τον οδηγο, ειναι η αναγκη να ξερω ποτε εμφανιζει spikes η cpu, θα πρεπει να το δω με καποιο τροπο, ενω παιρνω το capture. O τροπος που επελεξα (..προφανως) ηταν ο process explorer. Δυστυχως ομως οταν ειχα ανοιχτο τον process explorer και ταυτοχρονα προσπαθουσα να παρω καποιο capture με το xperf, επαιρνα το μηνυμα λαθους που εμφανιζεται στη photo 7.Υποθετω πως εχει να κανει με τη λειτουργια του process explorer και με καποια σχεση που εχει με το xperf, μια και το ιδιο το xperf με ενημερωνει πως το αρχειο που παει να κανει capture χρησιμοποιειται εκεινη τη στιγμη. Οπως και να χει το μικρο αυτο προβλημα, λυνεται φορτωνοντας τον Resource Monitor για την παρακολουθηση της cpu.
|
Photo 7 |
Αφου λοιπον παρατηρησουμε τα spikes της cpu του προβληματος μας στον resource monitor, μπορουμε να σταματησουμε το capture του xperf και να το σωσουμε στο δισκο μας.
Αυτο γινεται με την εντολη
xperf -stop perf!GeneralProfiles.InBuffer PerformanceCapture.etl
οπου PerformanceCapture.etl το ονομα του αρχειου που θα σωσουμε το capture.Τελος
αυτο που απομενει ειναι να ανοιξουμε το PerformanceCapture.etl με τον Windows
Performance Analyzer και να αρχισουμε το..σκαλισμα μεσα στις εκατονταδες
πληροφοριες και charts που διαθετει.
|
Photo 8 |
Μια τελευταια παρατηρηση, οταν ανοιγουμε τον Windows Performance Analyzer και ενω
ειμαστε σε administrator mode, ενα μηνυμα μας ενημερωνει πως η αναλυση καλο θα ειναι
να μην γινει με τα ιδια δικαιωματα (administrator), για αποφυγη τυχον buffer overflows τα
οποια μπορει να εχουν αρνητικο αντικτυπο στο συστημα μας. Eπιλεγουμε Yes,δεν
επηρεαζει καθολου την αναλυση μας.
Καλησπέρα Gio , το Link που μας έδωσες για να κατεβάσουμε το Microsoft Windows SDK for Windows 7 and .NET Framework είναι το version 4 και αυτά που πρέπει να εγκαταστήσουμε δεν μοιάζουν με αυτά της φωτογραφίας 5 που έχεις βάλει στο tutorial.Είναι κάπως έτσι : http://i51.tinypic.com/2lazucw.jpg
Τι από όλα αυτά πρέπει να κάνουμε Instal ?
Οντως απο το .net 4 εχει αλλαξει ελαφρως ο installer.Επελεξε και τα 2 Windows Performance Toolkit, απο τo Common Utilities και το Redistibutable Packages
Με το .net 4 ,αλλαζει και το directory οπου θα βρεις τα wpt_ia64.msi,
wpt_x64.msi και wpt_x86.msi. Βρισκονται στ
Redist\Windows Performance Toolkit subdirectory του SDK.