Pemverifikasi Aplikasi - Tanya Jawab Umum (FAQ)

Pertanyaan Umum

Berikut adalah daftar pertanyaan yang diterima sekeliling penggunaan umum Pemverifikasi Aplikasi.

Apa itu Pemverifikasi Aplikasi?

Application Verifier adalah alat verifikasi runtime yang digunakan untuk menemukan bug di Aplikasi Microsoft Windows. Karena ini adalah alat runtime kode aplikasi perlu dijalankan untuk diverifikasi. Oleh karena itu, cakupan pengujian yang baik sangat penting.

Skenario penggunaan khas Pemverifikasi Aplikasi adalah mengaktifkannya untuk aplikasi yang menarik (lihat pertanyaan di bawah ini tentang cara melakukannya) lalu jalankan semua pengujian yang telah Anda tulis untuk aplikasi Anda. Anda akan mendapatkan pemberitahuan untuk bug apa pun yang ditemukan dalam bentuk pemutusan debugger atau entri log pemverifikasi.

Bagaimana cara menghapus instalasi Pemverifikasi Aplikasi?

Untuk menghapus instalasi Pemverifikasi Aplikasi, akses panel kontrol dengan mengklik Mulai, pilih Tambahkan atau Hapus Program, lalu Hapus program, klik Pemverifikasi Aplikasi, lalu klik Hapus.

Bagaimana cara memulai Pemverifikasi Aplikasi?

Setelah menginstal Pemverifikasi Aplikasi, Anda dapat memulainya dengan mengaksesnya di daftar program Anda ATAU dengan mengetik Appverif.exe pada baris perintah. Untuk melakukan ini, buka perintah atau kotak Jalankan dari menu Startup. Ketik appverif.exe lalu tekan Enter. Ini akan memulai Pemverifikasi Aplikasi.

Biner Appverifer.exe diinstal di direktori sistem dan digunakan untuk membuat pengaturan alat.

Di mana log disimpan?

Log disimpan di %USERPROFILE%\AppVerifierLogs

Apa yang harus saya lakukan jika saya mengalami masalah saat menggunakan Pemverifikasi Aplikasi?

Pastikan Anda menjalankan rilis terbaru. Pertimbangkan untuk mencoba aplikasi yang sama pada PC yang berbeda atau bahkan versi Windows.

Apakah Pemverifikasi Aplikasi memverifikasi kode terkelola?

AppVerifier peduli tentang antarmuka antara sistem operasi dan aplikasi. Akibatnya, kecuali kode terkelola Anda melakukan interop terhadap API asli yang ada hubungannya dengan Heaps, Handles, Critical Section, dll. kasus pengujian Anda tidak akan memberi Anda interaksi apa pun dengan antarmuka yang diverifikasi.

Sebaiknya manfaatkan Asisten Penelusuran Kesalahan Terkelola untuk memverifikasi kode terkelola Anda. Baca selengkapnya tentang mereka di Debugging Kode Terkelola Menggunakan Windows Debugger.

Apakah ARM64EC didukung?

Pemverifikasi Aplikasi tidak mendukung ARM64EC.

Pertanyaan Debugger

Berikut adalah daftar pertanyaan yang diterima mengenai debugger.

Mengapa saya menerima kesalahan yang memberi tahu saya bahwa saya memerlukan debugger?

Lapisan verifikasi Dasar dalam Pemverifikasi Aplikasi mengharuskan Anda menjalankan aplikasi di bawah debugger. Jika Anda tidak memiliki debugger yang terkait dengan aplikasi sebelum memilih pengujian, Anda akan menerima dialog yang mengingatkan Anda bahwa Anda harus menjalankan aplikasi Anda di bawah debugger untuk mendapatkan informasi yang dicatat.

Bagaimana cara menjalankan aplikasi saya di bawah debugger?

Lihat topik penginstalan dan penyetelan Debugger - Memulai Penelusuran Kesalahan Windows

