Pemverifikasi Aplikasi - Pengujian dalam Pemverifikasi Aplikasi

Dukungan ARM64EC

Pemverifikasi Aplikasi tidak mendukung ARM64EC.

Dasar

Minimal, Anda harus menjalankan Pemverifikasi Aplikasi dengan pengaturan Dasar yang dipilih. Masing-masing akan menguji area yang akan menyebabkan crash atau skenario negatif lainnya, yang memiliki dampak langsung dan signifikan dari pengalaman pelanggan.

Pengecualian - Memastikan bahwa aplikasi tidak menyembunyikan pelanggaran akses menggunakan penanganan pengecualian terstruktur
Handel - Pengujian untuk memastikan aplikasi tidak mencoba menggunakan handel yang tidak valid
Tumpukan - Memeriksa masalah kerusakan memori dalam tumpukan
Kebocoran - Mendeteksi kebocoran dengan melacak sumber daya yang dibuat oleh dll yang tidak dibebankan pada saat dll dibongkar
Kunci - Memverifikasi penggunaan yang benar untuk bagian penting
Memori - Memastikan API untuk manipulasi ruang virtual digunakan dengan benar (misalnya, VirtualAlloc, MapViewOfFile)
SRWLock - memverifikasi penggunaan yang benar untuk kunci pembaca/penulis ramping (SRW).
Threadpool - Memastikan penggunaan API threadpool yang benar dan memberlakukan pemeriksaan konsistensi pada worker-thread-states setelah panggilan balik seperti utas threadpool kotor dan masalah terkait threadpool lainnya.
TLS - Memastikan bahwa API Penyimpanan Lokal Utas digunakan dengan benar

Untuk informasi tentang pengecualian kode berhenti yang dihasilkan oleh pengujian ini, lihat Pemverifikasi Aplikasi - Hentikan Kode dan Definisi. Untuk informasi tentang penelusuran kesalahan kegagalan ini, lihat Pemverifikasi Aplikasi - Men-debug Penghentian Pemverifikasi Aplikasi

Kompatibilitas

Pengujian Lapisan Verifikasi Kompatibilitas membantu mengidentifikasi aplikasi yang mungkin memiliki masalah dengan sistem operasi Microsoft Windows. Banyak dari pemeriksaan ini juga dapat digunakan untuk menguji persyaratan logo/sertifikasi.

Untuk informasi tentang pengecualian kode berhenti yang dihasilkan oleh pengujian ini, lihat Pemverifikasi Aplikasi - Hentikan Kode dan Definisi.

HighVersionLie — Mengidentifikasi masalah untuk beberapa masalah kompatibilitas aplikasi yang paling umum di Windows. Mendeteksi versi sistem operasi secara tidak benar atau menggunakan informasi versi yang dikodekan secara permanen dapat menyebabkan aplikasi gagal pada sistem operasi nanti.

Pusing

Lapisan verifikasi Concurrency Fuzzing (Cuzz) mendeteksi bug konkurensi dan kondisi perlombaan data. Cuzz menyesuaikan penjadwalan utas dengan menyuntikkan penundaan acak pada titik kunci dalam kode aplikasi. Skenario berikut menggambarkan jenis bug konkurensi yang dapat dideteksi oleh lapisan verifikasi Cuzz.

Aplikasi memiliki utas induk dan utas anak. Utas induk memulai utas anak dan kemudian mengalokasikan memori untuk struktur.

// Parent Thread
StartChildThread(...);
g_pointer = ... malloc(...);

Utas anak mendereferensikan penunjuk.

//Child Thread
LONG value = g_pointer->someMember;

Kode sebelumnya memiliki bug konkurensi. Jika utas turunan mencoba untuk mendereferensikan penunjuk sebelum utas induk mengalokasikan memori, penunjuk akan tidak valid. Bug sangat tidak mungkin memanifestasikan dirinya sendiri, karena dalam banyak kasus, utas induk akan mengalokasikan memori sebelum utas anak dimulai. Tetapi dalam kasus yang jarang terjadi, utas anak dapat memulai dan mencoba mendereferensikan penunjuk sebelum utas induk telah mengalokasikan memori.

Lapisan verifikasi Cuzz meningkatkan kemungkinan menemukan bug konkurensi seperti yang diilustrasikan dalam contoh sebelumnya. Cuzz tidak melakukan pemeriksaan tambahan selain menyisipkan penundaan. Dengan demikian, tidak ada pemberhentian verifikasi yang terkait langsung dengan Cuzz. Namun, jika mengaktifkan Cuzz menghasilkan bug konkurensi yang memanifestasikan dirinya sendiri, lapisan verifikasi lainnya akan mendapat manfaat. Misalnya, jika kondisi balapan menghasilkan luapan timbunan, lapisan verifikasi Heaps tidak akan menemukan kesalahan kecuali kondisi balapan memanifestasikan dirinya pada run time. Dengan meningkatkan probabilitas kondisi balapan yang terjadi, Cuzz meningkatkan efektivitas lapisan Heaps dalam mengidentifikasi kesalahan.

Untuk mendapatkan manfaat maksimum Cuzz, aktifkan Cuzz pada tes sebanyak mungkin, dan ulangi pengujian yang sama berkali-kali. Cuzz dapat diaktifkan pada semua pengujian, termasuk pengujian manual, tes fungsional, dan tes stres. Selain itu, aktifkan lapisan verifikasi Pemverifikasi Aplikasi sebanyak mungkin.

Anda dapat meningkatkan probabilitas mereproduksi bug dengan menyediakan Cuzz dengan benih acak yang sama (lihat Properti).

Cuzz menyisipkan penundaan hanya pada panggilan API sinkronisasi Win32.

Properti Cuzz

Properti berikut tersedia untuk lapisan verifikasi Cuzz. Untuk mengatur properti, pilih lapisan Cuzz di antarmuka pengguna Pemverifikasi Aplikasi, dan buka Jendela Properti.

Properti	Deskripsi
FuzzingLevel	Mengontrol tingkat fuzzing untuk Cuzz. Atur ini ke 1 untuk aplikasi penting waktu dan 4 untuk aplikasi reguler.
AcakSeed	Benih acak yang digunakan oleh Cuzz pada awalnya. Jika Anda mengatur ini ke 0, Cuzz menghasilkan benih acak berbasis waktu.

Simulasi Sumber Daya Rendah

Simulasi sumber daya rendah mencoba mensimulasikan lingkungan di bawah sumber daya rendah, seperti kehabisan memori. Simulasi ini akan mengidentifikasi bug yang terjadi dalam kondisi memori rendah. Ini juga disebut sebagai Injeksi Kesalahan. Anda dapat mensimulasikan lingkungan di bawah sumber daya rendah, di mana Anda dapat menentukan angka (0–100) yang menunjukkan panggilan probabilitas kesalahan:

Tunggu (misalnya. API WaitForXXXX).
Heap_Alloc (API Alokasi Timbunan).
Virtual_Alloc (API alokasi Memori Virtual).
Registri (Registry API).
File (FILE API seperti CreateFile).
Peristiwa (API Peristiwa seperti CreateEvent).
MapView ( MapView API seperti CreateMapView).
Ole_Alloc (Ole API seperti SysAllocString).

