Panduan lengkap untuk menganalisis BSOD dan dump kernel di Windows

Informatec Digital » Sumber daya » Panduan lengkap untuk menganalisis BSOD dan dump kernel di Windows

Ketika komputer Windows mengalami pembekuan dengan layar biru, itu bukan hanya menjengkelkan: seringkali ada informasi berharga yang tersembunyi dalam dump memori yang memberi tahu kita persis apa yang terjadi di kernel. Alih-alih menyalahkan RAM, BIOS, atau langsung memformat ulang, ada baiknya mempelajari cara membaca data tersebut.

Dengan sedikit latihan, alat seperti WinDbg dan fungsi seperti !analyze -v, .bugcheck, atau penggunaan simbol yang tepat memungkinkan kita untuk beralih dari "Saya mendapatkan kesalahan layar biru" menjadi "Saya tahu driver, sumber daya, atau perangkat mana yang menyebabkan BSOD." Dalam artikel ini, kita akan menguraikan, langkah demi langkah dan secara detail, cara menganalisis BSOD menggunakan dump kernel-nya, jenis dump apa saja yang ada, cara mempersiapkan semuanya, dan perintah apa yang harus digunakan untuk mendapatkan hasil maksimal dari analisis tersebut.

Apa itu BSOD dan informasi apa yang terdapat di dalamnya?

Ketika Windows menemukan kondisi yang membahayakan integritas sistem dan tidak dapat pulih dengan aman, ia melakukan panggilan kernel internal yang disebut KeBugCheckEx . Panggilan inilah yang memicu munculnya Blue Screen of Death (BSOD) yang terkenal.

KeBugCheckEx selalu menerima lima argumen: kode STOP (kode bugcheck) dan empat parameter tambahan yang memberikan konteks teknis pada kesalahan tersebut. Data yang sama inilah yang kemudian dapat kita gunakan.

• Pada layar biru klasik, jika sistem tidak dikonfigurasi untuk memulai ulang secara otomatis.
• Di log peristiwa Windows, di dalam Event Viewer (log sistem).
• Dalam file dump memori (minidump, kernel dump atau full dump), menggunakan WinDbg dan perintah seperti !analyze -v o .bugcheck.

Setiap kode pemeriksaan bug memiliki nama simbolik dan nilai heksadesimal terkait . Misalnya, pemeriksaan bug DRIVER_POWER_STATE_FAILURE memiliki kode 0x9F , sedangkan RESOURCE_NOT_OWNED sesuai dengan 0xE3 . Kode-kode ini dan parameternya didokumentasikan dalam referensi kode pemeriksaan bug Microsoft, yang sebaiknya selalu Anda simpan.

Selain kode kesalahan, layar biru mungkin menampilkan nama driver .sys yang berpotensi terlibat . Jika itu adalah driver pihak ketiga (antivirus, kartu jaringan, kartu grafis, dll.), kita sering kali memiliki tersangka yang jelas. Jika komponen sistem generik (ntoskrnl.exe, win32k.sys, dll.) muncul, atau jika tidak ada yang muncul sama sekali, kita perlu melakukan dump memori dan menggunakan WinDbg untuk menyelidiki lebih lanjut.

Jenis-jenis dump memori di Windows

Untuk menganalisis BSOD secara mendalam, kita perlu Windows untuk menghasilkan file dump memori (DMP) saat kegagalan terjadi. File ini menangkap keadaan sistem pada saat kesalahan terjadi dan dapat berupa berbagai jenis.

Pada opsi "Startup dan Pemulihan" (klik kanan pada "PC Ini / Komputer Saya" → Properti → Pengaturan sistem lanjutan → tab "Lanjutan" → tombol "Pengaturan" di bawah "Startup dan Pemulihan"), Anda dapat memilih di antara beberapa jenis dump. Masing-masing memiliki kelebihan dan kekurangannya sendiri.

Dump Memori Kecil (Minidump)

Format minidump adalah yang terkecil (sekitar 64 KB) dan juga yang paling terbatas untuk debugging tingkat lanjut. Namun, format ini tetap berguna untuk mendapatkan diagnosis cepat dalam banyak skenario BSOD.

Minidump menyimpan, antara lain, data berikut:

