Πλήρης οδηγός για την ανάλυση BSOD και kernel dumps στα Windows

Informatec Digital » Πόροι » Πλήρης οδηγός για την ανάλυση BSOD και kernel dumps στα Windows

Όταν ένας υπολογιστής με Windows παγώνει με μπλε οθόνη, δεν είναι απλώς ενοχλητικό: συνήθως υπάρχουν πολύτιμες πληροφορίες κρυμμένες στη μνήμη Αυτό μας λέει ακριβώς τι συνέβη στον πυρήνα. Αντί να ρίχνουμε το φταίξιμο στη μνήμη RAM, στο BIOS ή στη μορφοποίηση με το πρώτο σημάδι προβλήματος, αξίζει να μάθουμε πώς να διαβάζουμε αυτά τα δεδομένα.

Με λίγη εξάσκηση, εργαλεία όπως το WinDbg και λειτουργίες όπως !analyze -v, .bugcheck ή η σωστή χρήση συμβόλων Μας επιτρέπουν να πάμε από το "Λαμβάνω ένα σφάλμα μπλε οθόνης" στο "Ξέρω ποιο πρόγραμμα οδήγησης, πόρος ή συσκευή προκάλεσε το BSOD". Σε αυτό το άρθρο, θα αναλύσουμε, βήμα προς βήμα και με αρκετή λεπτομέρεια, πώς να αναλύσουμε ένα BSOD χρησιμοποιώντας το dump του πυρήνα του, ποιοι τύποι dumps υπάρχουν, πώς να προετοιμάσουμε τα πάντα και ποιες εντολές να χρησιμοποιήσουμε για να αξιοποιήσουμε στο έπακρο την ανάλυση.

Τι είναι ένα BSOD και ποιες πληροφορίες περιέχει;

Όταν τα Windows αντιμετωπίζουν μια συνθήκη που Θέτει σε κίνδυνο την ακεραιότητα του συστήματος. και δεν μπορεί να ανακτήσει με ασφάλεια, κάνει μια εσωτερική κλήση πυρήνα που ονομάζεται KeBugCheckExΑυτή η κλήση είναι που ενεργοποιεί την περίφημη μπλε οθόνη του θανάτου (BSOD).

Το KeBugCheckEx λαμβάνει πάντα πέντε ορίσματα: ένας κωδικός STOP (κωδικός ελέγχου σφαλμάτων) y τέσσερις επιπλέον παράμετροι τα οποία παρέχουν τεχνικό πλαίσιο για την αποτυχία. Αυτά τα ίδια δεδομένα είναι αυτά που μπορούμε στη συνέχεια να συμβουλευτούμε:

• Στην μπλε οθόνη κλασικό, εάν το σύστημα δεν έχει ρυθμιστεί για αυτόματη επανεκκίνηση.
• Στο αρχείο καταγραφής συμβάντων των Windows, μέσα στο Πρόγραμμα προβολής συμβάντων (αρχείο καταγραφής συστήματος).
• Στο αρχείο ένδειξης σφαλμάτων μνήμης (minidump, kernel dump ή full dump), χρησιμοποιώντας WinDbg και εντολές όπως !analyze -v o .bugcheck.

Κάθε κωδικός ελέγχου σφαλμάτων έχει ένα συμβολικό όνομα και μια συσχετισμένη δεκαεξαδική τιμήΓια παράδειγμα, ο έλεγχος σφαλμάτων DRIVER_POWER_STATE_FAILURE έχει τον κωδικό 0x9FΕνώ ΔΕΝ ΕΙΝΑΙ ΙΔΙΟΚΤΗΣΙΑ ΤΟΥ ΠΟΡΟΥ αντιστοιχεί σε 0xE3Αυτοί οι κωδικοί και οι παράμετροί τους τεκμηριώνονται στην αναφορά κωδικών ελέγχου σφαλμάτων της Microsoft, την οποία θα πρέπει να έχετε πάντα πρόχειρη.

Εκτός από τον κώδικα, η μπλε οθόνη μπορεί να εμφανίσει το όνομα ενός προγράμματος οδήγησης .sys που φέρεται να εμπλέκεταιΑν πρόκειται για πρόγραμμα οδήγησης τρίτου κατασκευαστή (antivirus, κάρτα δικτύου, κάρτα γραφικών, κ.λπ.), συχνά έχουμε έναν σαφή ύποπτο. Αν αυτό που εμφανίζεται είναι ένα γενικό στοιχείο συστήματος (ntoskrnl.exe, win32k.sys…) ή δεν εμφανίζεται τίποτα απολύτως, θα πρέπει να χρησιμοποιήσουμε ένα αρχείο memory dump και το WinDbg για να ψάξουμε σε βάθος.

Τύποι dumps μνήμης στα Windows

Για να μπορέσουμε να αναλύσουμε ένα BSOD σε κάποιο βάθος, χρειαζόμαστε τα Windows για να δημιουργήσουν ένα αρχείο ένδειξης σφαλμάτων μνήμης (DMP) όταν παρουσιάζεται η βλάβη. Αυτό το αρχείο καταγράφει την κατάσταση του συστήματος τη στιγμή του σφάλματος και μπορεί να είναι διαφορετικών τύπων.