Simulasi sumber daya rendah (juga dikenal sebagai injeksi kesalahan) mencoba mensimulasikan lingkungan di bawah sumber daya rendah, misalnya kehabisan memori. Ini akan mengidentifikasi bug dalam kondisi memori rendah.

Properti Simulasi Sumber Daya Rendah

Untuk mengedit properti, centang kotak Simulasi Sumber Daya Rendah di area Pengujian, klik kanan, dan pilih properti:

Properti	Deskripsi
Memasukkan	Kesalahan batas hanya terjadi di dll yang ditentukan. Satu nama dll tanpa jalur per baris. Jika '*' ditentukan, kesalahan akan terjadi untuk semua modul.
Mengecualikan	Kecualikan kesalahan untuk modul yang ditentukan. Satu nama dll tanpa jalur per baris.
Waktu habis	Berikan slot waktu (dalam milidetik) ketika tidak ada kesalahan pada inisialisasi proses.
Tunggu	Angka [0 – 1000000] yang menunjukkan probabilitas kesalahan untuk API WaitForXXXX.
Heap_Alloc	Angka [0 – 1000000] yang menunjukkan probabilitas kesalahan untuk API Alokasi Heap.
Virtual_Alloc	Angka [0 – 1000000] yang menunjukkan probabilitas kesalahan untuk API alokasi Memori Virtual.
Registri	Angka [0 – 1000000] yang menunjukkan probabilitas kesalahan untuk API Registri.
File	Angka [0 – 1000000] yang menunjukkan probabilitas kesalahan untuk API File seperti CreateFile.
Kejadian	Angka [0 – 1000000] yang menunjukkan probabilitas kesalahan untuk API Peristiwa seperti CreateEvent
MapView	Angka [0 – 1000000] yang menunjukkan probabilitas kesalahan untuk MAPView API seperti CreateMapView.
Ole_Alloc	Angka [0 – 1000000] yang menunjukkan probabilitas kesalahan untuk Ole API seperti SysAllocString.
Tumpukan	Setiap utas aplikasi Windows dimulai dengan cadangan tumpukan dan ukuran penerapan tumpukan. Di bawah penggunaan normal, penerapan tumpukan tumbuh setiap kali ada kebutuhan untuk lebih banyak ruang pada tumpukan. Lihat Membuat Utas dan Ukuran Tumpukan Utas untuk informasi selengkapnya. Jika sistem mengalami kondisi memori yang rendah, pertumbuhan penerapan tumpukan mungkin gagal. Utas yang gagal menumbuhkan tumpukannya dan seluruh aplikasi kemungkinan besar akan mengalami crash. Crash semacam itu tidak dapat diterima untuk proses sistem penting (misalnya untuk layanan). Pemeriksaan Tumpukan akan menonaktifkan pertumbuhan tumpukan untuk aplikasi yang sedang diverifikasi sehingga akan mensimulasikan kegagalan pertumbuhan tumpukan tanpa perlu mensimulasikan seluruh kondisi memori rendah sistem. Pengecualian akan dilemparkan ketika aplikasi mencoba memperluas tumpukan. Tidak ada perhentian pemverifikasi yang dihasilkan oleh ini.

LuaPriv

Pengujian Limited User Account Privilege Predictor (LuaPriv) adalah Prediktif dan diagnostik dan bekerja untuk memunculkan masalah yang terkait dengan menjalankan aplikasi dengan hak istimewa administratif, dan apakah aplikasi tersebut juga akan berfungsi jika dijalankan dengan hak istimewa yang lebih sedikit (umumnya, sebagai pengguna normal).

Juga dikenal sebagai pemeriksaan UAC, Prediksi Hak Istimewa Akun Pengguna Terbatas (LuaPriv) memiliki dua tujuan utama:

Prediktif: Saat menjalankan aplikasi dengan hak istimewa administratif, prediksi apakah aplikasi tersebut juga akan berfungsi jika dijalankan dengan lebih sedikit hak istimewa (umumnya, sebagai pengguna normal). Misalnya, jika aplikasi menulis ke file yang hanya mengizinkan akses Administrator, aplikasi tersebut tidak akan dapat menulis ke file yang sama jika dijalankan sebagai non-administrator.
Diagnostik: Saat berjalan dengan hak istimewa non-administrator, identifikasi potensi masalah yang mungkin sudah ada dengan eksekusi saat ini. Melanjutkan contoh sebelumnya, jika aplikasi mencoba menulis ke file yang hanya memberikan akses anggota grup Administrator, aplikasi akan mendapatkan kesalahan ACCESS_DENIED. Jika aplikasi tidak beroperasi dengan benar, operasi ini mungkin pelakunya.

LuaPriv mengidentifikasi jenis masalah berikut:

Potensi Masalah	Keterangan
Namespace Terbatas	Membuat objek sinkronisasi bernama (Peristiwa, Semaphore, Mutex, dll) tanpa namespace mungkin rumit berjalan tanpa hak istimewa pada beberapa sistem operasi karena sistem operasi dapat memilih untuk menempatkan objek di namespace terbatas. Membuat objek seperti itu di namespace terbatas (seperti namespace layanan Global) memerlukan SeCreateGlobalPrivilege, yang hanya diberikan kepada administrator. LuaPriv menandai kedua masalah ini jika mendeteksinya.
Pemeriksaan Administrator Keras	Beberapa aplikasi menginterogasi token keamanan pengguna untuk mengetahui berapa banyak hak istimewa yang dimilikinya. Dalam kasus tersebut, aplikasi dapat mengubah perilakunya tergantung pada seberapa besar daya yang dipikirkan pengguna. LuaPriv menandai panggilan API yang mengembalikan informasi ini.
Meminta Hak Istimewa	Aplikasi dapat mencoba mengaktifkan hak istimewa yang relevan dengan keamanan (seperti SeTcbPrivilege atau SeSecurityPrivilege) sebelum melakukan operasi yang memerlukannya. Bendera LuaPriv mencoba mengaktifkan hak istimewa yang relevan dengan keamanan.
Hak Istimewa Hilang	Jika aplikasi mencoba mengaktifkan hak istimewa yang tidak dimiliki pengguna, aplikasi mungkin memberi sinyal bahwa aplikasi mengharapkan hak istimewa, yang dapat menyebabkan perbedaan perilaku. Bendera LuaPriv gagal meminta hak istimewa.
Operasi INI-File	Upaya untuk menulis ke file INI yang dipetakan (WritePrivateProfileSection dan API serupa) dapat gagal sebagai pengguna non-administrator. LuaPriv menandai operasi tersebut.
Akses Ditolak	Jika aplikasi mencoba mengakses objek (File, kunci registri, dll) tetapi upaya gagal karena akses yang tidak memadai, aplikasi mungkin mengharapkan untuk berjalan dengan lebih banyak hak istimewa daripada yang dimilikinya. LuaPriv menandai upaya buka objek yang gagal dengan ACCESS_DENIED dan kesalahan serupa.
Tolak ACE	Jika objek memiliki Tolak ACE dalam DACL-nya, maka objek secara eksplisit menolak akses ke entitas tertentu. Ini jarang terjadi, dan membuat prediksi sulit, jadi LuaPriv menandai Tolak ACE ketika menemukannya.
Akses Dibatasi	Jika aplikasi mencoba membuka objek untuk hak yang tidak diberikan kepada pengguna normal (misalnya, mencoba menulis ke file yang hanya dapat ditulis oleh administrator), aplikasi mungkin tidak akan berfungsi sama ketika dijalankan sebagai pengguna normal. LuaPriv menandai operasi tersebut.
MAXIMUM_ALLOWED	Jika aplikasi membuka objek untuk MAXIMUM_ALLOWED, maka pemeriksaan akses aktual pada objek akan terjadi di tempat lain. Sebagian besar kode yang melakukan ini tidak berfungsi dengan benar, dan hampir pasti akan bekerja secara berbeda ketika dijalankan tanpa hak istimewa. LuaPriv dengan demikian menandai semua insiden MAXIMUM_ALLOWED.