• Pesan berhenti, kode bugcheck, dan parameternya.
• Konteks prosesor (PRCB) dari prosesor yang menyebabkan kegagalan tersebut.
• Informasi proses kernel (EPROSS) dari proses aktif pada saat terjadi crash.
• Informasi thread di kernel (ETHREAD) dari thread yang menyebabkan crash.
• Tumpukan panggilan mode kernel untuk thread tersebut (hingga 16 KB).
• Daftar driver yang dimuat pada saat putusan tersebut dikeluarkan.
• Daftar modul yang dimuat dan diunduh.
• Blok data debugging dengan informasi sistem dasar.

Jenis dump ini biasanya disimpan di %SystemRoot%\Minidump (misalnya, C:\Windows\Minidump ). Untuk banyak kasus dukungan atau diagnostik dasar, minidump yang dianalisis secara menyeluruh dengan !analyze -v mungkin sudah lebih dari cukup.

Pembuangan Memori Kernel

File dump memori kernel berisi isi memori kernel pada saat terjadi crash, tidak termasuk ruang memori proses pengguna. File ini menawarkan keseimbangan yang berharga antara ukuran dan detail, dan seringkali menjadi pilihan yang direkomendasikan untuk mendiagnosis sebagian besar BSOD (Blue Screen of Death).

File dump ini disimpan sebagai MEMORY.DMP di %SystemRoot% (secara default, C:\Windows\MEMORY.DMP ). Ukurannya bergantung pada memori yang digunakan oleh kernel, tetapi biasanya jauh lebih besar daripada minidump dan jauh lebih mudah dikelola daripada full dump.

Pembuangan Memori Lengkap

Pengambilan data memori lengkap ( full memory dump) menyimpan hampir semua isi RAM pada saat terjadi kesalahan: kernel, proses pengguna, dll. Ini adalah yang paling detail tetapi juga yang paling memakan ruang dan paling menuntut dalam hal konfigurasi.

Agar sebuah dump data lengkap dianggap valid, beberapa persyaratan harus dipenuhi:

• El file paging harus ada di dalam partisi yang sama tempat Windows diinstal.
• Pasti ada ruang disk minimal sama dengan ukuran memori fisik dari mesin.
• Jangan pindahkan pagefile ke disk fisik lain jika Anda ingin menghindari dump yang rusak.

Dalam lingkungan produksi dengan banyak RAM, dump penuh mungkin tidak praktis, tetapi untuk kasus yang sangat kompleks atau terjadi sesekali, hal itu dapat membuat perbedaan besar dalam menemukan masalahnya.

Konfigurasi Windows untuk menangkap dan mencatat BSOD (Blue Screen of Death).

Sebelum kita mulai menggunakan WinDbg, penting untuk memastikan bahwa sistem menghasilkan dump dan mencatat kejadian layar biru dengan benar.

Di jendela "Mulai dan Pemulihan" kita menemukan beberapa opsi yang relevan:

• Tuliskan suatu kejadian ke dalam log sistem.: harus diaktifkan agar bugcheck dapat tercatat di Event Viewer.
• Tulis informasi debuggingDi sini kita memilih Minidump, Kernel memory dump, atau Complete memory dump.
• jalur file dump: bawaan %SystemRoot%\MEMORY.DMP untuk kernel/penuh.
• Mulai ulang secara otomatisSebaiknya kita tidak mencentangnya jika kita mau. dengan tenang menonton layar biru dan perhatikan apa yang muncul.

Untuk beberapa produsen atau departemen dukungan, seperti dalam kasus adaptor jaringan tertentu, pengguna diminta untuk mengirimkan file dump . File tersebut biasanya terletak di C:\Windows\memory.dmp , dan disarankan untuk mencarinya berdasarkan tanggal/waktu untuk mengidentifikasi file yang sesuai dengan kegagalan terakhir.

Jika yang kita inginkan adalah dapat memaksa dump bahkan ketika sistem membeku (tanpa respons keyboard atau mouse), ada juga trik yang sangat berguna untuk keyboard PS/2 (bukan USB/Bluetooth), yang terdiri dari mengkonfigurasi registri untuk memicu dump dengan kombinasi tombol.

Lakukan dump paksa menggunakan keyboard jika terjadi pembekuan.

Untuk menghasilkan dump memori meskipun layar benar-benar membeku, Anda dapat menggunakan opsi CrashOnCtrlScroll pada keyboard PS/2. Metode ini tidak berlaku untuk keyboard USB atau Bluetooth.

Di dalam registri, kita harus membuat atau memodifikasi kunci berikut:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Setelah memulai ulang, kapan saja (bahkan saat layar membeku) Anda dapat memicu crash terkontrol dan membuat sistem menghasilkan dump memori dengan menekan tombol CTRL kanan lalu tombol Scroll Lock dua kali . Ini sangat berguna untuk menyelidiki crash parah yang tidak menampilkan BSOD (Blue Screen of Death) dengan sendirinya.

