Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Catatan Instruksi untuk mengaktifkan fitur ini hanya berlaku untuk WDK untuk Windows 8. Untuk Windows 8.1, fitur ini telah diintegrasikan ke dalam Driver Verifier. Pada komputer yang menjalankan Windows 8.1, gunakan opsi simulasi sumber daya rendah sistematis.
Opsi Injeksi Kegagalan Berbasis Stack menyuntikkan kegagalan sumber daya ke dalam driver dalam mode kernel. Opsi ini menggunakan driver khusus, KmAutoFail.sys, bersama dengan Driver Verifier untuk menembus jalur penanganan kesalahan driver. Menguji jalur-jalur ini secara historis sangat sulit. Opsi Injeksi Kegagalan Berbasis Tumpukan menyuntikkan kegagalan sumber daya dengan cara yang dapat diprediksi, sehingga masalah yang ditemukan bisa direproduksi. Karena jalur kesalahan mudah direproduksi, juga memudahkan untuk memverifikasi perbaikan untuk masalah ini.
Untuk membantu Anda menentukan akar penyebab kesalahan, ekstensi debugger disediakan yang dapat memberi tahu Anda dengan tepat kegagalan mana yang telah disuntikkan dan dalam urutan apa.
Ketika opsi Injeksi Kegagalan Berbasis Tumpukan diaktifkan pada driver tertentu, opsi ini mencegat beberapa panggilan dari driver tersebut ke kernel dan Ndis.sys. Injeksi Kegagalan Berbasis Stack melihat stack panggilan—khususnya, pada bagian stack panggilan yang berasal dari driver yang diaktifkan. Jika ini adalah pertama kalinya melihat tumpukan itu, panggilan tersebut akan gagal berdasarkan semantik panggilannya. Jika tidak, jika telah mengidentifikasi panggilan itu sebelumnya, maka panggilan tersebut akan diteruskan tanpa perubahan. Injeksi Kegagalan Berbasis Tumpukan berisi logika untuk menangani fakta bahwa driver dapat dimuat dan dibongkar beberapa kali. Ini akan mengenali bahwa tumpukan panggilan sama bahkan jika driver dimuat ulang ke lokasi memori yang berbeda.
Mengaktifkan opsi ini
Anda dapat mengaktifkan fitur Injeksi Kegagalan Berbasis Stack untuk satu atau beberapa driver saat Anda Memasang Driver ke Komputer Pengujian. Anda dapat memilih opsi Injeksi Kegagalan Berbasis Tumpukan ketika mengonfigurasi Properti Pemverifikasi Driver untuk Paket Proyek Driver. Anda harus memulai ulang komputer untuk mengaktifkan atau menonaktifkan opsi Injeksi Kegagalan Berbasis Tumpukan. Anda juga dapat menjalankan utilitas pengujian untuk mengaktifkan Pemverifikasi Driver dan fitur ini di komputer pengujian.
Penting Saat Anda mengaktifkan Injeksi Kegagalan Berbasis Tumpukan pada komputer pengujian, pastikan jangan juga memilih Simulasi Sumber Daya Rendah.
Menggunakan Halaman Properti Pemverifikasi Driver
- Buka halaman properti untuk paket driver Anda. Klik kanan proyek paket driver di Penjelajah Solusi dan pilih properti .
- Di halaman properti untuk paket driver, klik Properti Konfigurasi, klik Penginstalan Driver, lalu klik Driver Verifier.
- Pilih Aktifkan Pemverifikasi Driver. Ketika Anda memfungsikan Pemverifikasi Driver pada komputer uji, Anda dapat memilih untuk memfungsikan Pemverifikasi Driver untuk semua driver pada komputer, hanya untuk proyek driver, atau untuk daftar driver yang ditentukan.
- Di bawah Injektor Kegagalan Berbasis Tumpukan, pilih (centang) Injeksi Kegagalan Berbasis Tumpukan.
- Klik Terapkan atau OK.
- Lihat Menerapkan Driver ke Komputer Uji untuk informasi selengkapnya. Komputer uji harus dimulai ulang untuk mengaktifkan opsi ini.
Menggunakan uji Mengaktifkan dan Menonaktifkan Pemverifikasi Driver
Anda juga dapat mengaktifkan Driver Verifier dengan menjalankan pengujian utilitas. Ikuti instruksi yang dijelaskan dalam Cara menguji driver saat runtime menggunakan Visual Studio. Di bawah kategori pengujian All Tests\Driver Verifier, pilih pengujian Enable Driver Verifier (mungkin diperlukan reboot) dan Disable Driver Verifier (mungkin diperlukan reboot).
Pilih opsi Pemverifikasi Driver dengan mengklik pada nama Aktifkan Pemverifikasi Driver (mungkin diperlukan reboot) pengujian di jendela Grup Pengujian Driver.
Pilih (centang) Injeksi Kegagalan Berbasis Tumpukan.
Setelah menambahkan pengujian ini ke grup pengujian, Anda dapat menyimpan grup pengujian. Untuk mengaktifkan Injeksi Kegagalan Berbasis Tumpukan, jalankan pengujian Aktifkan Pemverifikasi Driver (mungkin diperlukan restart) pada komputer yang telah Anda konfigurasi untuk pengujian.
Untuk menonaktifkan Driver Verifier, lakukan pengujian Nonaktifkan Driver Verifier (mungkin diperlukan reboot).
Menggunakan opsi Injeksi Kegagalan Berbasis Tumpukan
Salah satu pertimbangan penting saat menguji dengan Injeksi Kegagalan Berbasis Tumpukan adalah bahwa sebagian besar bug yang ditemukannya akan menghasilkan cek kesalahan. Ini bisa menjadi agak menyakitkan jika driver Anda adalah driver yang dimuat saat boot. Karena itu, kami akan secara otomatis menonaktifkan Injeksi Kegagalan Berbasis Tumpukan jika Pemverifikasi Driver dinonaktifkan. Ini berarti Anda dapat menonaktifkan Stack Based Failure Injection pada saat booting melalui debugger dengan menonaktifkan Driver Verifier menggunakan perintah !verifier –disable.
Jika memungkinkan, untuk pengujian awal Anda dengan Injeksi Kegagalan Berbasis Tumpukan, siapkan driver Anda sehingga tidak dimuat saat booting. Anda kemudian dapat menjalankan beberapa pengujian beban dan pembongkaran sederhana. Banyak bug yang ditemukan oleh Injeksi Kegagalan Berbasis Stack terjadi selama inisialisasi atau pembongkaran. Berulang kali memuat dan membongkar driver Anda adalah cara yang baik untuk menemukannya.
Setelah melakukan perbaikan apa pun yang diperlukan untuk mendapatkan pengujian pembongkaran beban agar berhasil, Anda dapat beralih ke pengujian berbasis IOCTL, pengujian fungsional penuh, dan akhirnya pengujian stres. Secara umum, jika Anda mengikuti perkembangan pengujian ini, Anda tidak akan mengungkap banyak masalah baru selama pengujian stres karena sebagian besar jalur kode telah dijalankan sebelum ini.
Menggunakan ekstensi debugger Stack Based Failure Injection (SBFI)
Sebagian besar masalah yang ditemukan dengan Injeksi Kegagalan Berbasis Tumpukan mengakibatkan pengecekan kesalahan. Untuk membantu menentukan penyebab bug kode ini, WDK menyediakan ekstensi debugger untuk Injeksi Kegagalan Berbasis Tumpukan serta simbol yang diperlukan. Prosedur penginstalan akan menginstal keduanya pada sistem debugger Anda. Lokasi defaultnya adalah C:\Program Files (x86)\Windows Kits\8.0\Debuggers\<arch>.
Untuk menjalankan ekstensi debugger
Dari prompt perintah debugger, ketik perintah berikut: !<jalur>\kmautofaildbg.dll.autofail. Misalnya, dengan asumsi ekstensi debugger diinstal di c:\dbgext dan kmautofail.pdb berada di jalur simbol, Anda akan memasukkan perintah berikut:
!c:\dbgext\kmautofaildbg.dll.autofail
Ini akan menampilkan informasi ke debugger Anda yang menunjukkan tumpukan panggilan dari kegagalan terbaru yang telah dimasukkan. Setiap entri terlihat seperti berikut ini, diambil dari uji coba nyata. Dalam contoh berikut, Injeksi Kegagalan Berbasis Stack diaktifkan pada Mydriver.sys
Sequence: 2, Test Number: 0, Process ID: 0, Thread ID: 0
IRQ Level: 2, HASH: 0xea98a56083aae93c
0xfffff8800129ed83 kmautofail!ShimHookExAllocatePoolWithTag+0x37
0xfffff88003c77566 mydriver!AddDestination+0x66
0xfffff88003c5eeb2 mydriver!ProcessPacketDestination+0x82
0xfffff88003c7db82 mydriver!ProcessPacketSource+0x8b2
0xfffff88003c5d0d8 mydriver!ForwardPackets+0xb8
0xfffff88003c81102 mydriver!RoutePackets+0x142
0xfffff88003c83826 mydriver!RouteNetBufferLists+0x306
0xfffff88003c59a76 mydriver!DeviceSendPackets+0x156
0xfffff88003c59754 mydriver!ProcessingComplete+0x4a4
0xfffff88001b69b81 systemdriver2!ProcessEvent+0x1a1
0xfffff88001b3edc4 systemdriver1!CallChildDriver+0x20
0xfffff88001b3fc0a systemdriver1!ProcessEvent+0x3e
0xfffff800c3ea6eb9 nt!KiRetireDpcList+0x209
0xfffff800c3ea869a nt!KiIdleLoop+0x5a
Di bagian atas output, nomor urut menghitung jumlah kesalahan yang disuntikkan. Contoh ini menunjukkan kesalahan kedua yang dimasukkan selama tes ini. ID proses adalah 0, jadi ini adalah proses sistem. IRQL adalah 2, jadi ini disebut pada tingkat pengiriman.
Dari tumpukan, KmAutoFail adalah driver Injeksi Kegagalan Berbasis Tumpukan. Nama fungsi KmAutoFail menunjukkan panggilan fungsi mana dari Mydriver.sys yang disadap dan diberi kesalahan. Di sini, fungsi yang gagal adalah ExAllocatePoolWithTag. Semua fungsi di KmAutoFail yang mencegat panggilan ke Ntoskrnl.sys atau Ndis.sys menggunakan konvensi penamaan ini. Selanjutnya, kita melihat tumpukan panggilan dengan driver yang sedang diuji coba (Mydriver.sys). Ini adalah bagian dari tumpukan panggilan yang digunakan untuk menentukan keunikan tumpukan. Dengan demikian setiap entri yang dibuang oleh ekstensi debugger akan unik dalam bagian tumpukan panggilan ini. Sisa tumpukan panggilan menunjukkan siapa yang memanggil driver. Kepentingan utama dari ini adalah apakah driver dipanggil dari mode pengguna (dengan cara IOCTL) atau dari driver mode kernel.
Perhatikan bahwa jika driver mengembalikan status gagal dari rutinitas DriverEntry, percobaan memuat ulang biasanya akan terjadi di lokasi memori yang berbeda. Dalam hal ini, tumpukan panggilan dari lokasi sebelumnya mungkin akan berisi "sampah" daripada informasi tumpukan dari driver. Tetapi ini bukan masalah; ini menunjukkan bahwa driver menangani kesalahan yang disuntikkan dengan tepat.
Entri berikutnya ini menunjukkan panggilan ke driver melalui IOCTL dari mode pengguna. Perhatikan ID proses dan tingkat IRQ. Karena Mydriver.sys adalah driver filter NDIS, IOCTL datang melalui Ndis.sys. Perhatikan bahwa nt! NtDeviceIoControlFile ada di tumpukan. Setiap pengujian yang Anda jalankan pada driver yang menggunakan IOCTL akan melalui fungsi ini.
Sequence: 5, Test Number: 0, Process ID: 2052, Thread ID: 4588
IRQ Level: 0, HASH: 0xecd4650e9c25ee4
0xfffff8800129ed83 kmautofail!ShimHookExAllocatePoolWithTag+0x37
0xfffff88003c6fb39 mydriver!SendMultipleOids+0x41
0xfffff88003c7157b mydriver!PvtDisconnect+0x437
0xfffff88003c71069 mydriver!NicDisconnect+0xd9
0xfffff88003ca3538 mydriver!NicControl+0x10c
0xfffff88003c99625 mydriver!DeviceControl+0x4c5
0xfffff88001559d93 NDIS!ndisDummyIrpHandler+0x73
0xfffff88001559339 NDIS!ndisDeviceControlIrpHandler+0xc9
0xfffff800c445cc96 nt!IovCallDriver+0x3e6
0xfffff800c42735ae nt!IopXxxControlFile+0x7cc
0xfffff800c4274836 nt!NtDeviceIoControlFile+0x56
0xfffff800c3e74753 nt!KiSystemServiceCopyEnd+0x13
Menganalisis hasil Injeksi Kegagalan Berbasis Tumpukan
Anda menjalankan uji coba pada driver Anda, dan tiba-tiba Anda menghadapi masalah. Kemungkinan besar ini adalah pemeriksaan bug, tetapi juga bisa karena komputer menjadi tidak responsif. Bagaimana anda menemukan penyebabnya? Dengan asumsi itu adalah pemeriksaan bug, pertama-tama gunakan ekstensi di atas untuk menemukan daftar kegagalan yang disuntikkan, lalu gunakan perintah debugger: !analyze –v.
Pemeriksaan bug yang paling umum disebabkan oleh kegagalan memeriksa keberhasilan alokasi. Dalam kasus ini, stack dari analisis pemeriksaan bug mungkin hampir identik dengan kegagalan terakhir yang diinjeksikan. Pada titik tertentu setelah alokasi gagal (sering kali baris berikutnya), driver akan mengakses pointer null. Jenis bug ini sangat mudah diperbaiki. Terkadang alokasi yang gagal adalah satu atau dua di atas dalam daftar, tetapi tipe ini masih sangat mudah ditemukan dan diperbaiki.
Pemeriksaan bug paling umum kedua terjadi selama pembersihan. Dalam hal ini, driver mungkin mendeteksi kegagalan alokasi dan melanjutkan ke proses pembersihan, tetapi selama pembersihan, driver tidak memeriksa penunjuk dan sekali lagi mengakses penunjuk null. Kasus lain yang serupa adalah ketika pembersihan dapat dilakukan dua kali. Jika pembersihan tidak mengatur penunjuk ke struktur menjadi null setelah membebaskannya, ketika fungsi pembersihan dipanggil untuk kedua kalinya, fungsi tersebut akan mencoba membebaskan struktur sekali lagi, yang mengakibatkan kesalahan sistem.
Kesalahan yang menyebabkan komputer menjadi tidak responsif lebih sulit didiagnosis, tetapi prosedur untuk men-debugnya serupa. Kesalahan ini sering disebabkan oleh jumlah referensi atau masalah pengunci spin. Untungnya, Driver Verifier akan menangkap banyak masalah spin lock sebelum menyebabkan masalah. Dalam kasus ini, masuk ke debugger dan gunakan ekstensi debugger untuk menampilkan daftar kerusakan yang disuntikkan oleh Stack Based Failure Injection. Melihat sekilas pada kode di sekitar kegagalan terbaru bisa menunjukkan penghitungan referensi yang dicatat sebelum kegagalan tetapi tidak dilepaskan setelahnya. Jika tidak, cari utas di driver Anda yang menunggu pada kunci putaran, atau untuk jumlah referensi apa pun yang jelas salah.