Lain-lain

Masalah umum yang diabaikan diambil dalam tes Lain-lain.

API Berbahaya — Melacak untuk melihat apakah aplikasi menggunakan tindakan tidak aman berikut:
- Panggilan berbahaya untuk TerminateThread.
- Potensi luapan tumpukan dalam kondisi memori rendah.
- Proses keluar yang dipanggil saat beberapa utas masih berjalan.
- LoadLibrary dipanggil selama DllMain.
- FreeLibrary dipanggil selama DllMain.
Tumpukan Kotor mengisi (secara berkala) bagian tumpukan yang tidak digunakan dengan pola memori. Ini dapat membantu mendeteksi variabel yang tidak diinisialisasi dalam panggilan fungsi di masa mendatang dalam konteks utas tersebut.
TimeRollOver memaksa API GetTickCount dan TimeGetTime untuk bergulir lebih cepat dari biasanya. Ini memungkinkan aplikasi untuk menguji penanganan rollover waktu mereka dengan lebih mudah.

Properti Lain-lain

Pemeriksaan API berbahaya memiliki satu properti yang dapat diubah:

DllMainCheck - Periksa panggilan LoadLibrary/FreeLibrary saat DllMain aktif.

Jaringan

Pengujian jaringan mencari penggunaan API WinSock yang tidak tepat. Misalnya, jika API Jaringan dipanggil sebelum WSAStartup() yang berhasil atau setelah panggilan WSACleanup() yang berhasil diseimbangkan dilakukan. Untuk informasi selengkapnya tentang WinSock, lihat header winsock.h dan Windows Sockets 2.

Properti

Properti berikut ini tersedia untuk lapisan verifikasi Net. Untuk mengatur properti, pilih penyedia Jaringan di antarmuka pengguna Pemverifikasi Aplikasi, dan buka Jendela Properti.

Properti	Deskripsi
FragmentsEnabled	Memungkinkan fragmentasi aliran data yang diterima oleh soket TCP IPv4 dan IPv6.
FragmentSize	Menentukan jumlah maksimum byte yang dikembalikan ke buffer ke panggilan API penerima Winsock.

Properti FragmentsEnabled memungkinkan fungsionalitas di penyedia pemverifikasi Jaringan untuk memfasilitasi pengujian dan verifikasi aplikasi yang mengurai aliran TCP dari jaringan. Setelah diaktifkan, semua panggilan ke Winsock untuk menerima data hanya akan menerima hingga FragmentSize byte kecuali aplikasi secara khusus memerlukan seluruh buffer yang diisi sebelum kembali (dikontrol oleh bendera MSG_WAITALL). Karena baik protokol TCP maupun Winsock tidak memberikan jaminan apa pun tentang jumlah byte yang mungkin dikembalikan ke dalam buffer, memungkinkan pemeriksaan ini akan memfasilitasi verifikasi bahwa kode yang mengurai aliran data dari jaringan melakukannya dengan benar, secara independen dari jumlah byte yang diterima per panggilan ke Winsock. Masalah dalam pengurai aliran telah menjadi sumber bug profil tinggi, dan properti ini disediakan untuk memudahkan verifikasi kebenaran, karena ini sangat sulit untuk diuji. Catatan: Ini tidak mengubah data yang dikembalikan - hanya memperlambatnya pada tingkat tertentu: aplikasi harus ber perilaku yang sama persis dengan yang diaktifkan atau dinonaktifkan ini.

Baris perintah berikut memungkinkan fragmentasi semua aliran TCP masuk ke semua soket TCP IPv4 dan IPv6 yang dibuat dalam myApp.exe dan semua biner yang dimuat oleh myApp.exe.

appverif -enable Networking -for myApp.exe -with Networking.FragmentsEnabled=True Networking.FragmentSize=10

!avrf Debugger Extension

!avrf -net -socket count - menampilkan jumlah handel soket terbuka dan tertutup

!avrf -net -socket dump [-v] [HANDLE] - menampilkan handel soket, verbosely atau tidak.

!avrf -net -wsastacks - menampilkan jumlah init WSA saat ini dan daftar kronologis jejak tumpukan untuk WSAStartup/WSACleanup.

!avrf -net -wsastacks count - menampilkan jumlah init WSA saat ini.

!avrf -net -socket count - Perintah ini akan memberikan jumlah keseluruhan handel soket yang sedang dilacak, baik yang dibuka maupun ditutup. Perhatikan bahwa ini dilacak dalam antrean melingkar, sehingga ada langit-langit hingga total yang dilacak. Soket ditambahkan ke daftar yang dibuka ketika salah satu API Winsock yang mengalokasikan handel soket dipanggil. Misalnya, socket(), WSASocket(), accept(). Soket dipindahkan dari daftar yang dibuka ke daftar tertutup ketika fungsi closesocket() dipanggil pada handel soket tersebut.

!avrf -net -socket dump [-v] [HANDLE] - Perintah ini akan menghitung handel soket. "-socket dump" akan mencantumkan semua handel soket terbuka dan tertutup yang dilacak oleh nilai SOCKET mereka. Bendera -v opsional juga akan mencetak tumpukan panggilan terbuka atau tutup segera setelah mencetak setiap nilai SOCKET. Bidang HANDLE opsional hanya akan mencantumkan handel SOCKET yang ditentukan dan tumpukan panggilan terbuka atau tutupnya.

Berikut adalah contoh berbagai opsi penggunaan -soket:

0:008> !avrf -net -socket count
Number of open socket handles   = 16
Number of closed socket handles = 12
 
0:008> !avrf -net -socket dump
CLOSED SOCKET HANDLE - 0x47c
CLOSED SOCKET HANDLE - 0x2cc
CLOSED SOCKET HANDLE - 0x8c4
CLOSED SOCKET HANDLE - 0x6bc
CLOSED SOCKET HANDLE - 0x44c
CLOSED SOCKET HANDLE - 0x578
CLOSED SOCKET HANDLE - 0x6f4
CLOSED SOCKET HANDLE - 0x5b4
CLOSED SOCKET HANDLE - 0x4d8
CLOSED SOCKET HANDLE - 0x3cc
CLOSED SOCKET HANDLE - 0x4fc
CLOSED SOCKET HANDLE - 0x4e0
OPEN SOCKET HANDLE - 0xfd4
OPEN SOCKET HANDLE - 0x7d8
OPEN SOCKET HANDLE - 0xf8c
OPEN SOCKET HANDLE - 0xf88
OPEN SOCKET HANDLE - 0xae0
OPEN SOCKET HANDLE - 0xe58
OPEN SOCKET HANDLE - 0xdfc
OPEN SOCKET HANDLE - 0xcf8
OPEN SOCKET HANDLE - 0xa18
OPEN SOCKET HANDLE - 0x7a0
OPEN SOCKET HANDLE - 0x7b0
OPEN SOCKET HANDLE - 0x534
OPEN SOCKET HANDLE - 0xcdc
OPEN SOCKET HANDLE - 0x1f0
OPEN SOCKET HANDLE - 0x444
OPEN SOCKET HANDLE - 0x8bc
 