Pengantar WinDbg untuk menganalisis dump kernel

WinDbg adalah alat andalan Microsoft untuk debugging kernel dan analisis dump memori . Tersedia secara gratis (saat ini juga di Microsoft Store sebagai WinDbg Preview) dan, meskipun mungkin tampak rumit pada pandangan pertama, untuk analisis BSOD awal Anda hanya perlu memahami beberapa opsi dasar.

Kita dapat menginstal WinDbg pada mesin yang bermasalah itu sendiri atau pada komputer lain ; file .dmp dapat disalin melalui jaringan, melalui USB, atau bahkan dikompresi ke dalam file CAB. Prosesor dan versi Windows tempat kita menganalisis dump tidak harus sama dengan mesin yang mengalami crash.

Jalankan WinDbg dengan dump dari baris perintah.

Cara klasik untuk membuka dump memori di WinDbg adalah dengan menggunakan baris perintah dengan parameter `-z` , yang menentukan jalur ke file dump. Ini dapat dikombinasikan dengan parameter lain seperti jalur simbol atau biner.

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

Pengubah -v mengaktifkan mode verbose , yang sangat berguna untuk melihat lebih banyak konteks. Selain WinDbg, ada juga kd.exe , debugger berbasis konsol yang memungkinkan Anda melakukan hal yang hampir sama tetapi tanpa antarmuka grafis.

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

Buka file dump dari antarmuka grafis.

Jika WinDbg sudah terbuka dalam mode pasif, Anda dapat memuat file dump crash menggunakan menu File → Open Crash Dump atau pintasan Ctrl+D . Pilih file .dmp (atau bahkan file .cab yang berisi file tersebut) dan WinDbg akan memuat informasi crash.

Alternatif lainnya adalah dengan meluncurkan WinDbg, dan setelah masuk, jalankan perintah .opendump dengan menentukan jalur ke file dump dan kemudian perintah g (Go) untuk memulai sesi debugging dump:

.opendump C:\Windows\Memory.dmp
g

WinDbg bahkan mengizinkan membersihkan beberapa tempat pembuangan sampah sekaligusmenambahkan beberapa parameter -z pada baris perintah atau dengan mengulanginya .opendump dengan rute yang berbeda dan mengelola sesi multi-tujuan.

Konfigurasikan jalur simbol di WinDbg

Tanpa simbol, WinDbg beroperasi hampir secara buta. Simbol (.pdb) berisi informasi debugging tentang fungsi, struktur internal, variabel, offset, dll. , dan sangat penting untuk analisis yang andal, terutama saat bekerja dengan kernel.

Untuk menggunakan simbol publik Microsoft tanpa harus mengunduhnya secara manual, praktik terbaik adalah mengkonfigurasi server simbol yang mengarah ke server resmi Microsoft dan direktori cache lokal. Misalnya, kita dapat terlebih dahulu membuat folder C:\symbols dan kemudian, di WinDbg, mengkonfigurasi jalur simbol sebagai berikut:

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

Hal ini dapat dilakukan dari menu File → Symbol File Path atau, di WinDbg Preview, dari File → Settings → Debugging settings dengan menyesuaikan “Default symbol path”. Saat pertama kali Anda menganalisis dump dari sistem tertentu, debugger akan secara otomatis mengunduh simbol yang diperlukan dari internet, yang mungkin membutuhkan beberapa menit tergantung pada koneksi Anda.

Penting untuk dicatat bahwa simbol publik Microsoft terkadang tidak menyertakan semua informasi tipe internal , dan Anda mungkin melihat peringatan seperti "Debugger Anda tidak menggunakan simbol yang benar" atau referensi ke tipe yang tidak dapat diselesaikan. Untuk analisis BSOD dasar, simbol publik biasanya sudah cukup, tetapi jika Anda membutuhkan detail lebih lanjut, akan ada keterbatasan.

Analisis pertama: perintah dasar dan pengecekan bug

Setelah dump dimuat dan simbol dikonfigurasi, WinDbg biasanya menampilkan header dengan informasi sistem dan peringatan seperti "Gunakan !analyze -v untuk mendapatkan informasi debugging terperinci." Itulah langkah pertama kita untuk analisis awal.

Perintah !analyze -v melakukan analisis otomatis terhadap dump dan biasanya memberikan hasil sebagai berikut:

• Kode pemeriksaan kesalahan (misalnya, 0xE3, 0xD1, 0x9F, 0x44…).
• Parameter Arg1, Arg2, Arg3 dan Arg4 dari pemeriksaan bug.
• Modul atau driver yang paling mungkin penyebab kegagalan (Probably caused by).
• Proses terkait pada saat itu (misalnya, Teams.exe).
• Tumpukan panggilan (stack trace) dari thread yang memicu crash tersebut.
• Informasi ember dan hash kegagalan, yang berguna untuk mengkorelasikan kesalahan yang berulang.

Sebagai contoh, dalam kasus bugcheck dunia nyata RESOURCE_NOT_OWNED (0xE3) , analisis mungkin menunjukkan bahwa sebuah thread mencoba melepaskan sumber daya yang bukan miliknya , menampilkan Teams.exe sebagai proses dan menunjuk ke win32kbase.sys dalam fungsi seperti DrvEnumDisplaySettings . Ini menunjukkan bahwa thread yang gagal tersebut sedang menanyakan atau memanipulasi pengaturan tampilan dari ruang pengguna melalui lapisan grafis Windows.

Untuk mempelajari lebih dalam detail mengenai kode berhenti dan parameternya, kita juga memiliki perintah berikut: .bugcheckyang sekali lagi menampilkan bugcheck dan keempat argumennya, yang berguna jika kita ingin mengulang informasi tersebut tanpa menjalankan semuanya dari awal. !analyze -v.

Studi kasus praktis: faktor pendorong dan konflik tipikal.

Analisis BSOD biasanya berkisar pada identifikasi driver yang rusak atau tidak berfungsi , konflik driver, akses memori yang tidak tepat, penanganan IRP (Paket Permintaan I/O) yang salah, dan sebagainya. Mari kita lihat beberapa contoh praktis dari kasus dunia nyata untuk lebih memahami prosesnya.

RESOURCE_NOT_OWNED (0xE3) terkait dengan Teams dan win32kbase.sys

Dalam skenario Windows 10 di mana, setelah beberapa hari berjalan tanpa gangguan, muncul BSOD dengan bugcheck 0xE3 (RESOURCE_NOT_OWNED) , dump minikernel menunjukkan sesuatu yang mirip dengan:

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
...

Di sini, debugger menunjukkan bahwa pemeriksaan bug dipicu oleh thread yang terkait dengan Teams.exe , tetapi kode yang sebenarnya ada di tumpukan pada saat kritis adalah milik win32kbase.sys , khususnya fungsi DrvEnumDisplaySettings . Ini tidak serta merta berarti bahwa Teams adalah penyebab langsungnya, tetapi lebih tepatnya Teams memanggil API pengguna yang mengakibatkan bug sinkronisasi atau pelepasan sumber daya di subsistem grafis.

Dalam jenis diagnosis ini, kesimpulannya seringkali adalah adanya bug pada tumpukan grafis Windows, driver video tertentu , atau interaksi antara aplikasi dan driver. Solusi sebenarnya mungkin melibatkan pembaruan driver GPU, pembaruan Teams, atau bahkan penerapan patch Windows tertentu , daripada hanya menunggu masalah tersebut teratasi dengan sendirinya.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) dengan NotMyFault

Utilitas NotMyFault dari Sysinternals adalah alat edukasi yang memungkinkan Anda menghasilkan kesalahan kernel secara terkontrol untuk mempelajari cara menganalisis tangkapan layar. Misalnya, jika Anda meluncurkan opsi High IRQL fault (mode kernel) dari NotMyFault dan mengklik "Do Bug", Anda akan memunculkan kesalahan DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1).

Pada layar biru, kita akan melihat sesuatu seperti DRIVER_IRQL_NOT_LESS_OR_EQUAL dan mungkin driver kandidat (misalnya, MyFault.sys , driver yang digunakan oleh alat tersebut). Setelah dump dihasilkan dan dibuka dengan WinDbg, output awalnya mungkin terlihat seperti ini:

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

Meskipun debugger menunjukkan kerusakan memori , kita tahu penyebab sebenarnya terkait dengan NotMyFault dan driver-nya. Untuk mengkonfirmasi hal ini, kita dapat melanjutkan penelusuran dengan perintah seperti !thread untuk melihat panggilan apa yang dilakukan thread pada saat kegagalan, dan !irp untuk menganalisis IRP yang terlibat jika pemeriksaan bug terkait dengan operasi I/O.

Sebagai contoh, dengan `!thread <dir_thread>` kita dapat melihat jejak tumpukan (stack trace) thread dan menemukan instruksi tempat `myfault+0x403` muncul , yang menunjukkan di mana driver pengujian mengalami kesalahan. Dari situ, kita dapat memeriksa IRP, status memori, dan sebagainya, sama seperti yang kita lakukan pada bug sungguhan.

MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) dan konflik USB

Contoh lain yang sangat menggambarkan hal ini adalah bugcheck. PERMINTAAN_IRP_SELESAI BERGANDA (0x44)Kesalahan ini terjadi ketika Sebuah IRP (I/O Request Packet) diselesaikan lebih dari sekali., biasanya karena dua pengemudi yang berbeda percaya bahwa mereka memiliki IRP yang sama dan keduanya menyebutnya IoCompleteRequest().

Analisis dengan !analyze -v mungkin menghasilkan deskripsi yang mirip dengan ini:

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

Awalnya, tersangka tampaknya adalah usbehci.sys , driver Microsoft untuk pengontrol USB EHCI. Namun, relatif jarang terjadi bug yang sebenarnya disebabkan oleh driver Windows asli tanpa interaksi pihak ketiga. Untuk langsung ke intinya, kita menggunakan alamat IRP yang diberikan oleh bugcheck (Arg1) dan menjalankan !irp <IRP_ADDRESS> :

!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

Pada baris terakhir, kita jelas melihat string \Driver\usbehci ax88172 , yang menunjukkan bahwa IRP telah melewati usbehci.sys dan driver bernama ax88172.sys , yang terkait dengan chipset jaringan USB tertentu (AX88172). Oleh karena itu, kita dapat menyimpulkan bahwa konflik tersebut berasal dari driver NIC USB pihak ketiga ini , bukan dari driver EHCI generik Microsoft.

Dalam kasus tersebut, solusinya melibatkan pembaruan driver adaptor USB, penggantian perangkat, atau, jika perlu, penghapusan perangkat . Analisis IRP jenis ini sangat berguna untuk BSOD yang terkait dengan USB, penyimpanan, kartu jaringan, dan, secara umum, komponen apa pun yang menggunakan I/O intensif.

Perintah WinDbg yang berguna dalam mode kernel

Selain !analyze -v dan .bugcheck , terdapat beberapa ekstensi dan perintah WinDbg yang sangat berguna ketika kita ingin mempelajari lebih dalam tentang kernel dumping.

Beberapa yang paling umum adalah:

• !benangMenampilkan informasi detail tentang sebuah thread, termasuk tumpukan panggilannya, statusnya, IRP terkait, dll. Ini memungkinkan Anda untuk melihat "tindakan terakhir" dari thread yang sedang berjalan ketika sistem mengalami crash.
• !proses 0 0Ini mencantumkan semua proses aktif pada saat terjadi kerusakan. Ini berguna untuk mengidentifikasi apakah ada proses, layanan, EDR, antivirus, dll., yang mencurigakan yang berjalan di mesin tersebut.
• !irp: menganalisis IRP tertentu dan menunjukkan jejak para pengemudi yang telah dilaluinyaPerintah I/O, flag, dan lain-lain, merupakan kunci dalam bug yang terkait dengan MULTIPLE_IRP_COMPLETE_REQUESTS dan kesalahan I/O lainnya.
• !cpuinfo: memberikan informasi tentang prosesor (pabrikan, MHz, tanda tangan, karakteristik), berguna untuk memverifikasi lingkungan perangkat keras.
• !pebMenampilkan detail PEB (Process Environment Block), seperti nama komputer, jalur instalasi Windows, jumlah prosesor, dll.
• !token: memberikan informasi tentang token keamanan, izin, dan konteks keamanan dari proses atau thread.
• .cls: membersihkan jendela perintah, seperti pada konsol biasa.

Selain itu, banyak ekstensi sistem file khusus (misalnya, untuk PnP, NTFS, dll.) memungkinkan Anda untuk mengekstrak lebih banyak informasi dari dump. Dalam beberapa kasus, WinDbg akan menunjukkan keberadaan BLACKBOX* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), yang merupakan blok data tambahan yang diambil selama pemeriksaan bug untuk mempermudah diagnosis area sistem tertentu.

Menggunakan Driver Verifier untuk menemukan driver yang bermasalah.

Sebagian besar kesalahan Blue Screen of Death (BSOD) pada Windows disebabkan oleh driver yang rusak atau diprogram dengan buruk . Untuk mendeteksi masalah jenis ini secara proaktif, sistem menyertakan alat yang ampuh: Driver Verifier.

Driver Verifier berjalan secara real-time dan menguji driver terpilih dengan serangkaian tes dan uji beban: ia memeriksa penggunaan memori yang benar, penggunaan kernel pool, IRQL, IRP, dll. Jika mendeteksi bahwa driver berperilaku tidak wajar, ia dapat memicu BSOD terkontrol sehingga kita dapat menganalisis dump yang jauh lebih jelas, di mana penyebabnya biasanya mudah diidentifikasi.

Untuk menjalankan pengelola Driver Verifier, cukup buka command prompt dengan hak akses administrator dan ketik:

verifier

Dari situ, kita dapat memilih driver mana yang ingin kita verifikasi. Sebaiknya berhati-hati: Verifier menambah beban pada sistem dan dapat menurunkan kinerja , jadi disarankan untuk mengaktifkan verifikasi hanya untuk sesedikit mungkin driver yang mencurigakan, alih-alih memilih semuanya secara sembarangan.

Setelah Verifier memicu BSOD (Blue Screen of Death) saat mendeteksi perilaku yang salah, kita dapat menganalisis dump kernel dengan WinDbg dan, mudah-mudahan, melihat dengan jelas driver mana yang terdeteksi dan apa yang salah. Artikel referensi Microsoft tentang Driver Verifier menjelaskan berbagai opsi dan strategi penggunaan secara detail.

Saran praktis untuk para insinyur dan teknisi

Baik Anda seorang pengembang driver, pengembang perangkat lunak yang berinteraksi dengan kernel, atau sekadar teknisi andalan yang menerima semua pesan kesalahan layar biru (BSOD), ada beberapa panduan yang perlu dipahami untuk menghindari tersesat dalam labirin BSOD.

Langkah pertama, jika kesalahan terkait dengan kode Anda sendiri, adalah menggunakan debugger kernel secara sistematis untuk mereproduksi dan menganalisis masalah . Dengan menghubungkan debugger ke mesin target (melalui jaringan, serial, dll.), bugcheck akan menyebabkan sistem berhenti di dalam debugger alih-alih menampilkan layar biru secara langsung. Dari sana, Anda dapat memeriksa memori, tumpukan, struktur, dan memperbaiki kode.

Dalam skenario lain, pemeriksaan bug mungkin disebabkan oleh driver, perangkat keras, atau perangkat lunak pihak ketiga yang tidak kita kendalikan. Dalam kasus tersebut, tujuannya bergeser dari "memperbaiki kode" menjadi mengisolasi dan mengurangi masalah.

• Identifikasi driver atau komponen perangkat keras yang mencurigakan menggunakan WinDbg dan analisis dump.
• Perbarui atau kembalikan ke versi sebelumnya versi driver, BIOS, firmware, atau aplikasi terkait.
• Hapus atau ganti Perangkat USB, kartu grafis, adaptor jaringan Bertentangan.
• Untuk bersandar pada Event Viewer, Sysinternals, alat pemantauan dan analisis jaringan. untuk konteks tambahan.

Banyak masalah yang tampaknya misterius dapat diselesaikan dengan prosedur pemecahan masalah dasar : meninjau dokumentasi, memeriksa versi dan tanggal file, menginstal ulang komponen utama, atau menonaktifkan modul yang bertentangan. Menganalisis dump memberi kita arahan yang jelas tentang ke mana harus mencari dan seringkali menghemat waktu berjam-jam dari proses coba-coba.

Penting juga untuk diingat bahwa, dalam lingkungan seperti yang menyebabkan insiden CrowdStrike Falcon dan EDR lainnya, pertanyaan yang paling umum berkisar pada apa yang memicu BSOD dan bagaimana cara mengidentifikasinya dengan cepat . Dengan WinDbg yang dikonfigurasi dengan benar, dengan simbol dan prosedur yang jelas untuk membuka dan menganalisis dump, Anda dapat mempersempit dalam hitungan menit apa yang mungkin berakhir dengan "format dan instal ulang" tanpa benar-benar memahami penyebabnya.

Singkatnya, menggabungkan konfigurasi dump memori yang baik, penggunaan alat-alat seperti WinDbg, Driver Verifier, dan Sysinternals secara disiplin, serta kebiasaan meninjau log dan stack secara metodis, mengubah layar biru dari musuh yang tak terduga menjadi sumber informasi yang sangat akurat tentang apa yang gagal di kernel , membantu kita membuat keputusan teknis yang jauh lebih tepat.