Bagaimana cara menguji ekspansi tumpukan tanpa instrumentasi lain?

Secara umum, ekspansi tumpukan harus benar-benar diuji dalam isolasi dari lapisan verifikasi lain, termasuk tumpukan. Alasannya adalah sebagai berikut: setiap lapisan verifikasi "thunks" API atau titik yang diekspor dengan beberapa rutinitas.

Misalnya, panggilan ke CreateFileA, akan menjadi panggilan ke appvocre! NS_SecurityChecks::CreateFileA, yang mungkin memanggil appvcore! NS_FillePaths::CreateFileA yang mungkin memanggil kernel32! CreateFileA, yang mungkin memanggil pemverifikasi! AVrfpNtCreateFile, yang akan memanggil ntdll! NtCreateFile. Anda dapat melihat bahwa instrumentasi telah menambahkan 3 panggilan fungsi "bertumpuk" lagi, masing-masing dapat dan akan mengonsumsi lebih banyak tumpukan.

Dalam kasus di bawah ini, LH-verifier.dll "mengintai" setiap DllMain, dan jalur kode tumpukan "berinstrumentasi" akan menambahkan lebih banyak penggunaan tumpukan. Karena utas yang disuntikkan dari debugger tidak menggunakan default IMAGE_NT_HEADERS, tumpukan yang awalnya diterapkan tidak akan cukup untuk menyelesaikan status APC utas (utas dalam status APC menjalankan kode inisialisasi).

Jika Anda ingin menggunakan Stack-Ckecs, mungkin satu-satunya lapisan verifikasi lainnya yang harus Anda gunakan jika FirstChanceAccessViolation.

Saat menggunakan ekstensi !avrf, saya mendapatkan 'Pemverifikasi aplikasi tidak diaktifkan untuk proses ini...'

Kesalahan lengkap yang diterima: Application verifier is not enabled for this process. Use appverif.exe tool to enable it.

Anda mungkin hanya mengaktifkan lapisan verifikasi shim dan/atau timbunan dalam mode "murni". Ini adalah beberapa kemungkinan penyebabnya.

Pertanyaan Skenario Pengujian

Berikut ini adalah daftar pertanyaan yang diterima di sekitar skenario pengujian yang berbeda.

Bagaimana cara mengaktifkan Pemverifikasi Aplikasi di layanan saya tetapi bukan yang lain?

Buat salinan svchost.exe di direktori System32 dan panggil salinan "Mysvchost.exe".

Dengan menggunakan regedit, buka HKLM\System\CurrentControlSet\Services\MyService.

Edit nilai "ImagePath", yang akan menjadi sesuatu seperti "%SystemRoot%\system32\svchost.exe -k myservice" dan ubah svchost.exe menjadi "Mysvchost.exe".

Tambahkan "Mysvchost.exe" ke daftar AppVerifier dan periksa pengujian yang diinginkan.

Mulai ulang.

Bagaimana cara menjalankan Application Verifier pada aplikasi 64-bit yang diluncurkan dari aplikasi 32-bit yang berjalan di bawah WOW64?

Versi sederhana: Aturan emas untuk mengaktifkan pengaturan pemverifikasi pada aplikasi tertentu adalah mencocokkan bit-ness alat dan proses target. Artinya: gunakan appverif.exe 32-bit untuk aplikasi 32-bit (keduanya berjalan di bawah WoW64) dan gunakan AppVerif.exe 64-bit untuk target asli 64-bit asli.

Versi Panjang: Pengaturan Pemverifikasi Aplikasi adalah penyatuan pengaturan "inti" dan pengaturan "shim" yang tepat.

Pengaturan inti - Pengaturan inti disimpan di bawah Opsi Eksekusi File Gambar.