0:008> !avrf -net -socket dump -v 0x47c
 
The socket handle is closed
 
vfNet!VfHookclosesocket
WININET!ICSocket::_UnSafeCloseSocket
WININET!ICSocket::Dereference
WININET!CFsm_GetConnection::RunSM
WININET!CFsm::Run
WININET!DoFsm
WININET!HTTP_REQUEST_HANDLE_OBJECT::OpenConnection_Fsm
WININET!CFsm_OpenConnection::RunSM
WININET!CFsm::Run
WININET!DoFsm
WININET!HTTP_REQUEST_HANDLE_OBJECT::OpenConnection
WININET!HTTP_REQUEST_HANDLE_OBJECT::MakeConnection_Fsm
WININET!CFsm_MakeConnection::RunSM
WININET!CFsm::Run
WININET!DoFsm
WININET!HTTP_REQUEST_HANDLE_OBJECT::SendRequest_Fsm
WININET!CFsm_SendRequest::RunSM
WININET!CFsm::Run
WININET!DoFsm
WININET!HTTP_REQUEST_HANDLE_OBJECT::HttpSendRequest_Start
WININET!CFsm_HttpSendRequest::RunSM
WININET!CFsm::Run
WININET!CFsm::RunWorkItem
SHLWAPI!ExecuteWorkItemThreadProc
vfbasics!AVrfpRtlWorkerCallback
ntdll!RtlpTpWorkCallback
ntdll!TppWorkerThread
kernel32!BaseThreadInitThunk
ntdll!__RtlUserThreadStart
ntdll!_RtlUserThreadStart

!avrf -net -wsastacks [count]

Winsock mengharuskan pengembang aplikasi untuk memanggil WSAStartup() setidaknya sekali sebelum melakukan panggilan Winsock. Ini dilacak oleh winsock di seluruh proses. Jumlah referensi awal menginstruksikan pustaka Winsock (ws2_32.dll) untuk menginisialisasi dan memuat katalog dan penyedia Winsock. Panggilan lebih lanjut ke kenaikan WSAStartup jumlah referensi tersebut. Winsock juga mengharuskan pengembang aplikasi untuk memanggil WSACleanup() ketika mereka telah 'selesai'memanggil ke Winsock. Panggilan ke WSACleanup harus dipasangkan dengan benar dengan panggilan sebelumnya ke WSAStartup(). Panggilan ke WSACleanup() mengurangi jumlah referensi di seluruh proses. Ketika jumlah referensi jatuh ke nol, Winsock merilis sumber dayanya dan membongkar katalog dan penyedia Winsock.

Perintah ini akan memberikan nilai jumlah referensi keseluruhan dari rutinitas inisialisasi "WSAStartup" saat ini dan mencantumkan tumpukan panggilan untuk panggilan ke WSAStartup dan WSACleanup yang dibuat dalam proses. Perhatikan bahwa ini dipertahankan dalam antrean melingkar tetap, sehingga tidak dijamin selesai - hanya panggilan N terbaru.

Berikut adalah contoh berbagai opsi penggunaan -wsastacks:

0:008> !avrf -net -wsastacks count
 
Current WSARefCount: 1 (WSAStartup call count minus WSACleanup call count for the target process)
 
 
0:008> !avrf -net -wsastacks
 
Current WSARefCount: 1 (WSAStartup call count minus WSACleanup call count for the target process)
 
 
THREAD ID: 0xe4c called WSAStartup
vfNet!WSAInitStacks<NetAllocatorViaPrivateHeap>::AddWSAStackTrace
vfNet!VfHookWSAStartup
WININET!LoadWinsock
WININET!GlobalDataInitialize
WININET!InternetSetOptionA
WININET!InternetSetOptionW
IEFRAME!LCIEUpdateSessionStartTime
IEFRAME!LCIETab_ThreadProc
iertutil!_IsoThreadProc
vfbasics!AVrfpStandardThreadFunction
kernel32!BaseThreadInitThunk
ntdll!__RtlUserThreadStart
ntdll!_RtlUserThreadStart

NTLM

Plug-in Pemverifikasi Aplikasi ini memantau panggilan proses individual ke API autentikasi AcquireCredentialsHandle dan InitializeSecurityContext untuk mendeteksi penggunaan protokol NTLM. NTLM adalah protokol autentikasi yang kedaluarsa dengan kelemahan yang berpotensi membahayakan keamanan aplikasi dan sistem operasi dan tidak boleh digunakan.

Risiko Autentikasi NTLM

Protokol autentikasi NTLM yang ketinggalan jaman yang paling penting adalah kurangnya autentikasi server, yang dapat memungkinkan penyerang untuk mengelabui pengguna agar terhubung ke server spoofed. Sebagai koroller autentikasi server yang hilang, aplikasi yang menggunakan NTLM juga dapat rentan terhadap jenis serangan yang dikenal sebagai serangan "refleksi". Yang terakhir ini memungkinkan penyerang untuk membajak percakapan autentikasi pengguna ke server yang sah dan menggunakannya untuk mengautentikasi penyerang ke komputer pengguna. Kerentanan dan cara NTLM untuk mengeksploitasinya adalah target peningkatan aktivitas penelitian di komunitas keamanan.

Meskipun Kerberos telah tersedia selama bertahun-tahun, banyak aplikasi masih ditulis untuk menggunakan NTLM saja. Ini tidak perlu mengurangi keamanan aplikasi. Namun Kerberos tidak dapat menggantikan NTLM dalam semua skenario - terutama yang mana klien perlu mengautentikasi ke sistem yang tidak bergabung ke domain (jaringan rumah mungkin yang paling umum dari ini). Paket keamanan Negosiasi memungkinkan kompromi yang kompatibel mundur yang menggunakan Kerberos jika memungkinkan dan hanya kembali ke NTLM ketika tidak ada opsi lain. Mengalihkan kode untuk menggunakan Negosiasi alih-alih NTLM akan secara signifikan meningkatkan keamanan bagi pelanggan kami sambil memperkenalkan beberapa atau tidak ada kompatibilitas aplikasi. Negosiasi dengan sendirinya bukan peluru perak - ada kasus di mana penyerang dapat memaksa penurunan ke NTLM tetapi ini secara signifikan lebih sulit untuk dieksploitasi. Namun, salah satu peningkatan langsung adalah bahwa aplikasi yang ditulis untuk menggunakan Negosiasi dengan benar secara otomatis kebal terhadap serangan refleksi NTLM.

