Παει μπολικος καιρος απο το πρωτο μερος, σε σημειο που σε λιγο θα αναλυουμε τις bsod με βαση το emoticon τους (credits to liopyr). Αλλα καλλιο αργα..Παμε λοιπον. Οταν ερθει η ωρα που θα συναντησουμε για μια ακομα φορα το μισητο μπλε χρωμα και αφου τελειωσουμε με τα πατροπαραδοτα @#%$^#!!, μπορουμε με μερικα απλα βηματα και μια δοση λογικης να εντοπισουμε τι προκαλεσε το προβλημα.
Βασικα συστατικα αποτελουν τα debugging tools για windows (εκδοση 64bit ή 32bit), τα οποια δεν ερχονται πια ως μεμονωμενο download απο το site της Microsoft, αλλα σαν μερος του Windows SDK. Δεν αποτελει προβλημα το συγκεκριμενο, απλα θελει μερικα κλικ παραπανω για να φτασουμε στο στοχο μας. Download του web installer, επιλογη των Debugging Tools for Windows οπως φαινεται και στην διπλα εικονα και ειμαστε ετοιμοι.
Μπορουμε επισης να επιλεξουμε και το Redistributable Package των Debugging Tools, εαν θελουμε να παρουμε και το εκτελεσιμο της εγκαταστασης τους και να γλυτωσουμε το κατεβασμα του SDK την επομενη φορα που θα χρειαστει να κανουμε εγκατασταση τα συγκεκριμενα. Ενα δευτερο συστατικο, οχι ομως και υποχρεωτικο, αποτελουν τα symbol packages για Windows. Τα συγκεκριμενα βοηθουν τον
debugger να αναγνωρισει τα ονοματα των functions και των entry point offsets που χρησιμοιουνται στο αρχειο το οποιο εχουμε φορτωσει. Με μια επισκεψη στο link των symbol packages θα δει κανεις, πως τον περιμενει αρκετο download σε περιπτωση που θελει ολα τα symbols (windows 2000 μεχρι windows 8 developer preview την ωρα που γραφονται αυτες οι γραμμες), για διαφορετικες αρχιτεκτονικες (x86 εως itanium). Επιπροσθετα, η εγκατασταση αυτων θα χρειαστει μερικα gigabytes αποθηκευτικου χωρου. Ο λογος που μπορει να χρειαζεται καποιος τα προαναφερθεντα packages, δεν ειναι αλλος απο την δυνατοτητα που του δινουν για debugging σε μηχανηματα τα οποια δεν εχουν προσβαση στο internet. Σε διαφορετικη περιπτωση, η ιδανικη λυση ειναι να χρησιμοποιησουμε τον symbol server της Microsoft. Ανοιγουμε τον Windows Debugger και δηλωνουμε στο symbol path την διευθυνση του:
srv*http://msdl.microsoft.com/download/symbols
Ενα trick το οποιο μπορει να χρησιμοποιησουμε εαν εχουμε ηδη στο σκληρο μας symbols απο προηγουμενα debugging ή καποιο symbol package, να ζητησουμε απο τον debugger να ψαχνει πρωτα στον τοπικο φακελο και στη συνεχεια να απευθυνεται στον server της microsoft για οτι δεν βρισκει. Το οποιο γινεται προσθετοντας στο path των symbols το παρακατω:
srv*c:\symbols*http://msdl.microsoft.com/download/symbols
οπου c:\symbols ο φακελος με τα τοπικα symbols. Σε περιπτωση που ο debugger δεν βρει αυτο που ζηταει, θα συνεχισει το ψαξιμο στον server της microsoft και θα κρατησει αντιγραφο στον συγκεκριμενο φακελο, δημιουργωντας ετσι μια symbol cache στον τοπικο μας δισκο. Αφου τελειωσαμε με τα διαδικαστικα, ωρα να ανοιξουμε ενα crash dump.
Μετα απο καθε μπλε οθονη θεωρητικα τα windows γραφουν μια αναφορα του τι συνεβαινε στον υπολογιστη τη συγκεκριμενη στιγμη (minidump, kernel memory dump). Και λεω θεωρητικα, καθως υπαρχουν περιπτωσεις οπου δεν ειναι δυνατη η αποθηκευση των συγκεκριμενων πληροφοριων (system hang/froze, σοβαρο προβλημα του σκληρου, κ.ο.κ). Το οποιο με τη σειρα του θα πρεπει να αποτελει ενδειξη hardware προβληματος ή software προβληματος διαφορετικο απο τα συνηθισμενα, το οποιο θα πρεπει να αντιμετωπισουμε με τον τροπο που αναφερω στο
Gimme BSOD (part 1).
Ας πουμε λοιπον πως εχουμε να αντιμετωπισουμε μια τυπικη μπλε οθονη, η οποια οφειλεται σε software προβλημα. Επιλεγουμε στον windows debugger “Open Crash Dump”. Αμεσως ο debugger θα ξεκινησει την προκαταρκτικη αναλυση με τη βοηθεια των symbols. Να τονισω πως σε περιπτωση που πραγματοποιουμε offline debugging και κανουμε χρηση symbol packages, καλο ειναι να γνωριζουμε το λειτουργικο και την αρχιτεκτονικη του μηχανηματος απο το οποιο προερχεται το crash dump, για να εχουμε τα βελτιστα δυνατα αποτελεσματα. Οπως φαινεται και απο την διπλανη εικονα, ο debugger εχει κανει ηδη καλη δουλεια και μας ενημερωνει πως το προβλημα πιθανοτατα προερχεται απο ενα συγκεκριμενο driver, τον pci.sys. Oλα οκ μεχρι εδω, με μια μικρη ενσταση. Ο συγκεκριμενος driver αποτελει μερος των Windows και ειναι digitaly signed απο την Microsoft. To οποιο σημαινει πως εχει περασει ουκ ολιγo debugging μεχρι να καταληξει να αποτελει μερος των Windows, debugging με καθε δυνατο configuration στο οποιο μπορει να εχει προσβαση η Microsoft. Με αλλα λογια οι πιθανοτητες να μην φταιει οντως ο συγκεκριμενος driver ειναι αρκετα μεγαλες. Γι αυτο λοιπον, θα ακολουθησουμε την προτροπη του ιδιου του debugger και θα δωσουμε την εντολη
!analyze -v
Tο αποτελεσμα φαινεται στην προηγουμενη φωτογραφια. Ο debugger επιμενει πως το module το οποιο προκαλει το προβλημα ειναι το pci.sys. Αναφερει ομως και κατι αλλο: X64_0x9F_3_
athrx_IMAGE_pci.sys. Τι μπορει να σημαινει το συγκεκριμενο? Κατι οντως χρησιμοποιει τον pci.sys και προκαλει το προβλημα. Μενει να βρουμε τι ειναι αυτο το κατι. Το μηχανημα απο το οποιο προερχεται το συγκεκριμενο minidump ειναι laptop Fujitsu Lifebook. Εμφανιζε
μπλε οθονη κατα το hibernation και μονο. Ειχε λοιπον ενα συγκεκριμενο pattern. Ριχνοντας μια ματια στα τεχνικα χαρακτηριστικα του, ξεχωριζει μια pci συσκευη του. Η καρτα ασυρματου δικτυου με
Atheros chipset. Μοιαζει να ταιριαζει με την περιπτωση μας, σωστα? Τα επομενα βηματα ειναι ο ελεγχος της εκδοσης driver για την καρτα ασυρματη δικτυου στο laptop και στη συνεχεια ελεγχος στο site του κατασκευαστη για νεωτερες εκδοσεις του, τα οποια και ελυσαν το προβλημα.
Υπαρχουν περιπτωσεις ομως οπου θα πρεπει να σκαψουμε βαθυτερα για να βρουμε τι φταιει. Μια σειρα απο εντολες που θα μας βοηθησουν ειναι οι ακολουθες:
- lm kv Εμφανιζει στον debugger τους drivers που ηταν φορτωμενοι στο συστημα λιγο πριν την μπλε οθονη. Ιδιαιτερα χρησιμη για να αναγνωρισουμε τυχον προβληματικους drivers, την version τους, καθως και το timestamp τους. Ανεξαρτητως σταθεροτητας απαρχαιωμενοι drivers θα πρεπει παντα να ανανεωνονται ή τουλαχιστον να ελεγχονται για προβληματα ασφαλειας.
- !vm Εμφανιζει πληροφοριες σχετικα με τη μνημη. Μπορει να βοηθησει στον εντοπισμο drivers με memory leaks
- !poolused Μπορει να χρησιμοποιηθει σε crash dumps απο Windows Server συστηματα (μπορει να ενεργοποιηθει και σε desktop μηχανηματα). Εμφανιζει πληροφοριες σχετικα με τα kernel memory pools και τη χρηση τους απο τους drivers του συστηματος. Να σημειωσω πως το συγκεκριμενο αναφερεται μονο στους drivers της Microsoft. Προκειμενου να μπορεσουμε να συνδιασουμε συγκεκριμενο pooltag με συγκεκριμενο 3rd party driver θα πρεπει να καταφυγουμε στη χρηση καποιου hex editor (ή του strings) προκειμενου να δουμε εαν το pooltag του driver ταιριαζει με καποιο απο αυτα που υπαρχουν στα kernel memory pools.
- !deadlock Σε συνεργασια με τον Driver Verifier και στην περιπτωση που εμφανισει μηνυμα πως εντοπισε καποιο deadlock, η εντολη αυτη θα βοηθησει στον αμεσο εντοπισμο του προβληματος.
- !thread Πληροφοριες για το συγκεκριμενο thread που ετρεχε τη στιγμη της μπλε οθονης.
- !process 0 0 Πληροφοριες σχετικα με τις διεργασιες που ετρεχαν πριν την μπλε οθονη.
- !irp ακολουθουμενο απο το IRP της επιθυμιας μας. Η συγκεκριμενη εντολη μπορει να αποδειχθει χρησιμη σε περιπτωσεις corrupted stack.
Να τονισω πως στη περιπτωση Fujitsu Lifebook, υπηρχαν 2 minidumps, τα οποια “εδειχναν” τον ιδιο driver και σε συνδυασμο με το pattern που ανεφερα προηγουμενως και τα χαρακτηριστικα του μηχανηματος, οι πιθανοτητες να φταιει οντως ο συγκεκριμενος driver ηταν αρκετα υψηλες.
Ο debugger απο μονος του δεν θα ειναι παντα σωστος. Θα πρεπει να λαμβανουμε υποψην ολες
τις παραμετρους του προβληματος. Οσο μεγαλυτερο το δειγμα (minidumps, kernel dumps) τοσο πιο ασφαλες το συμπερασμα. Drivers οπως ο win32k.sys εχει 99% πιθανοτητες να μην φταιει για καμια μπλε οθονη στον κοσμο. Το 70% των μπλε οθονων οφειλονται σε buggy 3rd party drivers και το 15% σε corrupted memory (αρα πιθανοτατα και παλι σε 3rd party drivers). Εαν στα 10 minidumps τα 4 “δειχνουν” windows drivers, το 1 αυτους της καρτας δικτυου, τα 3 της GPU και το ενα ειναι corrupted, τοτε μαλλον μιλαμε για ενα απο τα “δυσκολα” crashes. Καλα θα κανουμε να ελεγξουμε το hardware μας πρωτα, ενω θα πρεπει να ειμαστε προετοιμασμενοι να χρησιμοποιησουμε
τον driver verifier εαν χρειαστει. Τελος να αναφερω πως υπαρχουν επι πληρωμη tools απο την ιδια τη Microsoft τα οποια πραγματοποιουν μια στοιχειωδη αυτοματοποιημενη αναλυση των crash dumps. Δεν υπαρχει λογος να μην στραφει κανεις σε αυτα, εκτος απο το οτι 1ον δεν ειναι δωρεαν, 2ον χρησιμοποιουν μονο 2-3 στοιχειωδεις εντολες για την αναλυση, 3ον where’s the fun? 🙂
Aς κλεισω με τη σοφια της ημερας.
Υποθεσεις και γιατροσοφια του στυλ “Ναι,ειχα και γω μπλε οθονη σ ενα pc του θειου μου, αλλαξα την ταινια του σκληρου και εφτιαξε. Καντο και συ, αυτο ειναι” ή “Εχω διαβασει πως το ταδε παιχνιδι προκαλει προβληματα, απεγκατεστησε το”, ειναι το λιγοτερο βλακωδεις για προφανεις ελπιζω λογους.
Περα απο την τεχνικη καταρτηση, οπως και σε καθε προβλημα, η κοινη λογικη ειναι ιδιαιτερα χρησιμη για την επιλυση του..
debugger να αναγνωρισει τα ονοματα των functions και των entry point offsets που χρησιμοιουνται στο αρχειο το οποιο εχουμε φορτωσει. Με μια επισκεψη στο link των symbol packages θα δει κανεις, πως τον περιμενει αρκετο download σε περιπτωση που θελει ολα τα symbols (windows 2000 μεχρι windows 8 developer preview την ωρα που γραφονται αυτες οι γραμμες), για διαφορετικες αρχιτεκτονικες (x86 εως itanium). Επιπροσθετα, η εγκατασταση αυτων θα χρειαστει μερικα gigabytes αποθηκευτικου χωρου. Ο λογος που μπορει να χρειαζεται καποιος τα προαναφερθεντα packages, δεν ειναι αλλος απο την δυνατοτητα που του δινουν για debugging σε μηχανηματα τα οποια δεν εχουν προσβαση στο internet. Σε διαφορετικη περιπτωση, η ιδανικη λυση ειναι να χρησιμοποιησουμε τον symbol server της Microsoft. Ανοιγουμε τον Windows Debugger και δηλωνουμε στο symbol path την διευθυνση του:
ωραιος!