Στις επιλογές "Εκκίνηση και Επαναφορά" (κάντε δεξί κλικ στο "Αυτός ο υπολογιστής / Ο υπολογιστής μου" → Ιδιότητες → Ρυθμίσεις συστήματος για προχωρημένους → καρτέλα "Για προχωρημένους" → κουμπί "Ρυθμίσεις" στην ενότητα "Εκκίνηση και Επαναφορά"), μπορείτε να επιλέξετε ανάμεσα σε διάφορους τύπους dumps. Κάθε ένας έχει τα πλεονεκτήματα και τα μειονεκτήματά του.

Μικρή ένδειξη μνήμης (Minidump)

El minidump Είναι η μικρότερη μορφή (περίπου 64 KB) και επίσης η πιο περιορισμένη για προηγμένο εντοπισμό σφαλμάτων. Ωστόσο, εξακολουθεί να είναι χρήσιμη για λάβετε μια γρήγορη διάγνωση σε πολλά σενάρια BSOD.

Ένα minidump αποθηκεύει, μεταξύ άλλων δεδομένων:

• Το μήνυμα διακοπής, ο κωδικός ελέγχου σφαλμάτων και οι παράμετροί του.
• Το πλαίσιο του επεξεργαστή (PRCB) του επεξεργαστή που προκάλεσε την αποτυχία.
• Πληροφορίες διεργασίας πυρήνα (EPROSS) της ενεργής διεργασίας τη στιγμή της κατάρρευσης.
• Πληροφορίες νήματος στον πυρήνα (ETHREAD) του νήματος που προκάλεσε τη συντριβή.
• Η στοίβα κλήσεων σε λειτουργία πυρήνα για αυτό το νήμα (έως 16 KB).
• Λίστα φορτωμένων προγραμμάτων οδήγησης κατά τον χρόνο της απόφασης.
• Λίστα φορτωμένων και ληφθέντων ενοτήτων.
• Ένα μπλοκ δεδομένων εντοπισμού σφαλμάτων με βασικές πληροφορίες συστήματος.

Αυτός ο τύπος dump αποθηκεύεται συνήθως σε %SystemRoot%\Minidump (για παράδειγμα, C: \ Windows \ Minidump). Για πολλές περιπτώσεις βασικής υποστήριξης ή διαγνωστικών, ένα καλά αναλυμένο minidump με !analyze -v μπορεί να είναι περισσότερο από αρκετό.

Απόρριψη μνήμης πυρήνα

El dump μνήμης πυρήνα Περιέχει τα περιεχόμενα της μνήμης πυρήνα κατά τη στιγμή της κατάρρευσης, εξαιρουμένων των χώρων μνήμης διεργασίας χρήστη. Είναι μια πολύ ενδιαφέρουσα μέση λύση μεταξύ μεγέθους και λεπτομέρειας και συνήθως είναι η συνιστώμενη επιλογή για τη διάγνωση των περισσότερων BSOD.