Dengan kata terakhir hati-hati terhadap penggunaan NTLM: Di Windows dimungkinkan untuk menonaktifkan penggunaan NTLM pada tingkat sistem operasi. Jika aplikasi memiliki dependensi keras pada NTLM, aplikasi tersebut hanya akan gagal mengautentikasi ketika NTLM dinonaktifkan.

Faktor apa yang menyebabkan NTLM "dikodekan secara permanen" dalam aplikasi?

Ada dua faktor yang akan menyebabkan dependensi keras pada NTLM. Yang pertama secara eksplisit memilih NTLM sebagai paket autentikasi yang akan digunakan oleh aplikasi. Untuk beberapa protokol dan API, pilihan NTLM sudah jelas, seperti dalam panggilan ke API AcquireCredentialsHandle (). Untuk protokol lain, mungkin tidak begitu jelas. Misalnya, paket autentikasi default RPC (RPC_C_AUTHN_DEFAULT) sebenarnya adalah alias untuk NTLM ketika RPC digunakan melalui jaringan dan bahkan bendera eksplisit untuk memilih NTLM tidak memiliki singkatan NTLM di mana pun di dalamnya (RPC_C_AUTH_WINNT). Konstruksi semacam ini membuatnya lebih mudah untuk memilih NTLM tanpa harus mengetahui bahwa Anda telah melakukannya.

Sebagai ganti NTLM, pengembang harus menggunakan, metode autentikasi lainnya, misalnya paket Negosiasi (ini juga kadang-kadang disebut sebagai paket SPNEGO atau SNEGO). Pemilihan paket perlu cocok pada komponen klien dan server agar Negosiasi dapat mencoba menggunakan Kerberos - sehingga bagian klien dan server aplikasi perlu menggunakan Negosiasi. Jika salah satu sisi menggunakan NTLM (seperti yang mungkin terjadi dengan versi warisan) Negosiasi akan tetap berfungsi tetapi akan selalu kembali ke NTLM. Cara memberi tahu aplikasi Anda untuk menggunakan Negosiasi bervariasi menurut protokol. Beberapa protokol paling umum (RPC, LDAP, DCOM, HTTP) dibahas secara rinci nanti dalam topik 5000 - Aplikasi Telah Secara Eksplisit Memilih Paket NTLM.

Faktor kedua yang menyebabkan NTLM digunakan adalah ketika klien tidak memberikan nama target server yang valid ke proses autentikasi. Dalam protokol yang mendukung atau memerlukan autentikasi bersama (seperti Kerberos) nama target adalah apa yang digunakan untuk mencapai autentikasi bersama. API Autentikasi (seperti InitializeSecurityContext) mengambil parameter opsional, biasanya disebut sesuatu seperti "TargetName", "PrincipalName" atau "ServerPrincipalName". Ini adalah pengidentifikasi yang digunakan oleh pengendali domain untuk memilih akun domain yang benar untuk mendapatkan kredensial untuk layanan target. Karena NTLM tidak memiliki konsep autentikasi server, parameter ini tidak diperlukan agar NTLM berhasil mengautentikasi. Di sisi lain, Kerberos mengharuskan klien mendapatkan tiket layanan yang berlaku untuk layanan yang diautentikasi klien. Autentikasi Kerberos akan selalu gagal jika tidak ada nama target atau nama target yang tidak valid yang ditentukan. Ketika Negosiasi dipilih sebagai paket, tidak menyediakan nama target (atau nama target yang tidak valid) akan menyebabkan Kerberos dilewati sama sekali dan NTLM digunakan. Sebagian besar API autentikasi memiliki nama target sebagai parameter opsional akan menerima jika NULL tanpa kesalahan. Kecuali pengembang mengambil alih ini dan memberikan nama target eksplisit, NTLM, (dan selain itu, NTLM yang dapat dicerminkan) adalah hasilnya.

Cara Kerja Plug-in NTLM

Steker Pemverifikasi mendeteksi kesalahan berikut:

Paket NTLM secara langsung ditentukan dalam panggilan ke AcquireCredentialsHandle (atau API pembungkus tingkat yang lebih tinggi).
Nama target dalam panggilan ke InitializeSecurityContext adalah NULL. Dalam hal ini, Negosiasi kembali ke NTLM secara langsung.
Nama target dalam panggilan ke InitializeSecurityContext bukan nama domain bergaya SPN, UPN, atau NetBIOS yang dibentuk dengan benar. Dalam hal ini, pengendali domain mengembalikan kesalahan "utama tidak ditemukan", yang menyebabkan Negosiasi mundur ke NTLM.

Plug-in juga mencatat peringatan ketika mendeteksi penurunan ke NTLM; misalnya, ketika SPN tidak ditemukan oleh Pengendali Domain. Ini hanya dicatat sebagai peringatan karena sering kali merupakan kasus yang sah - misalnya, saat mengautentikasi ke sistem yang tidak bergabung dengan domain.

Mengonfigurasi Opsi Henti Plug-in

Secara default semua peristiwa yang dikategorikan sebagai Kesalahan diatur untuk menyebabkan kerusakan debug. Semua peristiwa peringatan diatur untuk mencatat detail peristiwa saja.

Peristiwa Kesalahan menyebabkan Stop/Break:

5000 – Aplikasi telah secara eksplisit memilih paket NTLM
5001 – Daftar Paket Negosiasi Hanya Mencakup NTLM
5002 – Daftar Paket Negosiasi Pengecualian NTLM Salah
5003 – Tidak ada nama target atau nama target yang salah bentuk untuk Server

Peristiwa Peringatan dicatat:

5010 – Turun tingkat ke NTLM Terdeteksi

NTLM Berhenti

5000 – Aplikasi telah secara eksplisit memilih paket NTLM

Tingkat keparahan – Kesalahan

Aplikasi atau subsistem secara eksplisit memilih NTLM alih-alih Bernegosiasi dalam panggilan ke AcquireCredentialsHandle. Meskipun mungkin bagi klien dan server untuk mengautentikasi menggunakan Kerberos ini dicegah oleh pemilihan eksplisit NTLM.

Cara Memperbaiki Kesalahan ini

Perbaikan untuk kesalahan ini adalah memilih paket Negosiasi sebagai pengganti NTLM. Bagaimana hal ini dilakukan akan bergantung pada subsistem Jaringan tertentu yang digunakan oleh klien atau server. Beberapa contoh ditunjukkan di bawah ini. Anda harus berkonsultasi dengan dokumentasi tentang pustaka atau set API tertentu yang Anda gunakan.

