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.
Opsi Pemeriksaan Lain-lain dari Driver Verifier memantau driver untuk kesalahan umum yang menyebabkan driver atau sistem mengalami crash, seperti membebaskan memori yang masih berisi objek kernel aktif.
Secara khusus, opsi Pemeriksaan Lain-lain mencari perilaku driver yang tidak tepat berikut:
Elemen kerja aktif dalam memori yang telah dibebaskan. Driver memanggil ExFreePool untuk membebaskan blok kumpulan yang berisi item kerja yang diantrekan dengan menggunakan IoQueueWorkItem.
Sumber daya aktif dalam memori yang dikosongkan. Pengemudi memanggil ExFreePool untuk membebaskan blok pool yang berisi struktur ERESOURCE yang aktif. Driver harus memanggil ExDeleteResource untuk menghapus objek ERESOURCE sebelum memanggil ExFreePool.
Daftar lookaside aktif dalam memori yang dibebaskan. Driver memanggil ExFreePool untuk membebaskan blok kumpulan yang masih berisi struktur daftar lookaside aktif, baik NPAGED_LOOKASIDE_LIST maupun PAGED_LOOKASIDE_LIST. Driver harus memanggil ExDeleteNPagedLookasideList atau ExDeletePagedLookasideList untuk menghapus daftar lookaside sebelum memanggil ExFreePool.
Masalah pendaftaran Windows Management Instrumentation (WMI) dan Pelacakan Peristiwa Windows (ETW). Masalah yang terdeteksi oleh Driver Verifier meliputi:
Driver yang mencoba menghapus tanpa membatalkan pendaftaran panggilan balik WMI-nya.
Driver yang mencoba menghapus objek perangkat yang belum dibatalkan pendaftarannya dari WMI.
Driver yang mencoba membongkar penyedia mode kernel ETW tanpa membatalkan pendaftarannya.
Driver yang mencoba membatalkan pendaftaran penyedia yang sudah tidak terdaftar.
Kesalahan penanganan kernel. (Windows Vista dan versi lebih baru) Mengaktifkan opsi Pemeriksaan Lain-lain juga akan memungkinkan pelacakan handle untuk proses sistem, yang dapat membantu menyelidiki kebocoran handle kernel dan Bug Check 0x93: INVALID_KERNEL_HANDLE. Dengan pelacakan pegangan diaktifkan, kernel akan mengumpulkan jejak stack untuk operasi buka dan tutup pegangan terbaru. Jejak tumpukan dapat ditampilkan di debugger kernel menggunakan ekstensi debugger !htrace . Untuk informasi selengkapnya tentang !htrace, lihat dokumentasi Alat Penelusuran Kesalahan untuk Windows.
Handel mode pengguna dengan akses mode kernel Dimulai dengan Windows 7, ketika Anda memilih opsi Pemeriksaan Lain-lain, Driver Verifier juga memeriksa panggilan ke ObReferenceObjectByHandle. Anda tidak dapat meneruskan handle mode pengguna dengan akses mode kernel. Jika operasi seperti itu terjadi, Pemverifikasi Driver mengeluarkan Bug Check 0xC4, dengan nilai parameter 1 adalah 0xF6.
UserMode Tunggu Objek Sinkronisasi yang Dialokasikan di Tumpukan Kernel
Dimulai dengan Windows 7, Driver Verifier dapat mendeteksi cara tambahan bahwa driver dapat salah menggunakan mekanisme sinkronisasi multithreading yang disediakan sistem operasi.
Mengalokasikan objek sinkronisasi, seperti struktur KEVENT, sebagai variabel lokal pada tumpukan kernel adalah praktek yang umum. Saat suatu proses dimuat dalam memori, tumpukan kernel dari utasnya tidak pernah dipotong dari set kerja atau dikeluarkan ke disk. Mengalokasikan objek sinkronisasi dalam memori yang tidak dapat diserap tersebut sudah benar.
Namun, ketika driver memanggil API seperti KeWaitForSingleObject atau KeWaitForMultipleObjects untuk menunggu objek yang dialokasikan pada tumpukan, mereka harus menentukan nilai KernelMode untuk parameter WaitMode API. Ketika semua utas dari sebuah proses menunggu dalam mode UserMode, proses tersebut dapat dipindahkan ke disk. Oleh karena itu, jika driver menentukan UserMode sebagai parameter WaitMode, sistem operasi dapat mengalihkan proses saat ini selama semua utas lain dalam proses yang sama juga menunggu sebagai UserMode. Memindahkan seluruh proses ke disk termasuk memindahkan tumpukan kernel. Menunggu pada objek sinkronisasi yang telah dipindahkan oleh sistem operasi adalah tidak benar. Pada titik tertentu, utas harus datang dan memberi sinyal objek sinkronisasi. Menandakan objek sinkronisasi melibatkan kernel Windows yang memanipulasi objek di IRQL = DISPATCH_LEVEL atau lebih tinggi. Menyentuh memori yang di-paged out atau di-swapped out pada DISPATCH_LEVEL atau di atasnya menyebabkan sistem crash.
Sejak Windows 7, ketika Anda memilih opsi Pemeriksaan Lainnya, Pemverifikasi Driver memastikan bahwa objek sinkronisasi yang digunakan oleh driver terverifikasi untuk menunggu di UserMode tidak dialokasikan pada tumpukan kernel dari utas saat ini. Ketika Driver Verifier mendeteksi penantian yang salah, Driver Verifier mengeluarkan Pemeriksaan Bug 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION, dengan nilai dari parameter 1 0x123.
Referensi Handle Kernel Salah
Setiap proses Windows memiliki tabel handle. Anda dapat melihat tabel pegangan sebagai array berisi entri pegangan. Setiap nilai handel yang valid mengacu pada entri yang valid dalam array ini.
Handle kernel sebagai handle yang valid untuk tabel handle proses Sistem. Handle pengguna adalah handle yang valid untuk proses apa pun kecuali proses Sistem.
Di Windows 7, Driver Verifier mendeteksi upaya untuk merujuk nilai handle kernel yang salah. Kecacatan driver ini dilaporkan sebagai Bug Check 0x93: INVALID_KERNEL_HANDLE jika opsi Cek Rutin Miscellaneous dari Pemverifikasi Driver diaktifkan. Biasanya, kesalahan referensi handle seperti ini berarti bahwa driver telah menutup handle tersebut tetapi masih mencoba untuk menggunakannya. Cacat semacam ini dapat mengakibatkan masalah yang tidak dapat diprediksi untuk sistem karena nilai handel yang sedang direferensikan mungkin telah digunakan kembali oleh driver lain yang tidak terkait.
Jika driver kernel baru-baru ini menutup handle kernel dan kemudian mereferensikan handle yang telah ditutup, Driver Verifier memaksa cek bug seperti yang dijelaskan sebelumnya. Dalam kasus ini, output dari ekstensi !htrace menyediakan penelusuran tumpukan untuk jalur kode yang menutup handle ini. Gunakan alamat proses Sistem sebagai parameter untuk !htrace. Untuk menemukan alamat proses Sistem, gunakan perintah !process 4 0 .
Mulai dari Windows 7, Driver Verifier menambahkan pemeriksaan ke ObReferenceObjectByHandle. Sekarang dilarang untuk menggunakan handle ruang pengguna dengan akses KernelMode. Jika kombinasi seperti itu terdeteksi, Driver Verifier mengeluarkan Bug Check 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION, dengan parameter 1 nilai 0xF6.
Mengaktifkan opsi ini
Anda dapat mengaktifkan opsi Pemeriksaan Lain-lain untuk satu atau beberapa driver dengan menggunakan Driver Verifier Manager atau baris perintah Verifier.exe. Untuk detailnya, lihat Memilih Opsi Pemverifikasi Driver.
Pada baris perintah
Pada baris perintah, opsi Pemeriksaan Lain-lain diwakili oleh Bit 11 (0x800). Untuk mengaktifkan Pemeriksaan Lain-lain, gunakan nilai bendera 0x800 atau tambahkan 0x800 ke nilai bendera. Contohnya:
verifier /flags 0x800 /driver MyDriver.sysOpsi akan aktif setelah boot berikutnya.
Pada Windows Vista dan versi Windows yang lebih baru, Anda juga dapat mengaktifkan dan menonaktifkan Pemeriksaan Lain-lain tanpa me-reboot komputer dengan menambahkan parameter /volatile ke perintah . Contohnya:
verifier /volatile /flags 0x800 /adddriver MyDriver.sysPengaturan ini segera efektif, tetapi hilang ketika Anda mematikan atau me-reboot komputer. Untuk detailnya, lihat Menggunakan Pengaturan Volatil.
Opsi Pemeriksaan Lain-lain juga disertakan dalam pengaturan standar. Contohnya:
verifier /standard /driver MyDriver.sysMenggunakan Pengelola Verifikasi Pengemudi
Mulai Manajer Verifikasi Driver. Ketik Pemverifikasi di jendela Command Prompt.
Pilih Buat pengaturan kustom (untuk pengembang kode), lalu klik Berikutnya.
Pilih Pilih pengaturan individual dari daftar lengkap.
Pilih Pemeriksaan Lain-lain.
Fitur Pemeriksaan Lain-lain juga disertakan dalam pengaturan standar. Untuk menggunakan fitur ini, di Driver Verifier Manager, klik Buat Pengaturan Standar.
Menampilkan Hasil
Untuk melihat hasil opsi Pemeriksaan Lain-lain, gunakan ekstensi !verifier di debugger kernel. (Untuk informasi tentang !verifier, lihat dokumentasi Alat Debugging untuk Windows .)
Dalam contoh berikut, opsi Pemeriksaan Lain-lain mendeteksi struktur ERESOURCE aktif dalam memori yang coba dibebaskan driver, menghasilkan Pemeriksaan Bug 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION. Pemeriksaan Bug 0xC4 mencakup alamat ERESOURCE dan memori yang terpengaruh.
1: kd> !verifier 1
Verify Level 800 ... enabled options are:
Miscellaneous checks enabled
Summary of All Verifier Statistics
RaiseIrqls 0x0
AcquireSpinLocks 0x0
Synch Executions 0x0
Trims 0x0
Pool Allocations Attempted 0x1
Pool Allocations Succeeded 0x1
Pool Allocations Succeeded SpecialPool 0x0
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0
Current paged pool allocations 0x0 for 00000000 bytes
Peak paged pool allocations 0x0 for 00000000 bytes
Current nonpaged pool allocations 0x0 for 00000000 bytes
Peak nonpaged pool allocations 0x0 for 00000000 bytes
Driver Verification List
Entry State NonPagedPool PagedPool Module
8459ca50 Loaded 00000000 00000000 buggy.sys
*** Fatal System Error: 0x000000c4
(0x000000D2,0x9655D4A8,0x9655D468,0x000000B0)
0xD2 : Freeing pool allocation that contains active ERESOURCE.
2 - ERESOURCE address.
3 - Pool allocation start address.
4 - Pool allocation size.
Untuk menyelidiki alokasi kumpulan, gunakan ekstensi debugger !pool dengan alamat awal alokasi kumpulan, 9655D468. (Bendera 2 menampilkan informasi header hanya untuk kumpulan yang berisi alamat yang ditentukan. Informasi header untuk kumpulan lain tidak ditampilkan.)
1: kd> !pool 9655d468 2
Pool page 9655d468 region is Paged pool
*9655d468 size: b0 previous size: 8 (Allocated) *Bug_
Untuk menemukan informasi tentang ERESOURCE, gunakan ekstensi debugger !locks (!kdext*.locks) dengan alamat struktur.
1: kd> !locks 0x9655D4A8 <<<<<- ERESOURCE @0x9655D4A8 lives inside the pool block being freed
Resource @ 0x9655d4a8 Available
1 total locks
Anda juga dapat menggunakan perintah debugger kb untuk menampilkan jejak tumpukan panggilan yang menyebabkan kegagalan. Contoh berikut menunjukkan tumpukan, termasuk panggilan ke ExFreePoolWithTag yang diintersepsi oleh Driver Verifier.
1: kd> kb
ChildEBP RetAddr Args to Child
92f6374c 82c2c95a 00000003 92f68cdc 00000000 nt!RtlpBreakWithStatusInstruction
92f6379c 82c2d345 00000003 9655d468 000000c4 nt!KiBugCheckDebugBreak+0x1c
92f63b48 82c2c804 000000c4 000000d2 9655d4a8 nt!KeBugCheck2+0x5a9
92f63b6c 82e73bae 000000c4 000000d2 9655d4a8 nt!KeBugCheckEx+0x1e
92f63b88 82e78c32 9655d4a8 9655d468 000000b0 nt!VerifierBugCheckIfAppropriate+0x3c
92f63ba4 82ca7dcb 9655d468 000000b0 00000000 nt!VfCheckForResource+0x52
92f63bc8 82e7fb2d 000000b0 00000190 9655d470 nt!ExpCheckForResource+0x21
92f63be4 82e6dc6c 9655d470 92f63c18 89b6c58c nt!ExFreePoolSanityChecks+0x1fb
92f63bf0 89b6c58c 9655d470 00000000 89b74194 nt!VerifierExFreePoolWithTag+0x28
92f63c00 89b6c0f6 846550c8 846550c8 846e2200 buggy!MmTestProbeLockForEverStress+0x2e
92f63c18 82e6c5f1 846e2200 846550c8 85362e30 buggy!TdDeviceControl+0xc4
92f63c38 82c1fd81 82d4d148 846550c8 846e2200 nt!IovCallDriver+0x251
92f63c4c 82d4d148 85362e30 846550c8 84655138 nt!IofCallDriver+0x1b
92f63c6c 82d4df9e 846e2200 85362e30 00000000 nt!IopSynchronousServiceTail+0x1e6
92f63d00 82d527be 00000001 846550c8 00000000 nt!IopXxxControlFile+0x684
92f63d34 82cb9efc 0000004c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
92f63d34 6a22b204 0000004c 00000000 00000000 nt!KiFastCallEntry+0x12c