Αυτή η απόδειξη αποθηκεύεται ως MEMORY.DMP en % SystemRoot% (αθέτηση, C:\Windows\MEMORY.DMPΤο μέγεθός του εξαρτάται από τη μνήμη που χρησιμοποιείται από τον πυρήνα, αλλά συνήθως είναι πολύ μεγαλύτερο από ένα minidump και πολύ πιο διαχειρίσιμο από ένα full dump.

Ολοκλήρωση αποτύπωσης μνήμης

El πλήρης αποτύπωση μνήμης Πρακτικά σώζει όλα τα περιεχόμενα της μνήμης RAM τη στιγμή του σφάλματος: πυρήνας, διεργασίες χρήστη, κ.λπ. Είναι το πιο λεπτομερές αλλά και αυτό που καταλαμβάνει τον περισσότερο χώρο και είναι το πιο απαιτητικό από άποψη διαμόρφωσης.

Για να είναι έγκυρη μια πλήρης καταγραφή, πρέπει να πληρούνται ορισμένες προϋποθέσεις:

• El αρχείο σελιδοποίησης πρέπει να είναι στο το ίδιο διαμέρισμα όπου είναι εγκατεστημένα τα Windows.
• Πρέπει να υπάρχει χώρος στο δίσκο τουλάχιστον ίσος με το μέγεθος της φυσικής μνήμης του μηχανήματος.
• Μην μετακινείτε το αρχείο σελιδοποίησης σε άλλον φυσικό δίσκο, εάν θέλετε να αποφύγετε τα κατεστραμμένα dumps.

Σε περιβάλλοντα παραγωγής με πολλή μνήμη RAM, μια πλήρης dump μπορεί να μην είναι πρακτική, αλλά για πολύπλοκες ή διαλείπουσες περιπτώσεις Μπορεί να κάνει όλη τη διαφορά όσον αφορά τον εντοπισμό του προβλήματος.

Ρύθμιση παραμέτρων των Windows για καταγραφή και καταγραφή BSOD

Πριν ασχοληθούμε με το WinDbg, είναι απαραίτητο να διασφαλίσουμε ότι το σύστημα Δημιουργεί σωστά τα dumps και καταγράφει το συμβάν από την μπλε οθόνη.

Στο παράθυρο "Έναρξη και Επαναφορά" βρίσκουμε αρκετές σχετικές επιλογές:

• Εγγραφή συμβάντος στο αρχείο καταγραφής συστήματοςΤο : πρέπει να είναι ενεργοποιημένο για να καταγραφεί ο έλεγχος σφαλμάτων στην Προβολή Συμβάντων.
• Εγγραφή πληροφοριών εντοπισμού σφαλμάτων: εδώ επιλέγουμε Minidump, Kernel memory dump ή Complete memory dump.
• διαδρομή αρχείου dump: προεπιλογή %SystemRoot%\MEMORY.DMP για πυρήνα/πλήρη έκδοση.
• Επανεκκίνηση αυτόματα: συνιστάται να το αποεπιλέξουμε αν θέλουμε παρακολουθώ ήρεμα την μπλε οθόνη και σημειώστε τι εμφανίζεται.

Για ορισμένους κατασκευαστές ή τμήματα υποστήριξης, όπως στην περίπτωση ορισμένων προσαρμογέων δικτύου, ο χρήστης καλείται να στείλτε το αρχείο dumpΣυνήθως βρίσκεται σε C:\Windows\memory.dmp και συνιστάται να το εντοπίσετε κατά ημερομηνία/ώρα για να εντοπίσετε αυτήν που αντιστοιχεί στην τελευταία βλάβη.

Αν αυτό που θέλουμε είναι η εξουσία αναγκαστική εκτέλεση dump ακόμα και όταν το σύστημα είναι παγωμένο (χωρίς να ανταποκρίνεται το πληκτρολόγιο ή το ποντίκι), υπάρχει επίσης ένα πολύ χρήσιμο κόλπο για πληκτρολόγια PS/2 (όχι USB/Bluetooth), το οποίο συνίσταται στη ρύθμιση παραμέτρων του μητρώου ώστε να ενεργοποιεί μια ένδειξη με έναν συνδυασμό πλήκτρων.

Επιβολή dump χρησιμοποιώντας το πληκτρολόγιο σε περίπτωση παγώματος

Για να δημιουργήσουμε ένα memory dump ακόμα κι αν η οθόνη είναι εντελώς παγωμένη, μπορούμε να χρησιμοποιήσουμε την επιλογή CrashOnCtrlScroll Αυτή η μέθοδος δεν είναι έγκυρη για πληκτρολόγια USB ή Bluetooth.

Στο μητρώο, πρέπει να δημιουργήσουμε ή να τροποποιήσουμε το ακόλουθο κλειδί:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Μετά την επανεκκίνηση, ανά πάσα στιγμή (ακόμα και με την οθόνη παγωμένη) θα μπορούμε να προκαλέσει ελεγχόμενη σύγκρουση και ότι το σύστημα δημιουργεί την ένδειξη μνήμης πατώντας το πλήκτρο Δεξί CTRL και μετά, Πατήστε δύο φορές το πλήκτρο Scroll LockΕίναι πολύ χρήσιμο για την διερεύνηση σκληρών σφαλμάτων που δεν εμφανίζουν από μόνα τους BSOD.

Εισαγωγή στο WinDbg για την ανάλυση dumps πυρήνα

Το WinDbg είναι το κατεξοχήν εργαλείο της Microsoft για... εντοπισμός σφαλμάτων πυρήνα και ανάλυση dump μνήμηςΕίναι διαθέσιμο δωρεάν (αυτήν τη στιγμή υπάρχει και στο Microsoft Store ως WinDbg Preview) και, παρόλο που μπορεί να φαίνεται τρομακτικό με την πρώτη ματιά, για μια αρχική ανάλυση BSOD χρειάζεται να διαχειριστούμε μόνο μερικές βασικές επιλογές.

Μπορούμε να εγκαταστήσουμε το WinDbg στον ίδιο τον υπολογιστή που έχει προσβληθεί ή σε οποιαδήποτε άλλη ομάδαΤο αρχείο .dmp μπορεί να αντιγραφεί μέσω δικτύου, μέσω USB ή ακόμα και να συμπιεστεί σε ένα αρχείο CAB. Ο επεξεργαστής και η έκδοση των Windows που χρησιμοποιήθηκαν για την ανάλυση της ένδειξης ενδέχεται να μην ταιριάζουν με αυτές του μηχανήματος που υπέστη σφάλμα.

Ξεκινήστε το WinDbg με ένα αρχείο dump από τη γραμμή εντολών

Ένας κλασικός τρόπος για να ανοίξετε ένα αρχείο μνήμης στο WinDbg είναι να χρησιμοποιήσετε τη γραμμή εντολών με την παράμετρο -z καθορίζοντας τη διαδρομή του αρχείου dump. Μπορούμε να το συνδυάσουμε αυτό με άλλες παραμέτρους όπως τη διαδρομή συμβόλου ή τη δυαδική διαδρομή:

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Ο τροποποιητής -v ενεργοποιήστε το λεπτομερής λειτουργία (λεπτομερής)το οποίο είναι πολύ χρήσιμο για να δείτε περισσότερα συμφραζόμενα. Εκτός από το WinDbg, υπάρχει επίσης kd.exe, μια έκδοση εντοπισμού σφαλμάτων που βασίζεται σε κονσόλα και σας επιτρέπει να κάνετε σχεδόν το ίδιο πράγμα αλλά χωρίς γραφική διεπαφή:

kd.exe -z "Ruta\al\volcado.dmp" -y "Ruta\simbolos" -i "Ruta\busqueda\binarios"

Άνοιγμα αρχείου dump από τη γραφική διεπαφή

Αν έχουμε ήδη ανοιχτό το WinDbg σε παθητική λειτουργία, μπορούμε να φορτώσουμε ένα αρχείο dump χρησιμοποιώντας το μενού. Αρχείο → Άνοιγμα αρχείου απόρριψης σφαλμάτων ή με τη συντόμευση Ctrl + DΕπιλέγουμε το αρχείο .dmp (ή ακόμα και ένα αρχείο .cab που το περιέχει) και το WinDbg θα φορτώσει τις πληροφορίες dump.

Μια άλλη εναλλακτική λύση είναι να εκκινήσετε το WinDbg και, αφού μπείτε μέσα, να εκτελέσετε την εντολή .opendump καθορίζοντας τη διαδρομή προς το αρχείο dump και στη συνέχεια την εντολή g (Μετάβαση) για να ξεκινήσει η συνεδρία εντοπισμού σφαλμάτων dump:

.opendump C:\Windows\Memory.dmp
g

Το WinDbg επιτρέπει ακόμη και καθαρίστε πολλαπλές χωματερές ταυτόχροναπροσθέτοντας αρκετές παραμέτρους -z στη γραμμή εντολών ή επαναλαμβάνοντας .opendump με διαφορετικές διαδρομές και διαχείριση της συνεδρίας πολλαπλών προορισμών.

Ρύθμιση παραμέτρων της διαδρομής συμβόλων στο WinDbg

Χωρίς σύμβολα, το WinDbg λειτουργεί πρακτικά τυφλά. Τα σύμβολα (.pdb) περιέχουν Πληροφορίες εντοπισμού σφαλμάτων σχετικά με συναρτήσεις, εσωτερικές δομές, μεταβλητές, μετατοπίσεις κ.λπ.και είναι απαραίτητα για αξιόπιστη ανάλυση, ειδικά όταν εργάζεστε με τον πυρήνα.

Για να χρησιμοποιήσετε τα δημόσια σύμβολα της Microsoft χωρίς να χρειάζεται να τα κατεβάσετε χειροκίνητα, η καλύτερη πρακτική είναι να διαμορφώσετε ένα διακομιστής συμβόλων που δείχνει στον επίσημο διακομιστή της Microsoft και σε έναν τοπικό κατάλογο προσωρινής μνήμης. Για παράδειγμα, μπορούμε να δημιουργήσουμε έναν φάκελο εκ των προτέρων. C:\σύμβολα και στη συνέχεια, στο WinDbg, ρυθμίστε τη διαδρομή συμβόλων ως εξής:

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

Αυτό μπορεί να γίνει από το μενού Αρχείο → Διαδρομή αρχείου συμβόλου ή, στην προεπισκόπηση WinDbg, από Αρχείο → Ρυθμίσεις → Ρυθμίσεις εντοπισμού σφαλμάτων Προσαρμογή της «Προεπιλεγμένης διαδρομής συμβόλων». Την πρώτη φορά που αναλύουμε μια ένδειξη από ένα συγκεκριμένο σύστημα, το πρόγραμμα εντοπισμού σφαλμάτων θα κατεβάσει αυτόματα τα απαραίτητα σύμβολα μέσω διαδικτύου, κάτι που μπορεί να διαρκέσει μερικά λεπτά ανάλογα με τη σύνδεση.

Θα πρέπει να σημειωθεί ότι τα δημόσια σύμβολα της Microsoft, σε ορισμένες περιπτώσεις, Δεν περιλαμβάνουν όλες τις εσωτερικές πληροφορίες τύπουΚαι θα δούμε προειδοποιήσεις όπως "Το πρόγραμμα εντοπισμού σφαλμάτων σας δεν χρησιμοποιεί τα σωστά σύμβολα" ή αναφορές σε μη επιλύσιμους τύπους. Για βασική ανάλυση BSOD, τα δημόσια σύμβολα είναι συνήθως επαρκή, αλλά αν χρειαστούμε περισσότερες λεπτομέρειες, θα υπάρχουν περιορισμοί.

Πρώτη ανάλυση: βασικές εντολές και έλεγχος σφαλμάτων

Μόλις φορτωθεί το dump και ρυθμιστούν τα σύμβολα, το WinDbg συνήθως εμφανίζει μια κεφαλίδα με πληροφορίες συστήματος και μια προειδοποίηση. «Χρησιμοποιήστε την εντολή !analyze -v για να λάβετε λεπτομερείς πληροφορίες εντοπισμού σφαλμάτων.»Αυτή είναι η πρώτη μας στάση για μια αρχική ανάλυση.

Η εντολή !analyze -v Εκτελεί μια αυτόματη ανάλυση της απόρριψης και συνήθως παρέχει:

• Ο κώδικας ελέγχου σφαλμάτων (για παράδειγμα, 0xE3, 0xD1, 0x9F, 0x44…).
• Οι παράμετροι Arg1, Arg2, Arg3 και Arg4 από τον έλεγχο σφαλμάτων.
• Η πιο πιθανή ενότητα ή πρόγραμμα οδήγησης αιτία της αποτυχίας (Probably caused by).
• Η σχετική διαδικασία εκείνη τη στιγμή (για παράδειγμα, Teams.exe).
• Η στοίβα κλήσεων (ιχνηλάτηση στοίβας) του νήματος που προκάλεσε τη συντριβή.
• Πληροφορίες κάδου και κατακερματισμοί σφαλμάτων, χρήσιμοι για τη συσχέτιση επαναλαμβανόμενων σφαλμάτων.

Για παράδειγμα, σε ένα σενάριο ελέγχου σφαλμάτων στον πραγματικό κόσμο ΔΕΝ ΑΝΗΚΕΙ ΣΕ ΠΟΡΟΥΣ (0xE3)Η ανάλυση μπορεί να υποδεικνύει ότι ένα νήμα έχει επιχειρήσει απελευθερώνει έναν πόρο που δεν κατέχειδείχνοντας πώς η διαδικασία Teams.exe και δείχνοντας προς win32kbase.sys σε μια συνάρτηση όπως Ρυθμίσεις εμφάνισης DrvEnumΑυτό μας δίνει μια ένδειξη ότι το νήμα που απέτυχε ήταν η υποβολή ερωτημάτων ή ο χειρισμός των ρυθμίσεων εμφάνισης από τον χώρο χρήστη μέσω του επιπέδου γραφικών των Windows.

Για να εμβαθύνουμε λίγο περισσότερο στις λεπτομέρειες του κώδικα διακοπής και των παραμέτρων του, έχουμε επίσης την εντολή .bugcheckη οποία εμφανίζει ξανά τον έλεγχο σφαλμάτων και τα τέσσερα ορίσματα, κάτι που είναι χρήσιμο αν θέλουμε να επαναλάβουμε αυτές τις πληροφορίες χωρίς να εκτελέσουμε ξανά τα πάντα. !analyze -v.

Πρακτικές περιπτώσεις: παράγοντες που οδηγούν σε αλλαγές και τυπικές συγκρούσεις

Η ανάλυση BSOD συνήθως περιστρέφεται γύρω από εντοπισμός ελαττωματικών ή κακής συμπεριφοράς οδηγώνΣυγκρούσεις μεταξύ ελεγκτών, μη εξουσιοδοτημένη πρόσβαση στη μνήμη, λανθασμένος χειρισμός IRP (I/O Request Packets) κ.λπ. Ας δούμε μερικά πρακτικά παραδείγματα από πραγματικές περιπτώσεις για να κατανοήσουμε καλύτερα τη διαδικασία.

RESOURCE_NOT_OWNED (0xE3) που σχετίζεται με το Teams και το win32kbase.sys

Σε ένα σενάριο των Windows 10 όπου μετά από αρκετές ημέρες λειτουργίας εμφανίζεται ένα BSOD με το bugcheck 0xE3 (ΔΕΝ ΑΝΗΚΕΙ Ο ΠΟΡΟΣ)Η ένδειξη minikernel δείχνει κάτι σαν αυτό:

RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: <dirección recurso>
Arg2: <dirección thread>
Arg3: 0
Arg4: 0

PROCESS_NAME: Teams.exe

STACK_TEXT:
...
win32kbase!DrvEnumDisplaySettings+0x356
win32kbase!NtUserEnumDisplaySettings+0x59
win32k!NtUserEnumDisplaySettings+0x15
nt!KiSystemServiceCopyEnd+0x28
...

Εδώ, το πρόγραμμα εντοπισμού σφαλμάτων υποδεικνύει ότι ο έλεγχος σφαλμάτων ενεργοποιείται από ένα νήμα που σχετίζεται με Teams.exeαλλά ο κώδικας που βρίσκεται στην πραγματικότητα στη στοίβα την κρίσιμη στιγμή ανήκει σε win32kbase.sys, συγκεκριμένα για τη συνάρτηση Ρυθμίσεις εμφάνισης DrvEnumΑυτό δεν σημαίνει απαραίτητα ότι το Teams είναι ο άμεσος «ένοχος», αλλά μάλλον ότι Ένα API χρήστη καλείται από το Teams το οποίο καταλήγει σε σφάλμα συγχρονισμού ή απελευθέρωση πόρων στο υποσύστημα γραφικών.

Σε αυτούς τους τύπους διαγνώσεων, το συμπέρασμα είναι συχνά ότι είναι ένα σφάλμα στη στοίβα γραφικών των Windows, σε ένα συγκεκριμένο πρόγραμμα οδήγησης οθόνης ή στην αλληλεπίδραση μεταξύ της εφαρμογής και των προγραμμάτων οδήγησης. Η πραγματική λύση μπορεί να περιλαμβάνει Ενημερώστε τα προγράμματα οδήγησης GPU, ενημερώστε το Teams ή ακόμα και εφαρμόστε συγκεκριμένες ενημερώσεις κώδικα των Windowsπέρα από το να «περιμένεις» να διορθωθεί από μόνο του.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) με NotMyFault