API(parameter) Digunakan oleh Aplikasi	Nilai Salah	Nilai yang Benar	Catatan
AcquireCredentialsHandle (pszPackage)	"NTLM"	NEGOSSP_NAME atau "Negosiasi"
Klien RPC: RPCBindingSetAuthInfoEx RPCBindingSetAuthInfoEx (AuthnSv) RPC Server: RPCServerRegisterAuthInfo(AuthnSvc)	RPC_C_AUTHN_WINNT atau RPC_C_AUTH_DEFAULT	RPC_C_AUTH_GSS_NEGOTIATE	Ini bukan kesalahan bagi server RPC untuk mendaftarkan paket NTLM/WINNT. Ini sering diperlukan untuk mendukung klien lama yang hanya mendukung NTLM. Ini adalah kesalahan jika hanya paket NTLM yang terdaftar karena ini memaksa semua klien untuk menggunakan NTLM bahkan jika mereka mampu menggunakan Kerberos.
DCOM: SetBlanket CoSetProxyBlanket (dwAuthnSvc) CoCreateInstanceEx (diteruskan sebagai anggota dwAuthnSvc dari struktur COAUTHINFO, yang merupakan anggota struktur COSERVERINFO yang diteruskan ke API)	RPC_C_AUTHN_WINNT	RPC_C_AUTHN_DEFAULT atau RPC_C_AUTHN_GSS_NEGOTIATE	Negosiasi hanya boleh digunakan jika komunikasi selalu terjadi di seluruh jaringan. Jika panggilan DCOM pernah terjadi antara klien dan server pada komputer yang sama, Anda harus menggunakan DEFAULT dan mengizinkan DCOM untuk memilih paket yang benar untuk digunakan.
LDAP: ldap_bind_s (metode)	LDAP_AUTH_NTLM	LDAP_AUTH_NEGOTIATE
HTTP WinHTTPSetCredentials (AuthScheme)	WINHTTP_AUTH_SCHEME_NTLM	WINHTTP_AUTH_SCHEME_NEGOTIATE

5001 – Daftar Paket Negosiasi Hanya Mencakup NTLM

Tingkat keparahan – Kesalahan

Saat menggunakan AcquireCredentialsHandle dimungkinkan untuk menyediakan daftar paket yang akan digunakan atau diabaikan oleh Negosiasi. Bergantung pada daftar yang ditentukan, ini dapat mengambil alih logika yang disertakan dalam Negosiasi untuk memilih paket autentikasi yang paling tepat dan aman. Jika daftar paket hanya menyertakan NTLM atau mengecualikan Kerberos hasilnya identik dengan melewati Negosiasi sama sekali dan secara eksplisit memilih paket SSP NTLM secara langsung.

Menentukan daftar sub-paket hanya dimungkinkan saat memanggil AcquireCredentialsHandle secara langsung karena sebagian besar API lapisan yang lebih tinggi (seperti RPC) tidak mengizinkan pemanggil mengontrol daftar paket Negosiasi.

Microsoft tidak menyarankan agar aplikasi mencoba memanipulasi daftar paket Negosiasi dengan cara ini.

Cara Memperbaiki Kesalahan ini

Gunakan paket Negosiasi tanpa menentukan daftar subpaket atau pastikan bahwa Kerberos disertakan.

API(parameter) Digunakan oleh Aplikasi	Nilai Salah	Nilai yang Benar
AcquireCredentialsHandle (anggota PackageList dari struct SEC_WINNT_AUTH_IDENTITY_EX diteruskan sebagai parameter pAuthData)	“! Kerberos" atau "NTLM"	NULL atau "Kerberos, NTLM" atau "Kerberos, ! NTLM" atau "! NTLM"

5002 – Daftar Paket Negosiasi Pengecualian NTLM Salah

Tingkat keparahan - Peringatan

Saat memanggil AcquireCredentialsHandle, aplikasi telah mencoba mengecualikan NTLM dari daftar paket yang didukung oleh Negosiasi. Namun, sintaks yang salah telah digunakan untuk mengecualikan NTLM, sehingga tetap dalam daftar.

Cara Memperbaiki Kesalahan ini Gunakan sintaks berikut untuk mengecualikan paket NTLM dari Negosiasi:

API(parameter) Digunakan oleh Aplikasi	Nilai Salah	Nilai yang Benar
AcquireCredentialsHandle (anggota PackageList dari struct SEC_WINNT_AUTH_IDENTITY_EX diteruskan sebagai parameter pAuthData)	"-NTLM"	“! NTLM"

5003 – Tidak ada nama target atau nama target yang salah bentuk untuk Server

Tingkat keparahan – Kesalahan

Saat menggunakan paket Negosiasi, menyediakan nama target null atau tidak valid (terkadang disebut sebagai nama utama) akan menyebabkan Kerberos gagal dan NTLM digunakan di tempatnya. Anda harus selalu menentukan nama target yang valid saat melakukan panggilan autentikasi. Nama target adalah pengidentifikasi unik yang memungkinkan pengontrol domain untuk mendapatkan detail akun server yang coba diautentikasi oleh aplikasi Anda. Setelah pengendali domain memiliki informasi ini, ia dapat membangun tiket Kerberos yang sesuai yang akan dipahami (dapat didekripsi) oleh klien dan server.

Cara Memperbaiki Kesalahan ini

Nama target dapat ditentukan dalam tiga format berbeda, yang masing-masing dapat digunakan oleh pengendali domain untuk menemukan objek akun server yang benar. Format ini adalah Nama Prinsipal Layanan (SPN), Nama Prinsipal Pengguna (UPN) dan nama domain\akun dua bagian NetBIOS. SPN adalah bentuk yang paling umum dan paling dapat dioperasikan dengan implementasi Kerberos lainnya. Diskusi lengkap SPN berada di luar cakupan dokumen ini tetapi bentuk SPN yang paling sederhana dan paling umum memiliki dua bagian - kelas layanan dan nama host. Kelas layanan mengidentifikasi jenis aplikasi server (misalnya jenis aplikasi tertentu seperti http atau ldap atau sebagai generik sebagai host). Bagian kedua adalah nama domain yang sepenuhnya memenuhi syarat atau nama datar (NetBIOS) server. Klien dan server Windows secara otomatis mendaftarkan SPN untuk "host" untuk FQDN dan nama datar. Pengendali domain juga akan memetakan sekitar 40 kelas layanan khusus aplikasi ke SPN "host" untuk hal-hal seperti "http", "ldap", "rpc", "tapi", dll.

o menentukan nama target untuk aplikasi yang berjalan dalam konteks sistem operasi server (misalnya localsystem, layanan jaringan atau localservice) aplikasi klien dapat menggunakan SPN "host" yang terdaftar secara otomatis atau salah satu aliasnya. Untuk mengautentikasi ke aplikasi yang berjalan dalam konteks akun pengguna domain, Anda harus mendaftarkan SPN untuk akun tersebut.

Untuk akun pengguna, Anda juga dapat menggunakan formulir UPN implisit yang dibangun dari nama akun pengguna dan domain tempat akun berada: useraccountname@domain.dom. Meskipun Anda dapat membuat UPN tambahan untuk akun pengguna (menggunakan akhiran UPN yang dapat dibuat untuk setiap domain) ini tidak akan berfungsi sebagai nama target Kerberos - hanya UPN yang sesuai dengan nama akun masuk aktual dan domain aktual tempat akun tinggal dapat digunakan.

Akhirnya Anda masih dapat menggunakan domain\username gaya NT4 (atau domain\computername dalam kasus layanan yang berjalan sebagai localsystem, networkservice, atau localservice). Ini berfungsi untuk target yang berjalan dalam konteks akun pengguna domain atau akun komputer.