Nilai "Debugger" dibaca dari aplikasi peluncuran. Jadi, jika Anda ingin memiliki 32-bit devenv.exe meluncurkan my.exe 64-bit dan menjalankannya di bawah debugger, Anda harus menggunakan kunci registri 32-bit di bawah WoW6432Node. Nilai lain, untuk proses 32-bit, dibaca dari kedua tempat, baik IFEO asli maupun WoW6432Node.

Penalarannya adalah sebagai berikut: proses 32-bit yang berjalan di bawah WoW adalah proses 64-bit yang menjalankan perulangan emulasi Wow64. Jadi, setiap proses 32-bit adalah proses 64-bit pertama, dan kemudian proses 32-bit. IFEO 64-bit akan mengaktifkan pemverifikasi pada kode Wow64cpu.dll, sementara IFEO 32-bit akan mengaktifkan pemverifikasi pada kode 32-bit.

Dari sudut pandang pengguna akhir, verifier.dll dimuat dua kali (sekali di dunia 64-bit, sekali di dunia 32-bit). Karena sebagian besar orang tidak peduli tentang memverifikasi wow64cpu.dll, perilaku yang paling diterima untuk proses 32-bit adalah hanya memverifikasi bagian 32-bit. Itulah sebabnya aturan emas "selalu cocok dengan bit-ness" berlaku.

Bagaimana cara men-debug layanan saya yang berjalan di stasiun jendela non-interaktif

Untuk men-debug layanan yang berjalan di stasiun jendela non-interaktif, lakukan hal berikut (hanya berlaku jika Anda menggunakan ntsd/windbg):

Tambahkan kunci ke registri di bawah Opsi Eksekusi File HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image. Nama kunci ini harus menjadi nama proses (service.exe).

Buat nilai REG_SZ yang disebut Debugger dan atur nilai ini ke jalur tempat debugger Anda berada. Ini harus berisi jalur lengkap, bukan hanya nama debugger. Perintah harus menyertakan opsi –server dan port atau rentang port tertentu yang harus didengarkan debugger. Contohnya adalah c:\debuggers\ntsd.exe –server tcp:port=5500:5600 –g –G.

Sambungkan ke server debugger dengan menjalankan debugger dengan opsi –remote. Contohnya adalah: windbg.exe –remote tcp:=localhost,port=55xx di mana 'xx' adalah beberapa angka dari 00 hingga 99 jika Anda menggunakan rentang di server.

Apakah AppVerifier melakukan deteksi kebocoran? Di bawah Windows 7 dan yang lebih besar, ada opsi pemeriksaan Kebocoran yang akan mendeteksi kapan proses bocor memori. Di bawah sistem operasi sebelumnya, AppVerifier tidak menguji aplikasi untuk deteksi kebocoran tetapi mencari masalah memori lainnya.

Tes mana yang direkomendasikan untuk masalah keamanan?

• Tumpukan
• Handles
• Penguncian
• Tumpukan (hanya untuk layanan dan proses penting yang dapat menurunkan mesin)

Perlu diingat bahwa ObsoleteAPICalls hanya akan meludahi peringatan untuk setiap panggilan yang dilihatnya ke API yang terdaftar sebagai usang atau tidak digunakan lagi di MSDN. Anda harus memutuskan kasus per kasus jika penting bagi aplikasi Anda untuk beralih ke API baru. Beberapa API berbahaya, dan beberapa hanya digantikan oleh API yang lebih baru dengan lebih banyak opsi. Lihat bagian "API Berbahaya" dari Penulisan Kode Aman, penambahan ke-2 untuk lebih banyak lagi.

Untuk aplikasi yang harus sangat andal, seperti layanan dan program server, Anda juga harus mengaktifkan pemeriksaan Stacks. Ini memeriksa untuk melihat apakah ukuran penerapan tumpukan memadai, dengan menonaktifkan pertumbuhan tumpukan. Jika aplikasi segera berhenti dengan luapan tumpukan, itu berarti aplikasi perlu dikompresi ulang dengan ukuran penerapan tumpukan yang lebih besar. Jika Anda seorang penguji, dan mengalami masalah dengan aplikasi saat menggunakan pemeriksaan Stacks, ajukan bug, tetapkan ke pengembang Anda, dan terus uji.