Χρησιμότητα Δεν είναι λάθος μου Το εργαλείο του Sysinternals είναι ένας εκπαιδευτικός πόρος που σας επιτρέπει να δημιουργείτε σφάλματα πυρήνα με ελεγχόμενο τρόπο για να μάθετε πώς να αναλύετε στιγμιότυπα οθόνης. Για παράδειγμα, αν εκκινήσουμε την επιλογή από το NotMyFault Σφάλμα υψηλού IRQL (λειτουργία πυρήνα) και πατάμε «Κάντε σφάλμα», θα επιβάλουμε ένα DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1).

Στην μπλε οθόνη θα δούμε κάτι σαν DRIVER_IRQL_NOT_LESS_OR_EQUAL και ενδεχομένως έναν υποψήφιο οδηγό (για παράδειγμα, MyFault.sys(το πρόγραμμα οδήγησης που χρησιμοποιείται από το εργαλείο). Μόλις δημιουργηθεί και ανοιχτεί το dump με το WinDbg, η αρχική έξοδος μπορεί να μοιάζει με:

Use !analyze -v to get detailed debugging information.
BugCheck D1, {e1071800, 1c, 0, f7cda403}
*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
Probably caused by : memory_corruption
Followup: memory_corruption

Παρόλο που το πρόγραμμα εντοπισμού σφαλμάτων υποδεικνύει μνήμη_διαφθοράΓνωρίζουμε ότι η πραγματική αιτία σχετίζεται με το NotMyFault και το πρόγραμμα οδήγησης του. Για να το επιβεβαιώσουμε αυτό, μπορούμε να συνεχίσουμε την ανίχνευση με εντολές όπως !νήμα για να δούμε ποιες κλήσεις κάνει το νήμα τη στιγμή της αποτυχίας, και !irp για να αναλύσουμε το IRP που εμπλέκεται εάν ο έλεγχος σφαλμάτων σχετίζεται με λειτουργίες εισόδου/εξόδου.

Για παράδειγμα, με !νήμα Θα μπορέσουμε να δούμε το stack trace του νήματος και να εντοπίσουμε την εντολή εκεί που εμφανίζεται. το σφάλμα μου+0x403Αυτό μας λέει πού έκανε λάθος ο οδηγός δοκιμής. Από εκεί, μπορούμε να εξετάσουμε την IRP, την κατάσταση μνήμης κ.λπ., όπως ακριβώς θα κάναμε με ένα πραγματικό σφάλμα.

MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) και διενέξεις USB