API(parameter) Digunakan oleh Aplikasi	Parameter untuk mengatur nama target	Catatan
InitializeSecurityContext	pszTargetName
Klien RPC: RPCBindingSetAuthInfoEx RPCBindingSetAuthInfoEx (AuthnSv)	ServerPrincipalName	Ini harus menjadi nama target untuk akun tempat server/layanan berjalan. Ini tidak harus sama dengan nilai yang ditetapkan dalam RPCServerRegisterAuthInfo
DCOM: SetBlanket CoSetProxyBlanket (dwAuthnSvc) CoCreateInstanceEx (diteruskan sebagai anggota dwAuthnSvc dari struktur COAUTHINFO, yang merupakan anggota struktur COSERVERINFO yang diteruskan ke API)	pServerPrincName	Dapat menggunakan COLE_DEFAULT_PRINCIPAL untuk mengizinkan COM memilih nama secara otomatis dari informasi pengikatan
LDAP: tidak ada		Dibuat secara otomatis oleh klien LDAP.
HTTP tidak ada		WinHTTP dan WinInet menyediakan nama target dari nama server URL

5010 – Turun tingkat ke NTLM Terdeteksi

Tingkat keparahan - Peringatan

Meskipun aplikasi spesifik Bernegosiasi dan menggunakan nama target yang diformat dengan benar sesuatu terjadi untuk menyebabkan Negosiasi diturunkan ke NTLM. Tergantung pada keadaannya, ini dapat menunjukkan kesalahan atau perilaku yang diharapkan. Misalnya, ketika komputer bukan bagian dari domain atau digunakan di lokasi di mana pengontrol domain tidak dapat diakses, diharapkan bahwa Negosiasi akan diturunkan secara diam-diam untuk memungkinkan aplikasi mengautentikasi menggunakan NTLM. Namun, jika pemberhentian ini terjadi ketika pengontrol domain tersedia dan Anda biasanya mengharapkan Kerberos untuk digunakan hampir pasti menunjukkan bahwa ada sesuatu yang salah.

Cara Memperbaiki Kesalahan Ini

Dengan asumsi bahwa Anda telah menentukan bahwa Kerberos seharusnya digunakan dan bukan NTLM dalam keadaan ini, ada sejumlah kemungkinan mengapa penurunan tingkat terjadi:

• Nama target, meskipun mungkin telah dalam format yang benar, tidak ada di domain (atau forest).

o Anda harus memeriksa bahwa Anda membangun nama target yang benar di aplikasi klien. Apakah kelas layanan sudah benar? Apakah nama host sudah benar?

o Apakah proses server berjalan dalam konteks komputer atau akun domain lain. Dalam kasus sebelumnya SPN secara otomatis terdaftar, dalam kasus terakhir Anda mungkin harus mendaftarkan SPN atau menggunakan formulir alternatif seperti UPN implisit atau nama datar.

o Mungkin ada masalah konektivitas jaringan yang mencegah komunikasi dengan pengendali domain atau server DNS?

o Apakah SPN target terdaftar di lebih dari satu akun? Ini akan menyebabkan pengendali domain menolak upaya autentikasi padanya.

Pencetakan

Print Verifier membantu menemukan dan memecahkan masalah yang dapat mengakibatkan aplikasi memanggil subsistem cetak. Print Verifier menargetkan dua lapisan subsistem cetak, lapisan PrintAPI dan lapisan PrintDriver.

Cetak Lapisan API

Print Verifier menguji antarmuka antara program dan Winspool.drv dan prntvpt.dll dan menguji antarmuka DLL tersebut. Anda dapat meninjau aturan untuk memanggil fungsi di antarmuka ini di bagian bantuan MSDN untuk API yang diekspor oleh winspool.drv dan prntvpt.dll.

Cetak Lapisan Pengandar

Print Verifier juga menguji antarmuka antara driver cetak inti seperti UNIDRV.DLL, UNIDRUI.DLL, PSCRIPT5.DLL, PS5UI.DLL, atau MXDWDRV.DLL, dan plug-in driver cetak. Anda dapat menemukan informasi tentang antarmuka ini di MSDN dan WDK.

Biasanya, hanya versi debug yang menjalankan Pemverifikasi Aplikasi, sehingga performa umumnya bukan masalah. Jika masalah performa muncul dari penggunaan ini, atau pemeriksaan Pemverifikasi Aplikasi lainnya, jalankan satu pemeriksaan pada satu waktu hingga Anda melakukan semua pemeriksaan yang diperlukan.

Layanan Web

Lapisan Verifikasi Windows Webservices API (WWSAPI)

Plug-in WWSAPI memungkinkan pengembang untuk menangkap instans:

WWSAPI dipanggil yang mereferensikan objek WWSAPI intrinsik yang tidak valid.
WWSAPI dipanggil yang mereferensikan objek berulir tunggal yang sudah digunakan.
Objek intrinsik yang dibebaskan dengan panggilan asinkron tertunda.
Memanggil API pemblokiran dari utas pendek.

Selain itu, plug-in ini:

Melacak penggunaan objek dari instansiasi ke penghapusan.
Paksa panggilan yang dapat diselesaikan secara asinkron untuk diselesaikan secara sinkron. Hal ini untuk mencegah aplikasi tergantung pada perilaku tertentu dari panggilan yang mengambil WS_ASYNC_CONTEXT.
Memberikan deskripsi yang dapat dibaca manusia ketika API dilewatkan objek buruk, atau objek sedang digunakan menggunakan ekstensi debugger !avrf –ws –obj (ditunjukkan di bawah)
Untuk saluran, proksi layanan, dan host layanan, setiap panggilan yang dilacak akan menampilkan status objek saat ini.

Secara default, pemeriksa berikut diaktifkan:

Properti NameDescriptionValidateObjectValidates bahwa objek intrinsik validTrackObjectTracks penggunaan objek selama masa pakainya

Pemeriksa lain yang dapat diaktifkan di penyedia ini melalui UI properti adalah:

Properti NameDescriptionCheckTimeoutValidates bahwa fungsi asinkron diselesaikan dalam batas waktu, ditentukan sebagai TimeoutValForceSyncForce, jalur sinkronisasi yang akan diambil saat konteks WS_ASYNC_CONTEXT disediakan ke API.

Ekstensi debugger disediakan (!avrf –ws –obj) yang menampilkan objek WWSAPI intrinsik terbuka dan tertutup. Jika ekstensi ini diakhiri oleh objek, ekstensi ini akan menampilkan informasi verbose tentang penggunaan objek ini.

!avrf -ws –obj

Perintah ini menampilkan objek WWSAPI intrinsik yang sedang dilacak, baik yang dibuat maupun ditutup. Perhatikan bahwa objek tertutup disimpan dalam antrean melingkar, sehingga ada langit-langit ke jumlah total objek yang dilacak.

Objek ditambahkan ketika API berikut berhasil diselesaikan: WsCreateChannel(), WsCreateChannelForListener(), WsCreateServiceHost(), WsCreateServiceProxy(), WsCreateServiceProxyFromTemplate(), WsCreateError(), WsCreateHeap(), WsCreateHeap(), WsCreateateListener(), WsCreateMetadata(), WsCreateMessage(), WsCreateMessageForChannel(), WsCreateReader(), WsCreateWriter(), WsCreateXmlBuffer(), WsReadXmlBufferFromBytes()

Objek dipindahkan dari yang dibuat ke daftar yang dikosongkan ketika fungsi WsFree*() yang sesuai dipanggil dan selesai.