Uji Pertanyaan Spesifik

Berikut ini adalah daftar pertanyaan sekeliling pengujian. Klik pertanyaan untuk melihat respons:

Apakah kebocoran bagian penting?

Setiap kali Anda membocorkan bagian penting, Anda membocorkan hal berikut: handel peristiwa, sejumlah kecil kumpulan kernel, dan alokasi timbunan kecil. Ini akan dibersihkan jika proses keluar.

Jika proses Anda seharusnya tetap hidup dalam waktu yang lama, maka kebocoran ini dapat menggigit Anda. Karena perbaikannya sangat mudah dalam 99% kasus (pengembang lupa memanggil RtlDeleteCriticalSection) Anda harus mengatasinya.

Dapatkah kita berurusan secara terprogram dengan luapan tumpukan?

Membuat handler pengecualian dalam fungsi utas awal tidak dijamin untuk menangkap potensi luapan tumpukan yang mungkin dinaikkan. Ini karena kode yang mengirimkan pengecualian juga membutuhkan sedikit tumpukan untuk dijalankan di atas catatan aktivasi saat ini. Karena kami baru saja gagal ekstensi tumpukan, kemungkinan besar kami akan melangkahi akhir tumpukan yang diterapkan dan menaikkan pengecualian kedua saat mencoba mengirimkan yang pertama. Pengecualian kesalahan ganda akan mengakhiri proses tanpa syarat.

Pengujian LoaderLock memberikan kesalahan tentang memanggil DestroyWindow. Mengapa saya tidak dapat memanggil DestroyWindow di DllMain? Anda tidak mengontrol utas mana yang akan dilepaskan. Jika bukan utas yang sama yang membuat jendela, Anda tidak dapat menghancurkan jendela. Jadi Anda membocorkan jendela dan lain kali jendela menerima pesan, Anda crash karena Wndproc telah dibongkar.

Anda perlu menghancurkan jendela sebelum Anda mendapatkan proses-lepaskan. Bahayanya bukan karena user32 akan dibongkar. Bahayanya adalah kau dibongkar. Jadi pesan berikutnya yang diterima jendela akan merusak proses karena user32 akan mengirimkan pesan ke Wndproc Anda yang tidak ada lagi.

Sistem operasi Microsoft Windows memiliki afinitas utas. Proses-lepas tidak. Kunci loader tidak benar-benar masalah besar; masalahnya adalah Dllmain. Proses-lepas adalah terakhir kali DLL Anda menjalankan kode. Anda harus menyingkirkan segala sesuatu sebelum Anda kembali. Tetapi karena Windows memiliki afinitas utas, Anda tidak dapat membersihkan jendela jika Anda berada di utas yang salah.

Kunci loader masuk ke dalam gambar jika seseorang memiliki kait global yang terinstal (misalnya, spy++ sedang berjalan). Dalam hal ini, Anda memasukkan skenario kebuntuan potensial. Sekali lagi, solusinya adalah menghancurkan jendela sebelum Anda mendapatkan proses-lepaskan.

Apakah mahal untuk meningkatkan penerapan tumpukan awal untuk menghindari luapan?

Ketika Anda menerapkan tumpukan, Anda hanya mempertahankan ruang file halaman. Tidak ada dampak performa. Tidak ada memori fisik yang benar-benar digunakan. Satu-satunya biaya tambahan terjadi jika Anda benar-benar menyentuh ruang tumpukan yang Anda lakukan. Tapi ini tetap akan terjadi bahkan jika Anda tidak melakukan tumpukan di muka.

Mari kita lihat berapa biaya untuk membuat semua layanan berjalan dalam svchost.exe antipeluru. Pada mesin uji, saya mendapatkan 9 proses svchost.exe memiliki total 139 utas. Jika kita mengatur tumpukan default untuk setiap utas pada 32K, kita akan membutuhkan sekitar 32K x 200 ~ 6,4 Mb ruang file halaman untuk menerapkan semua tumpukan di muka.

Ini adalah harga yang cukup kecil untuk membayar keandalan.

Bagaimana dengan ukuran tumpukan yang dipesan?

Ada item menarik, seperti pengiriman pengecualian pada IA64/AMD64 yang membutuhkan tumpukan tambahan "tak terduga". Mungkin ada beberapa pemrosesan yang terjadi pada utas pekerja RPC yang persyaratan tumpukannya melewati upaya yang wajar untuk mengukurnya.

Pertama-tama, Anda harus mendapatkan gambaran tentang semua kumpulan utas yang hidup dalam proses. NT-Thread-Pool, dengan alertable-wait-threads terkadang istimewa, karena, misalnya, jika Anda menggunakan komponen database dari SQL, itu akan menggunakan tidur yang dapat diperingatkan di atas utas yang merupakan target user-APC. Ini dapat menyebabkan masalah dengan panggilan berlapis.

Setelah Anda mengetahui semua kumpulan utas, dapatkan gambaran tentang cara mengontrol persyaratan tumpukannya. Misalnya, RPC membaca kunci registri untuk penerapan tumpukan. Utas pompa WDM mendapatkannya dari gambar. Untuk Kumpulan Utas Lainnya, jarak tempuhnya dapat bervariasi.

Ketika Anda semua utas jelas, Anda dapat mengambil beberapa tindakan. Tidak memiliki ruang cadangan yang besar membantu mengatasi fragmentasi ruang hanya jika utas datang dan berjalan sangat sering. Jika Anda memiliki kumpulan utas stabil yang ada di kontrol Anda, maka Anda mungkin memiliki keuntungan dalam mengurangi ruang yang dipesan juga. Ini akan sangat membantu dalam menghemat ruang alamat untuk timbunan dan ruang alamat untuk pengguna.

Apakah ada rekomendasi tentang cara memilih ukuran yang tepat untuk LINKER_STACKCOMMITSIZE=?

Nilai harus dapat dibagi berdasarkan ukuran halaman (4k/8k tergantung pada CPU). Berikut adalah beberapa panduan untuk menentukan ukuran yang Anda butuhkan akan dilakukan:

1. Konversikan fungsi rekursif apa pun dengan potensi kedalaman tidak terikat (atau setidaknya kedalaman tinggi yang dapat diinduksi pengguna) menjadi berulang.

2. Kurangi penggunaan alloca. Gunakan timbunan atau safealloca.

3. Jalankan Prefast dengan pengurangan pemeriksaan ukuran tumpukan (misalnya 8k). Perbaiki fungsi-fungsi yang ditandai sebagai menggunakan terlalu banyak tumpukan.

4. Atur penerapan tumpukan ke 16k.

5. Jalankan di bawah kumpulan tes debugger dengan pemeriksaan "Tumpukan" Application Verifier.

6. Ketika Anda melihat luapan tumpukan menentukan pelanggar terburuk dan memperbaikinya. (Lihat langkah 5.)

7. Ketika Anda tidak dapat mengurangi penggunaan tumpukan lebih banyak benjolan sebesar 8k. Jika Anda > 64k ada sesuatu yang salah, kurangi kembali ke 64k dan lihat langkah 6. Jika tidak, buka langkah 5.

Apa persyaratan memori untuk tes tumpuk?

Untuk pengujian tumpukan penuh, Anda memerlukan RAM 256MB dan setidaknya file halaman 1GB. Untuk pengujian tumpukan normal, Anda memerlukan setidaknya 128MB RAM. Tidak ada persyaratan prosesor atau disk tertentu.

Mengapa saya menerima ALL_ACCESS berhenti?

Aplikasi apa pun yang menggunakan _ALL_ACCESS merender objek yang diaksesnya tidak dapat diaudit karena log audit tidak akan mencerminkan apa yang sebenarnya telah Anda lakukan dengan objek —hanya apa yang Anda minta untuk dilakukan dengan objek.

Kondisi ini menciptakan kamuflase untuk serangan yang lebih mengerikan. Administrator yang memindai aktivitas serangan yang sedang berlangsung tidak akan melihat ada yang salah dengan orang yang meminta ALL_ACCESS pada kunci X, karena aplikasi tertentu selalu melakukannya. Administrator akan berpikir "orang tersebut mungkin hanya menjalankan Word". Administrator tidak dapat memberitahu bahwa peretas telah menembus akun saya dan sekarang menyelidiki sistem untuk menentukan akses apa yang saya miliki, yang dapat dia eksploitasi untuk ujungnya yang jahat. Kemungkinannya tidak ada habisnya.

Masalah ACL dengan ALL_ACCESS adalah Anda harus selalu diberikan. Jika suatu hari nanti kami ingin menolak akses DELETE Anda ke kunci tertentu, kami tidak akan dapat. Meskipun Anda tidak benar-benar menghapus kunci, kami akan melanggar aplikasi Anda karena Anda akan meminta akses penghapusan.

Mengapa saya tidak mendapatkan log dari heap dan uji kunci?

Pengujian tersebut adalah lapisan verifikasi yang dibangun dalam sistem operasi (dan bukan dalam paket) dan melaporkan kesalahan dalam debugger. Jika Anda menjalankan aplikasi dengan pengujian tersebut diaktifkan dan tidak mengalami crash, maka mereka tidak melaporkan masalah apa pun.

Jika Anda mengalami crash, perlu dijalankan di bawah debugger, atau meneruskan aplikasi ke pengembang untuk menguji lebih dekat.

Mengapa injeksi kesalahan tidak berfungsi?

Probabilitas injeksi kesalahan diubah menjadi suku cadang per juta dalam build AppVerifier yang dirilis setelah Februari 2007 berdasarkan umpan balik pelanggan. Jadi, kemungkinan 0n20000 adalah 2%, 0n500000 adalah 50% dan sebagainya.

!avrf –flt debugger extension dapat digunakan untuk mengubah probabilitas dengan cepat di debugger. Namun, pemeriksaan Simulasi Sumber Daya Rendah untuk proses harus diaktifkan agar ini berfungsi.

Ekstensi debugger !avrf adalah bagian exts.dll yang dikirim dengan paket debugger. Perubahan dalam !avrf yang mendukung perubahan probabilitas ada dalam paket debugger terbaru. Jika Anda mengalami masalah dengan injeksi kesalahan, perbarui debugger dan paket AppVerifier Anda.

Mengapa Pemverifikasi Kebocoran tidak melaporkan kebocoran sumber daya tertentu?

Pemverifikasi Kebocoran tidak melaporkan kebocoran sumber daya saat modul DLL atau EXE dimuat. Saat modul dibongkar, Pemverifikasi Bocor mengeluarkan pemberhentian jika salah satu sumber daya yang dialokasikan oleh modul belum dirilis.

Untuk memeriksa sumber daya yang dialokasikan oleh DLL atau EXE yang dimuat, gunakan ekstensi !avrf -leak debugger.

Lihat Juga

Pemverifikasi Aplikasi - Gambaran Umum

Pemverifikasi Aplikasi - Fitur

Pemverifikasi Aplikasi - Aplikasi Pengujian

Pemverifikasi Aplikasi - Pengujian dalam Pemverifikasi Aplikasi

Pemverifikasi Aplikasi - Hentikan Kode dan Definisi

Pemverifikasi Aplikasi - Debugging Pemverifikasi Aplikasi Berhenti