Μια άλλη πολύ ενδεικτική περίπτωση είναι ο έλεγχος σφαλμάτων ΠΟΛΛΑΠΛΑ_ΑΙΤΗΜΑΤΑ_ΟΛΟΚΛΗΡΩΜΕΝΩΝ_IRP (0x44)Αυτό το σφάλμα παρουσιάζεται όταν Ένα IRP (I/O Request Packet) ολοκληρώνεται περισσότερες από μία φορές, συνήθως επειδή δύο διαφορετικοί οδηγοί πιστεύουν ότι έχουν την ίδια IRP και καλούν και οι δύο IoCompleteRequest().

Η ανάλυση με !analyze -v Μπορεί να δημιουργήσει μια περιγραφή παρόμοια με αυτήν:

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.
...
Arguments:
Arg1: <IRP_ADDRESS>
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000

Probably caused by : usbehci.sys

Αρχικά, φαίνεται ότι ο ύποπτος είναι usbehci.sysένα πρόγραμμα οδήγησης της Microsoft για ελεγκτές USB EHCI. Ωστόσο, είναι σχετικά σπάνιο το σφάλμα να προκαλείται στην πραγματικότητα από ένα εγγενές πρόγραμμα οδήγησης των Windows χωρίς καμία παρέμβαση τρίτου μέρους. Για να φτάσουμε στο θέμα, χρησιμοποιούμε τη διεύθυνση IRP που μας δίνεται από το bugcheck (Arg1) και εκκινούμε !irp:

!irp 87e5a490
Irp is active with 3 stacks 3 is current (= 0x87e5a548)
...
> [ f, 0] 0 c0 8a055618 00000000 b69de300-00000000 Success Error
  \Driver\usbehci ax88172
Args: b70989c0 00000000 00220003 00000000

Στην τελευταία γραμμή βλέπουμε καθαρά την αλυσίδα \Οδηγός\usbehci ax88172, το οποίο αποκαλύπτει ότι το IRP έχει περάσει τόσα πολλά usbehci.sys όπως από έναν οδηγό που ονομάζεται ax88172.sys, που σχετίζεται με ένα συγκεκριμένο chipset δικτύου USB (AX88172). Επομένως, μπορούμε να συμπεράνουμε ότι η διένεξη προέρχεται από αυτό πρόγραμμα οδήγησης κάρτας δικτύου USB τρίτου κατασκευαστήόχι το γενικό πρόγραμμα οδήγησης Microsoft EHCI.

Η λύση, σε αυτή την περίπτωση, βρίσκεται στο ενημερώστε το πρόγραμμα οδήγησης του προσαρμογέα USB, αντικαταστήστε τη συσκευή ή, εάν δεν υπάρχει άλλη επιλογή, καταργήστε την.Αυτός ο τύπος ανάλυσης που χρησιμοποιεί IRP είναι ιδιαίτερα χρήσιμος σε BSOD που σχετίζονται με USB, αποθηκευτικό χώρο, κάρτες δικτύου και, γενικά, οποιοδήποτε στοιχείο που χρησιμοποιεί εντατικά I/O.

Χρήσιμες εντολές WinDbg σε λειτουργία πυρήνα

Από εδώ και πέρα !analyze -v y .bugcheckΥπάρχουν αρκετές επεκτάσεις και εντολές του WinDbg που είναι πολύ χρήσιμες όταν θέλουμε να εμβαθύνουμε λίγο περισσότερο στο kernel dumping.

Μερικά από τα πιο συνηθισμένα είναι:

• !νήμαΕμφανίζει λεπτομερείς πληροφορίες σχετικά με ένα νήμα, συμπεριλαμβανομένης της στοίβας κλήσεων, της κατάστασης, των συσχετισμένων IRP κ.λπ. Σας επιτρέπει να δείτε τις "τελευταίες ενέργειες" του νήματος που εκτελούνταν όταν το σύστημα παρουσίασε σφάλμα.
• !διαδικασία 0 0Αυτό παραθέτει όλες τις ενεργές διεργασίες κατά τη στιγμή της διακοπής λειτουργίας. Είναι χρήσιμο για τον εντοπισμό τυχόν ύποπτων διεργασιών, υπηρεσιών, EDR, antivirus κ.λπ. που εκτελούνται στον υπολογιστή.
• !irp: αναλύει ένα συγκεκριμένο IRP και δείχνει το ίχνος των οδηγών από τους οποίους έχει περάσειΗ εντολή I/O, οι σημαίες κ.λπ. είναι βασικά σε σφάλματα που σχετίζονται με ΠΟΛΛΑΠΛΑ_ΟΛΟΚΛΗΡΩΜΕΝΑ_ΑΙΤΗΜΑΤΑ_IRP και άλλα σφάλματα εισόδου/εξόδου.
• !cpuinfo: παρέχει πληροφορίες σχετικά με τον επεξεργαστή (κατασκευαστής, MHz, υπογραφές, χαρακτηριστικά), χρήσιμες για την επαλήθευση περιβαλλόντων υλικού.
• !peb: εμφανίζει λεπτομέρειες του PEB (Process Environment Block), όπως όνομα υπολογιστή, διαδρομή εγκατάστασης των Windows, αριθμό επεξεργαστών κ.λπ.
• !ένδειξη: παρέχει πληροφορίες σχετικά με τα διακριτικά ασφαλείας, τα δικαιώματα και το περιβάλλον ασφαλείας της διεργασίας ή του νήματος.
• .cls: καθαρίζει το παράθυρο εντολών, όπως σε μια κανονική κονσόλα.

Επιπλέον, πολλές συγκεκριμένες επεκτάσεις (για παράδειγμα, για συστήματα αρχείων, PnP, NTFS, κ.λπ.) επιτρέπουν την εξαγωγή ακόμη περισσότερων πληροφοριών από τα dumps. Σε ορισμένες περιπτώσεις, το WinDbg θα υποδείξει την παρουσία ΜΑΥΡΟ ΚΟΥΤΙ* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), τα οποία είναι πρόσθετα μπλοκ δεδομένων που καταγράφονται κατά τη στιγμή του ελέγχου σφαλμάτων για να διευκολυνθεί η διάγνωση συγκεκριμένων περιοχών του συστήματος.

Χρήση του Driver Verifier για την εύρεση προβληματικών προγραμμάτων οδήγησης

Ένα πολύ υψηλό ποσοστό σφαλμάτων Μπλε Οθόνης Θανάτου (BSOD) των Windows οφείλεται σε ελαττωματικά ή κακώς προγραμματισμένα προγράμματα οδήγησηςΓια την προληπτική ανίχνευση αυτών των τύπων προβλημάτων, το σύστημα ενσωματώνει ένα πολύ ισχυρό εργαλείο: Έλεγχος οδηγού.

El Επαληθευτής προγράμματος οδήγησης Εκτελείται σε πραγματικό χρόνο και υποβάλλει τους επιλεγμένους οδηγούς σε μια σειρά δοκιμών και stress tests: επαληθεύει το σωστή χρήση μνήμης, kernel pools, IRQL, IRP, κ.λπ.Εάν εντοπίσει ότι ένας οδηγός κάνει κάτι λάθος, μπορεί να επιβολή ελεγχόμενου BSOD ώστε να μπορέσουμε να αναλύσουμε μια πολύ πιο σαφή απόρριψη, όπου ο ένοχος συνήθως προσδιορίζεται με μεγάλη σαφήνεια.

Για να ξεκινήσετε τη διαχείριση του Driver Verifier, απλώς ανοίξτε μια γραμμή εντολών με δικαιώματα διαχειριστή και πληκτρολογήστε:

verifier

Από εκεί μπορούμε να επιλέξουμε ποιοι ελεγκτές θέλουμε να επαληθευτούν. Είναι συνετό να είμαστε προσεκτικοί: ο Επαληθευτής Προσθέτει επιπλέον επιβάρυνση στο σύστημα και μπορεί να υποβαθμίσει την απόδοσηΣυνεπώς, συνιστάται η ενεργοποίηση της επαλήθευσης μόνο για το ελάχιστος αριθμός ύποπτων οδηγών αντί να σημειώνει χαρούμενα τα πάντα.

Μόλις το Verifier ενεργοποιήσει ένα BSOD κατά την ανίχνευση λανθασμένης συμπεριφοράς, μπορούμε να αναλύσουμε το dump του πυρήνα με το WinDbg και, ελπίζουμε, να δούμε καθαρά. ποιος οδηγός συνελήφθη Και τι έκανε λάθος; Τα άρθρα αναφοράς της Microsoft σχετικά με το Driver Verifier εξηγούν λεπτομερώς τις διάφορες επιλογές και στρατηγικές χρήσης.

Πρακτικές συμβουλές για μηχανικούς και τεχνικούς

Είτε είστε προγραμματιστής προγραμμάτων οδήγησης, είτε προγραμματιστής λογισμικού που αλληλεπιδρά με τον πυρήνα, είτε απλώς ο τεχνικός που λαμβάνει όλα τα μπλε οθόνες θανάτου, υπάρχουν ορισμένες οδηγίες που αξίζει να εσωτερικεύσετε για να αποφύγετε να χαθείτε στη ζούγκλα των BSOD.

Το πρώτο πράγμα που πρέπει να λάβετε υπόψη είναι, όταν το σφάλμα σχετίζεται με τον δικό σας κώδικα, συστηματική χρήση του προγράμματος εντοπισμού σφαλμάτων πυρήνα για την αναπαραγωγή και ανάλυση του προβλήματοςΣυνδέοντας ένα πρόγραμμα εντοπισμού σφαλμάτων στον υπολογιστή-στόχο (μέσω δικτύου, σειριακής σύνδεσης κ.λπ.), ένας έλεγχος σφαλμάτων θα προκαλέσει τη διακοπή του συστήματος μέσα στο πρόγραμμα εντοπισμού σφαλμάτων αντί να εμφανίζει απευθείας την μπλε οθόνη. Από εκεί, είναι δυνατό να ελέγξετε τη μνήμη, τις στοίβες, τις δομές δεδομένων και να εντοπίσετε σφάλματα στον κώδικα.

Σε άλλα σενάρια, οι έλεγχοι σφαλμάτων μπορεί να οφείλονται σε προγράμματα οδήγησης, υλικό ή λογισμικό τρίτων κατασκευαστών που δεν ελέγχουμε. Σε αυτές τις περιπτώσεις, ο στόχος μετατοπίζεται από την «διόρθωση του κώδικα» στην απομόνωση και μετριασμός του προβλήματος:

• Προσδιορίστε το ύποπτο πρόγραμμα οδήγησης ή στοιχείο υλικού χρησιμοποιώντας WinDbg και ανάλυση dump.
• Ενημέρωση ή επαναφορά εκδόσεις προγραμμάτων οδήγησης, BIOS, υλικολογισμικό ή σχετικές εφαρμογές.
• Αφαίρεση ή αντικατάσταση Συσκευές USB, κάρτες γραφικών, προσαρμογείς δικτύου συγκρουσιακός.
• Να στηρίζεσαι στο Πρόγραμμα προβολής συμβάντων, Sysinternals, εργαλεία παρακολούθησης και ανάλυσης δικτύου για επιπλέον περιεχόμενο.

Πολλά φαινομενικά μυστηριώδη προβλήματα λύνονται με βασικές διαδικασίες αντιμετώπισης προβλημάτωνΗ αναθεώρηση της τεκμηρίωσης, ο έλεγχος των εκδόσεων και των ημερομηνιών των αρχείων, η επανεγκατάσταση βασικών στοιχείων ή η απενεργοποίηση των μονάδων που βρίσκονται σε διένεξη αποτελούν όλα μέρος της διαδικασίας. Η ανάλυση της απόδειξης μας δίνει μια σαφή κατεύθυνση για το πού να ψάξουμε και συχνά μας γλιτώνει ώρες δοκιμών και σφαλμάτων.

Θα πρέπει επίσης να θυμόμαστε ότι, σε περιβάλλοντα όπως αυτό που προκάλεσε το περιστατικό CrowdStrike Falcon και άλλα EDR, οι πιο συνηθισμένες ερωτήσεις περιστρέφονται γύρω από Τι προκάλεσε το BSOD και πώς να το αναγνωρίσετε γρήγοραΈχοντας ρυθμίσει σωστά το WinDbg, με σύμβολα και μια σαφή διαδικασία για το άνοιγμα και την ανάλυση dumps, μπορείτε να περιορίσετε σε λίγα λεπτά αυτό που διαφορετικά θα μπορούσε να καταλήξει σε "διαμόρφωση και επανεγκατάσταση" χωρίς να κατανοήσετε πραγματικά την αιτία.

Εν ολίγοις, ο συνδυασμός μιας καλής διαμόρφωσης μνήμης dump, της πειθαρχημένης χρήσης εργαλείων όπως το WinDbg, το Driver Verifier και το Sysinternals, και της συνήθειας της μεθοδικής αναθεώρησης αρχείων καταγραφής και στοίβων μετατρέπει τις μπλε οθόνες ενός απρόβλεπτου εχθρού σε... μια πολύ ακριβής πηγή πληροφοριών σχετικά με το τι έχει πάει στραβά στον πυρήνα, βοηθώντας μας να λαμβάνουμε πολύ πιο εμπεριστατωμένες τεχνικές αποφάσεις.