!avrf –ws –obj [OBJECT]

Perintah ini menampilkan penggunaan objek WWSAPI intrinsik. Informasi penggunaan mencakup tumpukan ketika objek dibuat, digunakan, dan dibeberkan. Jika objek adalah saluran, host layanan, atau proksi layanan, objek akan menampilkan status objek sebelum API menggunakan objek dipanggil.

Berikut adalah contoh opsi penggunaan !avrf –ws –obj:

0:001> !avrf -ws -obj
Objects dependent on internal objects allocated:


Objects currently allocated:

 0x00000000048566C0 (Type=Heap, Thread=0x000001bc, Pending Operations=0)
 0x0000000001BE6780 (Type=Error, Thread=0x000001bc, Pending Operations=0)
 0x0000000001C13580 (Type=Service Proxy, Thread=0x000001bc, Pending Operations=0)

Freed objects:

 0x0000000001C17170 (Type=Service Proxy, Thread=0x000001bc)
 0x0000000004856730 (Type=Heap, Thread=0x000001bc)
 0x0000000001BE6820 (Type=Error, Thread=0x000001bc)

0:001> !avrf -ws -obj 0x0000000001C13580

Object @ 0x0000000001C13580
        Type = Service Proxy
        Thread = 0x000001bc
        Internal Reference = 0x00000000026C5E80

Created stack:
  vfnws!VfHookWsCreateServiceProxy+0x00aa
  BLUESTONE!WST_WebServices::WsCreateServiceProxy+0x00d8
  BLUESTONE!ServiceProxy::Connect+0x0116
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x0607
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d

Last 4 operations

Operation #1 created in thread 0x00000000000001BC

Service proxy state before operation = Created

Callstack:
  vfnws!VfHookWsGetServiceProxyProperty+0x0053
  BLUESTONE!WST_WebServices::WsGetServiceProxyProperty+0x009b
  BLUESTONE!ServiceProxy::GetState+0x004b
  BLUESTONE!ServiceProxy::VerifyState+0x001c
  BLUESTONE!ServiceProxy::Connect+0x01c7
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x0607
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d

Operation #2 created in thread 0x00000000000001BC

Service proxy state before operation = Created

Callstack:
  vfnws!VfHookWsOpenServiceProxy+0x0079
  BLUESTONE!WST_WebServices::WsOpenServiceProxy+0x0092
  BLUESTONE!ServiceProxy::Connect+0x03d3
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x0607
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d

Operation #3 created in thread 0x00000000000001BC

Service proxy state before operation = Open

Callstack:
  vfnws!VfHookWsGetServiceProxyProperty+0x0053
  BLUESTONE!WST_WebServices::WsGetServiceProxyProperty+0x009b
  BLUESTONE!ServiceProxy::GetState+0x004b
  BLUESTONE!ServiceProxy::VerifyState+0x001c
  BLUESTONE!ServiceProxy::Connect+0x0484
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x0607
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d

Operation #4 created in thread 0x00000000000001BC

Service proxy state before operation = Open

Callstack:
  vfnws!VfHookWsCall+0x00a6
  BLUESTONE!DefaultBinding_ICalculator_Add+0x008b
  BLUESTONE!ServiceModelTestGroup_Simple_Function+0x010a
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x069a
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d

Asynchronous Callback = BLUESTONE!ServiceModelTestGroup_Simple_Callback
Asynchronous CallbackState = 0x0000000005EBDC30

Completed asynchronously with HRESULT=0x00000000 in thread 0x00000000000001BC

Asynchronous callback stack:
  vfnws!VfHookWsCall+0x00e3
  BLUESTONE!DefaultBinding_ICalculator_Add+0x008b
  BLUESTONE!ServiceModelTestGroup_Simple_Function+0x010a
  BLUESTONE!ServiceModel_SimpleTest::SimpleClient+0x069a
  BLUESTONE!ServiceModelTestGroup_Simple_Test02_Run+0x0041
  BLUESTONE!Fnshell2::FnshellConfiguration::RunTest+0x002e
  BLUESTONE!Fnshell2::TESTCASE::Run+0x00d6
  BLUESTONE!fnsMsgProc+0x02d6
  BLUESTONE!fnsRunTestsWorkerThread+0x085f
  KERNEL32!BaseThreadInitThunk+0x000d
  ntdll!RtlUserThreadStart+0x001d


Closed stack:

0:001>

Layanan

Layanan menguji, memeriksa penggunaan Layanan Windows yang tepat. Misalnya, layanan sedang dimulai dan dihentikan dengan benar. Untuk informasi tentang pengecualian kode berhenti yang dihasilkan oleh pengujian ini, lihat Pemverifikasi Aplikasi - Hentikan Kode - Layanan.

Perf

Uji Perf memeriksa penggunaan API yang efisien yang memengaruhi performa sistem dan konsumsi energi, seperti memanggil fungsi Windows yang menggunakan periode tunggu yang salah. Untuk informasi tentang pengecualian kode berhenti yang dihasilkan oleh pengujian ini, lihat Pemverifikasi Aplikasi - Hentikan Kode - Perf.

Hang

Tes Hangs untuk penggunaan API yang menyebabkan sistem menjadi tidak responsif, misalnya ketika utas DllMain menunggu utas lain yang diblokir. Untuk informasi tentang pengecualian kode berhenti yang dihasilkan oleh pengujian ini, lihat Pemverifikasi Aplikasi - Hentikan Kode - Macet.

Lihat Juga

Pemverifikasi Aplikasi - Gambaran Umum

Pemverifikasi Aplikasi - Fitur

Pemverifikasi Aplikasi - Aplikasi Pengujian

Pemverifikasi Aplikasi - Hentikan Kode dan Definisi

Pemverifikasi Aplikasi - Debugging Pemverifikasi Aplikasi Berhenti

Pemverifikasi Aplikasi - Pertanyaan yang Sering Diajukan

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2023-06-15

Bagikan melalui

Pemverifikasi Aplikasi - Pengujian dalam Pemverifikasi Aplikasi

Dukungan ARM64EC

Dasar

Kompatibilitas

Pusing

Properti Cuzz

Simulasi Sumber Daya Rendah

Properti Simulasi Sumber Daya Rendah

LuaPriv

Lain-lain

Properti Lain-lain

Jaringan

Properti

!avrf Debugger Extension

NTLM

Risiko Autentikasi NTLM

Faktor apa yang menyebabkan NTLM "dikodekan secara permanen" dalam aplikasi?

Cara Kerja Plug-in NTLM

Mengonfigurasi Opsi Henti Plug-in

NTLM Berhenti

5000 – Aplikasi telah secara eksplisit memilih paket NTLM

Cara Memperbaiki Kesalahan ini

5001 – Daftar Paket Negosiasi Hanya Mencakup NTLM

Cara Memperbaiki Kesalahan ini

5002 – Daftar Paket Negosiasi Pengecualian NTLM Salah

5003 – Tidak ada nama target atau nama target yang salah bentuk untuk Server

Cara Memperbaiki Kesalahan ini

5010 – Turun tingkat ke NTLM Terdeteksi

Pencetakan

Layanan Web

Layanan

Perf

Hang

Lihat Juga

Saran dan Komentar

Sumber Daya Tambahan: