Windows Hardware Drivers Develop

Beri tahu kami tentang pengalaman mengunduh PDF.
Mengembangkan, Menguji, dan

Menyebarkan Driver
Artikel • 13/12/2022 • 2 menit untuk membaca
Lingkungan pengembangan driver Windows dan debugger Windows diintegrasikan ke

dalam Microsoft Visual Studio. Dalam lingkungan pengembangan driver terintegrasi ini,
sebagian besar alat yang Anda butuhkan untuk pengkodean, pembuatan, pengemasan,
penyebaran, dan pengujian driver tersedia di antarmuka pengguna Visual Studio.
Untuk mengatur lingkungan pengembangan terintegrasi, pertama instal Visual Studio

lalu instal WDK. Anda dapat menemukan informasi tentang cara mendapatkan Visual
Studio dan WDK di halaman pengaturan dan unduhan WDK. Alat Debugging untuk
Windows disertakan dengan instalasi WDK.
WDK menggunakan MSBuild.exe, yang tersedia baik di antarmuka pengguna Visual

Studio dan sebagai alat baris perintah. Driver yang dibuat di lingkungan Visual Studio
menggunakan file Project dan Solusi untuk menggambarkan proyek atau grup proyek.
Lingkungan Visual Studio menyediakan alat untuk mengonversi file Sumber dan Dirs
lama ke file Project dan Solusi.
Lingkungan Visual Studio menyediakan templat untuk:
Driver baru
Paket driver
Tes baru
Peningkatan pengujian yang ada
Skrip penyebaran driver kustom
Di lingkungan Visual Studio, Anda dapat mengonfigurasi proses pembuatan sehingga

secara otomatis membuat dan menandatangani paket driver. Alat analisis statis dan run-
time tersedia dalam Visual Studio. Anda dapat mengonfigurasi komputer target untuk
menguji driver dan secara otomatis menyebarkan driver ke komputer target setiap kali
Anda membangun kembali. Anda dapat memilih dari serangkaian tes run-time yang
ekstensif, dan Anda dapat menulis tes Anda sendiri.
Topik di bagian ini menunjukkan kepada Anda cara menggunakan Visual Studio untuk
melakukan beberapa tugas yang terlibat dalam pengembangan, penyebaran, dan
pengujian driver.
Video Tambahan
Anda akan menemukan video di halaman berikut di dokumen driver Windows:
Menggunakan Windows Performance Toolkit (WPT) dengan WDF

Video: Mengakses log IFR driver tanpa debugger
Video: Debugging driver Anda dengan kode sumber WDF
Video: Debugging Driver UMDF
Memulai 'Driver Windows'
Ketika Anda menulis driver untuk dijalankan pada sistem operasi Windows, Anda
memiliki dua pilihan dasar. Anda dapat menulis driver Windows Desktop, yang hanya
berjalan pada edisi Desktop Windows. Atau, Anda dapat memenuhi beberapa
persyaratan tambahan dan menulis Driver Windows, yang berjalan pada varian Desktop
dan non-Desktop Windows. Klasifikasi driver Windows memperluas dan menggantikan
klasifikasi Universal Driver yang lebih lama.
Persyaratan tambahan berikut berlaku untuk Driver Windows:
Mematuhi Prinsip Desain DCH.

Ikuti prinsip Isolasi Paket Driver.
Ikuti Persyaratan Lapisan API.
Disertifikasi dengan Windows Proses Sertifikasi Program Kompatibilitas Perangkat
Keras menggunakan Kit Lab Perangkat Keras. Persyaratan Proses Sertifikasi WHCP
berlaku untuk driver KMDF dan UMDF.
Tabel berikut ini meringkas perbedaan antara dua klasifikasi:
Fitur Driver Driver Desktop

Windows Windows
Berjalan di Windows Desktop Ya Ya
Berjalan pada varian non-Desktop Windows Ya Tidak
Harus disertifikasi dengan WHCP Ya Tidak
WDK & HLK adalah kendaraan utama untuk mengembangkan Ya Ya

dan mensertifikasi pengemudi
Mematuhi persyaratan keandalan dan layanan yang lebih ketat Ya Tidak

(misalnya isolasi paket driver)
Meskipun tidak diperlukan bagi driver yang hanya berjalan di Windows Desktop untuk
memenuhi persyaratan tambahan untuk Driver Windows, melakukannya meningkatkan
layanan dan keandalan driver, dan juga menyiapkan driver untuk kemungkinan
sertifikasi di masa mendatang pada varian non-Desktop Windows.
Prinsip Desain DCH dan Praktik Terbaik
Halaman ini menjelaskan prinsip-prinsip desain dan praktik terbaik untuk Driver
Windows.
Prinsip Desain DCH

Ada tiga prinsip desain yang perlu dipertimbangkan agar Driver Windows sesuai dengan
DCH:
Deklaratif (D): Instal driver hanya dengan menggunakan direktif INF deklaratif.
Jangan sertakan fungsi co-installer atau RegisterDll.
Componentized (C): Kustomisasi khusus edisi, khusus OEM, dan opsional untuk
pengemudi terpisah dari paket driver dasar. Akibatnya, driver dasar, yang hanya
menyediakan fungsionalitas perangkat inti, dapat ditargetkan, terbang, dan
dilayani secara independen dari penyesuaian.
Aplikasi Dukungan Perangkat Keras (H): Setiap komponen antarmuka pengguna

(UI) yang terkait dengan Driver Windows harus dikemas sebagai Aplikasi
Dukungan Perangkat Keras (HSA) atau diinstal sebelumnya pada perangkat OEM.
HSA adalah aplikasi khusus perangkat opsional yang dipasangkan dengan driver.
Aplikasi ini bisa menjadi aplikasi Universal Windows Platform (UWP) atau Desktop
Bridge. Anda harus mendistribusikan dan memperbarui HSA melalui Microsoft
Store. Untuk detailnya, lihat Aplikasi Dukungan Perangkat Keras (HSA): Langkah-
langkah untuk pengembang driver dan Aplikasi Dukungan Perangkat Keras (HSA):
Langkah-langkah untuk pengembang aplikasi.
Akronim "DCH" mengacu pada prinsip-prinsip yang tercantum di atas. Silakan lihat
halaman Contoh Paket Driver yang Sesuai dengan DCH untuk melihat bagaimana
sampel driver dapat menerapkan prinsip desain DCH.
Gambaran Umum
Paket driver yang sesuai dengan DCH berisi file INF dan binari yang diinstal dan
dijalankan pada edisi Windows berbasis Universal Windows Platform (UWP). Mereka
juga menginstal dan menjalankan pada edisi lain dari Windows 10 dan 11 yang berbagi
satu set umum antarmuka.
Binari driver yang sesuai dengan DCH dapat menggunakan KMDF, UMDF 2, atau
Windows Driver Model (WDM).
Driver yang sesuai dengan DCH terdiri dari bagian-bagian berikut:
Driver dasar
Paket komponen opsional
Aplikasi dukungan perangkat keras opsional
Driver dasar berisi semua fungsi inti dan kode bersama. Paket komponen opsional dapat
berisi penyesuaian dan pengaturan tambahan.
Biasanya, produsen perangkat, atau vendor perangkat keras independen (IHV), menulis
driver dasar. Kemudian, pembangun sistem, atau produsen peralatan asli (OEM),
menyediakan paket komponen opsional.
Setelah IHV telah mensertifikasi paket driver dasar, itu dapat digunakan pada semua
sistem OEM. Karena paket driver dasar dapat digunakan di semua sistem yang berbagi
bagian perangkat keras, Microsoft dapat menguji paket driver dasar secara luas melalui
penerbangan Windows Insider, daripada membatasi distribusi ke mesin tertentu.
OEM hanya memvalidasi kustomisasi opsional yang disediakannya untuk sistem OEM.
Persyaratan
Untuk membuat paket driver yang mengikuti prinsip desain DCH, ikuti langkah-langkah
berikut:
Buat file INF untuk driver Anda:
1. Tinjau daftar bagian dan arahan INF yang berlaku di paket Driver Windows.
2. Gunakan alat InfVerif untuk memverifikasi bahwa file INF paket driver Anda
mengikuti persyaratan Deklaratif (D) untuk Driver Windows. Itu harus berlalu
infverif /w .
Pastikan bahwa setiap paket komponen opsional yang tidak mengandung fungsi
driver inti dipisahkan dari paket driver dasar.
Aplikasi dukungan perangkat keras yang terkait dengan paket driver Anda harus
didistribusikan melalui Microsoft Store.
Praktik terbaik
Jika Anda menggunakan Windows Driver Kit (WDK) dengan Visual Studio terbaru
yang tersedia, atur nilai Target Platform di properti proyek driver ke Windows
Driver . Ini secara otomatis menambahkan pustaka yang benar, dan menjalankan
validasi INF yang tepat dan ApiValidator sebagai bagian dari build. Untuk
melakukan ini:
1. Buka properti proyek driver.

2. Pilih Pengaturan Driver.
3. Gunakan menu drop-down untuk mengatur Target Platform ke Windows
Driver .
Jika INF Anda melakukan tindakan penyiapan kustom yang bergantung pada
platform target, pertimbangkan untuk memisahkannya menjadi INF ekstensi. Anda
dapat memperbarui ekstensi INF secara independen dari paket driver dasar agar
lebih kuat dan dapat diservis. Untuk informasi selengkapnya, lihat Menggunakan
file INF ekstensi.
Jika Anda ingin menyediakan aplikasi yang berfungsi dengan perangkat Anda,
sertakan aplikasi UWP. Untuk informasi selengkapnya, lihat Aplikasi Dukungan
Perangkat Keras (HSA): Langkah-langkah untuk pengembang driver. OEM dapat
melakukan preload aplikasi semacam itu dengan menggunakan DISM -
Deployment Image Servicing and Management. Atau, pengguna dapat
mengunduh aplikasi secara manual dari Microsoft Store.
Di bagian INF DestinationDirs, atur direktori tujuan ke dirid 13 untuk membuat

pengemudi lari dari toko pengemudi. Pengaturan ini tidak akan berfungsi untuk
beberapa perangkat.
Isolasi paket driver
Isolasi paket driver adalah persyaratan untuk driver Windows yang membuat paket
driver lebih tahan terhadap perubahan eksternal, lebih mudah diperbarui, dan lebih
mudah diinstal.
７ Catatan
Meskipun isolasi paket driver diperlukan untuk driver Windows, Windows Driver
Desktop masih mendapat manfaat darinya melalui peningkatan ketahanan dan
layanan.
Tabel berikut ini memperlihatkan beberapa contoh praktik paket driver warisan yang
tidak lagi diizinkan untuk Driver Windows di kolom kiri bersama dengan perilaku yang
diperlukan untuk driver Windows di kolom kanan.
Driver yang tidak terisolasi Driver terisolasi
INF menyalin file ke %windir%\System32 File driver dijalankan dari penyimpanan driver
atau %windir%\System32\drivers
Berinteraksi dengan tumpukan/driver Berinteraksi dengan tumpukan/driver perangkat

perangkat menggunakan jalur yang menggunakan fungsi atau antarmuka perangkat
dikodekan secara permanen yang disediakan sistem
Jalur hardcode ke lokasi registri global Menggunakan fungsi HKR dan yang disediakan
sistem untuk lokasi relatif registri dan status file
File runtime menulis ke lokasi mana pun File ditulis relatif terhadap lokasi yang disediakan
oleh sistem operasi
Untuk bantuan dalam menentukan apakah paket driver Anda memenuhi persyaratan
isolasi paket driver, lihat Memvalidasi driver Windows. Untuk contoh cara memperbarui
INF untuk memenuhi persyaratan isolasi paket driver, lihat Porting INF untuk mengikuti
isolasi paket driver.
Jalankan dari penyimpanan driver

Semua paket driver terisolasi meninggalkan file paket driver mereka di penyimpanan
driver. Ini berarti bahwa mereka menentukan DIRID 13 di INF mereka untuk menentukan
lokasi untuk file paket driver saat diinstal. Untuk informasi selengkapnya tentang cara
menggunakan ini dalam paket driver, lihat Menjalankan dari penyimpanan driver.
Status membaca dan menulis
７ Catatan
Jika komponen Anda menggunakan properti antarmuka perangkat atau perangkat

untuk menyimpan status , terus gunakan metode tersebut dan API OS yang sesuai
untuk menyimpan dan mengakses status. Panduan berikut untuk registri dan status
file adalah untuk status lain yang perlu disimpan oleh komponen.
Akses ke berbagai registri dan status file harus dilakukan dengan memanggil fungsi
yang menyediakan penelepon dengan lokasi status dan kemudian status dibaca/ditulis
relatif terhadap lokasi tersebut. Jangan gunakan jalur registri absolut dan jalur file yang
dikodekan secara permanen.
Bagian ini berisi subbagian berikut:
Status registri
Status file
Status properti
Status registri
Status registri perangkat PnP
Status registri antarmuka perangkat
Status registri layanan
Status registri perangkat PnP

Paket driver terisolasi dan komponen mode pengguna biasanya menggunakan salah
satu dari dua lokasi untuk menyimpan status perangkat di registri. Ini adalah kunci
perangkat keras (kunci perangkat) untuk perangkat dan kunci perangkat lunak (kunci
driver) untuk perangkat. Kunci perangkat keras biasanya untuk pengaturan yang terkait
dengan bagaimana instans perangkat individual berinteraksi dengan perangkat keras.
Misalnya, untuk mengaktifkan fitur perangkat keras atau memasukkan perangkat keras
ke mode tertentu. Kunci perangkat lunak biasanya untuk pengaturan yang terkait
dengan bagaimana instans perangkat individual berinteraksi dengan sistem dan
perangkat lunak lainnya. Misalnya, untuk mengonfigurasi lokasi file data, untuk
beroperasi dengan kerangka kerja, atau mengakses pengaturan aplikasi untuk
perangkat. Untuk mengambil handel ke lokasi registri ini, gunakan salah satu opsi
berikut:
IoOpenDeviceRegistryKey (WDM)
WdfDeviceOpenRegistryKey, WdfFdoInitOpenRegistryKey (WDF)
CM_Open_DevNode_Key (kode mode pengguna)
Direktif INF AddReg menggunakan entri reg-root HKR di bagian add-registry yang
direferensikan dari bagian INF DDInstall atau bagian DDInstall.HW , seperti yang
ditunjukkan di bawah ini:
INF
[ExampleDDInstall.HW]
AddReg = Example_DDInstall.AddReg
[Example_DDInstall.AddReg]
HKR,,ExampleValue,,%13%\ExampleFile.dll
Status registri antarmuka perangkat

Untuk membaca dan menulis status registri antarmuka perangkat, gunakan salah satu
opsi berikut:
IoOpenDeviceInterfaceRegistryKey (WDM)
CM_Open_Device_Interface_Key (kode mode pengguna)
Direktif INF AddReg menggunakan entri reg-root HKR di bagian add-registry yang
direferensikan dari bagian add-interface-section
Status registri layanan

Status layanan harus diklasifikasikan ke dalam salah satu dari 3 kategori
Status registri layanan yang tidak dapat diubah
Status registri layanan internal

Status registri layanan bersama
Status registri layanan yang tidak dapat diubah
Status layanan yang tidak dapat diubah adalah status yang disediakan oleh paket driver
yang menginstal layanan. Nilai registri ini yang ditetapkan oleh INF untuk driver dan
layanan Win32 harus disimpan di bawah subkunci "Parameter" layanan dengan
menyediakan baris HKR di bagian AddReg , lalu merujuk bagian tersebut di bagian
penginstalan layanan di INF. Contohnya:
INF
[ExampleDDInstall.Services]
Addservice = ExampleService, 0x2, Example_Service_Inst
[Example_Service_Inst]
DisplayName = %ExampleService.SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %13%\ExampleService.sys
AddReg=Example_Service_Inst.AddReg
[Example_Service_Inst.AddReg]
HKR, Parameters, ExampleValue, 0x00010001, 1
Untuk mengakses lokasi status ini dari layanan saat runtime, gunakan salah satu fungsi
berikut:
IoOpenDriverRegistryKey (WDM) dengan DRIVER_REGKEY_TYPE

DriverRegKeyParameters
WdfDriverOpenParametersRegistryKey (WDF)
GetServiceRegistryStateKey (Layanan Win32) dengan

SERVICE_REGISTRY_STATE_TYPE ServiceRegistryStateParameters
Nilai registri ini disediakan oleh INF dalam subkunjuk "Parameter" untuk layanan hanya
boleh dibaca saat runtime dan tidak dimodifikasi. Mereka harus diperlakukan sebagai
baca saja.
Jika nilai registri yang disediakan oleh INF adalah pengaturan default yang dapat
ditimpa saat runtime, nilai penimpaan harus ditulis ke dalam status registri layanan
Internal atau status registri layanan bersama untuk layanan. Saat mengambil
pengaturan, pengaturan dapat dicari terlebih dahulu dalam status dapat diubah. Jika
tidak ada di sana, maka pengaturan dapat dicari dalam keadaan tidak dapat diubah.
RtlQueryRegistryValueWithFallback dapat digunakan untuk membantu pengaturan
kueri seperti ini yang memiliki penimpaan dan nilai default.
Status registri layanan internal
Status layanan internal adalah status yang ditulis pada runtime dan dimiliki dan dikelola
oleh hanya layanan itu sendiri dan hanya dapat diakses oleh layanan tersebut. Untuk
mengakses lokasi untuk status layanan internal, gunakan salah satu fungsi ini dari
layanan:

DriverRegKeyPersistentState
WdfDriverOpenPersistentStateRegistryKey (WDF)
GetServiceRegistryStateKey (Layanan Win32) dengan

SERVICE_REGISTRY_STATE_TYPE ServiceRegistryStatePersistent
Jika layanan ingin mengizinkan komponen lain untuk memodifikasi pengaturan ini,
layanan harus mengekspos antarmuka yang dapat dipanggil komponen lain yang
memberi tahu layanan cara mengubah pengaturan ini. Misalnya, layanan Win32 dapat
mengekspos antarmuka COM atau RPC dan layanan driver dapat mengekspos
antarmuka IOCTL melalui antarmuka perangkat.
Status registri layanan bersama
Status layanan bersama adalah status yang ditulis pada runtime dan dapat dibagikan
dengan komponen mode pengguna lain jika mereka cukup istimewa. Untuk mengakses
lokasi untuk status layanan bersama ini, gunakan salah satu fungsi berikut:

DriverRegKeySharedPersistentState
GetSharedServiceRegistryStateKey (Win32 Services) dengan

SERVICE_SHARED_REGISTRY_STATE_TYPE ServiceSharedRegistryPersistentState
Status file
Status file perangkat
Status file layanan

Status file perangkat
Jika file yang terkait dengan perangkat perlu ditulis saat runtime, file tersebut harus
disimpan relatif terhadap handel atau jalur file yang disediakan melalui OS API. File
konfigurasi khusus untuk perangkat tersebut adalah salah satu contoh jenis file apa
yang akan disimpan di sini. Untuk mengakses lokasi status ini, gunakan salah satu fungsi
ini dari layanan:
IoGetDeviceDirectory (WDM) dengan parameter DirectoryType diatur ke

DeviceDirectoryData
WdfDeviceRetrieveDeviceDirectoryString (WDF)
Status file layanan
Status file layanan dapat diklasifikasikan ke dalam salah satu dari 3 kategori
Status file layanan yang tidak dapat diubah
Status file layanan internal
Status file layanan bersama
Status file layanan yang tidak dapat diubah
Status file layanan yang tidak dapat diubah adalah file yang merupakan bagian dari
paket driver. Untuk informasi selengkapnya tentang mengakses file tersebut, lihat
Menjalankan dari Driver Store.
Status file layanan internal
Status file layanan internal adalah status yang ditulis pada runtime dan dimiliki serta
dikelola oleh hanya layanan itu sendiri dan hanya dapat diakses oleh layanan tersebut.
Untuk mengakses lokasi untuk status layanan internal, gunakan salah satu fungsi ini dari
layanan:
IoGetDriverDirectory (WDM, KMDF) dengan parameter DirectoryType diatur ke

DriverDirectoryData
WdfDriverRetrieveDriverDataDirectoryString (UMDF)
GetServiceDirectory (Win32 Services) dengan parameter eDirectoryType diatur ke

ServiceDirectoryPersistentState
Jika layanan ingin mengizinkan komponen lain untuk memodifikasi pengaturan ini,
layanan harus mengekspos antarmuka yang dapat dipanggil komponen lain yang
memberi tahu layanan cara mengubah pengaturan ini. Misalnya, layanan Win32 dapat
mengekspos antarmuka COM atau RPC dan layanan driver dapat mengekspos
antarmuka IOCTL melalui antarmuka perangkat.
Status file layanan bersama
Status file layanan bersama adalah status yang ditulis pada runtime dan dapat dibagikan
dengan komponen mode pengguna lain jika cukup istimewa. Untuk mengakses lokasi
untuk status layanan bersama ini, gunakan salah satu fungsi berikut:
IoGetDriverDirectory (WDM, KMDF) dengan parameter DirectoryType diatur ke

DriverDirectorySharedData
GetSharedServiceDirectory (Win32 Services) dengan parameter DirectoryType

diatur ke ServiceSharedDirectoryPersistentState
DriverData dan ProgramData
File yang akan digunakan sebagai bagian dari operasi perantara yang dapat dibagikan
dengan komponen lain dapat ditulis ke salah satu DriverData atau ProgramData lokasi.
Lokasi ini menawarkan komponen lokasi untuk menulis status atau status sementara
yang dimaksudkan untuk dikonsumsi oleh komponen lain dan berpotensi dikumpulkan
dan disalin dari sistem untuk diproses oleh sistem lain. Misalnya, file log kustom atau
crash dump sesuai dengan deskripsi ini.
Hindari menulis file di akar DriverData direktori atau ProgramData . Sebagai gantinya,
buat subdirektori dengan nama perusahaan Anda lalu tulis file dan subdirektori lebih
lanjut dalam direktori tersebut.
Misalnya, untuk nama perusahaan Contoso, driver mode kernel dapat menulis log
kustom ke \DriverData\Contoso\Logs dan aplikasi mode pengguna dapat
mengumpulkan atau menganalisis file log dari %DriverData%\Contoso\Logs .
DriverData
DriverData Direktori tersedia di Windows 10, versi 1803 dan yang lebih baru, dan dapat
diakses oleh administrator dan driver UMDF.

Driver mode kernel mengakses DriverData direktori dengan menggunakan tautan
simbolis yang disediakan sistem yang disebut \DriverData .
Program mode pengguna mengakses DriverData direktori dengan menggunakan

variabel %DriverData% lingkungan .
ProgramData
Variabel %ProgramData% lingkungan mode pengguna tersedia untuk digunakan

komponen mode pengguna saat menyimpan data.
Status properti
Perangkat dan antarmuka perangkat mendukung penyimpanan status melalui model
properti PnP. Model properti memungkinkan data properti terstruktur disimpan
terhadap perangkat atau antarmuka perangkat. Ini dimaksudkan untuk data yang lebih
kecil yang cukup cocok dengan jenis properti yang didukung oleh model properti.
Untuk mengakses properti perangkat, API ini dapat digunakan:
Driver WDM
IoGetDevicePropertyData
IoSetDevicePropertyData
Driver WDF
WdfDeviceQueryProperty
WdfDeviceAllocAndQueryProperty
WdfDeviceQueryPropertyEx
WdfDeviceAllocAndQueryPropertyEx
WdfDeviceAssignProperty
WdfFdoInitQueryProperty
WdfFdoInitAllocAndQueryProperty
WdfFdoInitQueryPropertyEx
WdfFdoInitAllocAndQueryPropertyEx
Kode mode pengguna
CM_Get_DevNode_Property
CM_Set_DevNode_Property
Untuk mengakses properti antarmuka perangkat, API ini dapat digunakan:
Driver WDM
IoGetDeviceInterfacePropertyData
IoSetDeviceInterfacePropertyData
Driver WDF
WdfDeviceQueryInterfaceProperty
WdfDeviceAllocAndQueryInterfaceProperty
WdfDeviceAssignInterfaceProperty
Kode mode pengguna
CM_Get_Device_Interface_Property
CM_Set_Device_Interface_Property
Menggunakan antarmuka perangkat

Jika driver ingin mengizinkan komponen lain membaca atau memodifikasi status
internal driver, driver harus mengekspos antarmuka yang dapat dipanggil komponen
lain yang memberi tahu driver pengaturan apa yang akan dikembalikan atau cara
mengubah pengaturan tertentu. Misalnya, layanan driver dapat mengekspos antarmuka
IOCTL melalui antarmuka perangkat.
Biasanya, driver yang memiliki status mengekspos antarmuka perangkat di kelas

antarmuka perangkat kustom. Ketika driver siap untuk komponen lain untuk memiliki
akses ke status, itu memungkinkan antarmuka. Untuk mendapatkan pemberitahuan saat
antarmuka perangkat diaktifkan, komponen mode pengguna dapat mendaftar untuk
pemberitahuan kedatangan antarmuka perangkat dan komponen mode kernel dapat
menggunakan IoRegisterPlugPlayNotification. Agar komponen ini dapat mengakses
status, driver yang mengaktifkan antarmuka harus menentukan kontrak untuk kelas
antarmuka perangkat kustomnya. Kontrak ini biasanya merupakan salah satu dari dua
jenis:
Kontrak I/O dapat dikaitkan dengan kelas antarmuka perangkat yang menyediakan
mekanisme untuk mengakses status. Komponen lain menggunakan antarmuka
perangkat yang diaktifkan untuk mengirim permintaan I/O yang sesuai dengan
kontrak.
Antarmuka panggilan langsung yang dikembalikan melalui antarmuka kueri. Driver

lain dapat mengirim IRP_MN_QUERY_INTERFACE untuk mengambil penunjuk
fungsi dari driver untuk dipanggil.
Atau, jika driver yang memiliki status memungkinkan akses langsung ke status , driver
lain dapat mengakses status dengan menggunakan fungsi yang disediakan sistem untuk
akses terprogram ke status antarmuka perangkat. Lihat Status Registri Antarmuka
Perangkat untuk informasi selengkapnya.
Antarmuka atau status ini (tergantung pada metode berbagi yang digunakan) perlu
diberi versi yang benar sehingga driver yang memiliki status dapat dilayankan secara
independen dari komponen lain yang mengakses status tersebut. Vendor driver tidak
dapat mengandalkan komponen lain yang dilayanakan pada saat yang sama dengan
driver dan tetap pada versi yang sama.
Karena antarmuka pengontrol perangkat dan driver datang dan pergi, driver dan
aplikasi harus menghindari panggilan IoGetDeviceInterfaces pada start-up komponen
untuk mendapatkan daftar antarmuka yang diaktifkan. Sebaliknya, praktik terbaik adalah
mendaftar untuk pemberitahuan kedatangan atau penghapusan antarmuka perangkat
dan kemudian memanggil fungsi yang sesuai untuk mendapatkan daftar antarmuka
yang diaktifkan yang ada pada komputer.
Untuk informasi selengkapnya tentang antarmuka perangkat, lihat:
Menggunakan Antarmuka Perangkat
Mendaftar untuk Pemberitahuan Kedatangan Antarmuka Perangkat dan

Penghapusan Perangkat
Mendaftar untuk Pemberitahuan Perubahan Antarmuka Perangkat
Referensi cepat dukungan sistem operasi untuk

API manajemen status
Sebagian besar paket driver perlu mendukung berbagai versi sistem operasi. Lihat
Mendukung beberapa versi sistem operasi untuk informasi selengkapnya tentang cara
mencapainya dalam paket driver. Tabel berikut ini memberikan referensi cepat tentang
kapan dukungan sistem operasi ditambahkan untuk berbagai API manajemen status.
Driver WDM
Sistem Dukungan ditambahkan

operasi
Windows IoopenDeviceRegistryKey
2000 IoOpenDeviceInterfaceRegistryKey
Windows IoGetDevicePropertyData
Vista IoSetDevicePropertyData
Windows 8 IoGetDeviceInterfacePropertyData
IoSetDeviceInterfacePropertyData
Windows 8.1 IoQueryFullDriverPath
Windows 10 IoOpenDriverRegistryKey untuk RegKeyType dari DriverRegKeyParameters dan

1803 DriverRegKeyPersistentState
IoGetDeviceDirectory
IoGetDriverDirectory untuk DirectoryTypedriverDirectoryImage dan

DriverDirectoryData
Windows 10 RtlQueryRegistryValueWithFallback
1809
Windows 11 IoOpenDriverRegistryKey untuk RegKeyType dari

21H2 DriverRegKeySharedPersistentState
IoGetDriverDirectory untuk DirectoryType dari DriverDirectorySharedData
Driver KMDF
Versi KMDF Dukungan ditambahkan
1,0 WdfDeviceOpenRegistryKey
WdfFdoInitOpenRegistryKey
WdfDriverOpenParametersRegistryKey
1.13 WdfDeviceQueryPropertyEx
1.25 WdfDriverOpenPersistentStateRegistryKey (Windows 10 1803)

Driver UMDF
Versi UMDF Dukungan ditambahkan
2.0 WdfDeviceOpenRegistryKey
WdfFdoInitOpenRegistryKey
WdfDriverOpenParametersRegistryKey
WdfDeviceQueryPropertyEx
WdfDeviceQueryInterfaceProperty (Windows 8.1)
WdfDeviceAllocAndQueryInterfaceProperty (Windows 8.1)
WdfDeviceAssignInterfaceProperty (Windows 8.1)
2,25 WdfDeviceRetrieveDeviceDirectoryString
WdfDriverOpenPersistentStateRegistryKey (Windows 10 1803)
2.27 WdfDriverRetrieveDriverDataDirectoryString
Kode mode pengguna
Sistem operasi Dukungan ditambahkan
Windows 2000 CM_Open_DevNode_Key
Windows Vista CM_Open_Device_Interface_Key

CM_Get_DevNode_Property
CM_Set_DevNode_Property
CM_Get_Device_Interface_Property
CM_Set_Device_Interface_Property
Windows 10 2004 GetServiceRegistryStateKey
GetServiceDirectory
Windows 11 21H2 GetSharedServiceRegistryStateKey
GetSharedServiceDirectory
Jalankan Dari Penyimpanan Driver
INF yang menggunakan 'jalankan dari Driver Store' berarti bahwa INF menggunakan
DIRID 13 untuk menentukan lokasi untuk file paket driver saat diinstal.
Untuk file 'jalankan dari Penyimpanan Driver' yang dimuat oleh INF, subdir yang
tercantum dalam entri SourceDisksFiles untuk file di INF harus cocok dengan subdir
yang tercantum dalam entri DestinationDirs untuk file di INF.
Selain itu, direktif CopyFiles tidak dapat digunakan untuk mengganti nama file yang
dijalankan dari Penyimpanan Driver. Pembatasan ini diperlukan agar penginstalan INF
pada perangkat tidak mengakibatkan pembuatan file baru di direktori Penyimpanan
Driver.
Karena entri SourceDisksFiles tidak dapat memiliki beberapa entri dengan nama file
yang sama dan CopyFiles tidak dapat digunakan untuk mengganti nama file, setiap file
'jalankan dari Penyimpanan Driver' yang direferensikan INF harus memiliki nama file
yang unik.
Paket driver memiliki dukungan umum untuk 'jalankan dari Driver Store' yang dimulai
dengan Windows 10 1709. Namun, tumpukan perangkat tertentu dapat menempatkan
pembatasan tambahan pada file yang perlu Anda berikan yang dicolokkan ke tumpukan
tersebut. Beberapa contohnya adalah tumpukan perangkat ini yang tidak mendukung
'jalankan dari Penyimpanan Driver' hingga Windows 10 1803:
Biner driver UMDF: Lihat Membatasi Lokasi Pemuatan Driver UMDF untuk
informasi selengkapnya
Pembaruan firmware UEFI: Lihat Menulis paket driver pembaruan untuk informasi
selengkapnya
Jika menyediakan biner yang dicolokkan ke tumpukan perangkat tertentu, silakan lihat
dokumentasi untuk tumpukan perangkat tertentu yang Anda colokkan untuk memeriksa
apakah mendukung penyediaan jalur file lengkap ke biner dan jika ada batasan pada
jalur file lengkap tersebut. Jika mendukung penyediaan jalur file lengkap ke biner tanpa
batasan pada jalur tersebut, maka harus mendukung file yang 'dijalankan dari Driver
Store'.
Menemukan dan memuat file secara dinamis

dari Penyimpanan Driver
Terkadang ada kebutuhan komponen untuk memuat file yang merupakan bagian dari
paket driver yang menggunakan 'jalankan dari Driver Store'. Jalur ke file paket driver ini
tidak boleh dikodekan secara permanen karena dapat berbeda antara versi paket driver
yang berbeda, versi OS yang berbeda, edisi OS yang berbeda, dll. Ketika kebutuhan
untuk memuat file paket driver muncul, file paket driver ini harus ditemukan dan dimuat
secara dinamis menggunakan beberapa paradigma yang dijelaskan di bawah ini.
Menemukan dan memuat file dalam paket driver yang

sama
Ketika file dalam paket driver perlu memuat file lain dari paket driver yang sama, salah
satu opsi potensial untuk menemukan file tersebut secara dinamis adalah menentukan
direktori tempat file ini dijalankan dan memuat file lain relatif terhadap direktori
tersebut.
Driver WDM atau KMDF yang berjalan dari Driver Store pada Windows 10 versi 1803
dan yang lebih baru yang perlu mengakses file lain dari paket drivernya harus
memanggil IoGetDriverDirectory dengan DriverDirectoryImage sebagai jenis direktori
untuk mendapatkan jalur direktori tempat driver dimuat. Atau untuk driver yang perlu
mendukung versi OS sebelum Windows 10 versi 1803, gunakan IoQueryFullDriverPath
untuk menemukan jalur driver, mendapatkan jalur direktori tempatnya dimuat, dan
mencari file yang relatif terhadap jalur tersebut. Jika driver mode kernel adalah driver
KMDF, driver dapat menggunakan WdfDriverWdmGetDriverObject untuk mengambil
objek driver WDM untuk diteruskan ke IoQueryFullDriverPath.
Biner usermode dapat menggunakan GetModuleHandleExW dan

GetModuleFileNameW untuk menentukan dari mana driver dimuat. Misalnya, biner
driver UMDF dapat melakukan sesuatu seperti berikut:
C++
bRet = GetModuleHandleExW(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS,
(PCWSTR)&DriverEntry,
&handleModule);
if (bRet) {
charsWritten = GetModuleFileNameW(handleModule,
path,
pathLength);
Menemukan dan memuat file dalam paket driver apa pun

Dalam beberapa skenario, paket driver mungkin berisi file yang dimaksudkan untuk
dimuat oleh biner dalam paket driver lain atau oleh komponen mode pengguna.
Metode ini juga dapat digunakan untuk file dari paket driver yang sama jika ini lebih
disukai daripada metode yang dijelaskan di atas untuk memuat file dari paket driver
yang sama.
Berikut adalah beberapa contoh skenario yang mungkin melibatkan pemuatan file dari
paket driver:
DLL mode pengguna dalam paket driver menyediakan antarmuka untuk

berkomunikasi dengan driver dalam paket driver.
Paket driver ekstensi berisi file konfigurasi yang dimuat oleh driver dalam paket
driver dasar.
Dalam situasi ini, paket driver harus mengatur beberapa status pada perangkat atau
antarmuka perangkat yang menunjukkan jalur file yang diharapkan untuk dimuat.
Paket driver biasanya akan menggunakan AddReg HKR untuk mengatur status ini.
Untuk contoh ini, harus diasumsikan bahwa untuk ExampleFile.dll , paket driver
memiliki entri SourceDisksFiles tanpa subdir. Ini menghasilkan file yang berada di akar
direktori paket driver. Juga harus diasumsikan bahwa DestinationDirs untuk direktif
CopyFiles menentukan diri 13.
Berikut adalah contoh INF untuk mengatur ini sebagai status perangkat:
C++
[ExampleDDInstall.HW]
AddReg = Example_DDInstall.AddReg
[Example_DDInstall.AddReg]
Contoh INF untuk mengatur ini sebagai status antarmuka perangkat adalah:
C++
[ExampleDDInstall.Interfaces]
AddInterface = {<fill in an interface class GUID for an interface exposed by

the device>},,Example_Add_Interface_Section
[Example_Add_Interface_Section]
AddReg = Example_Add_Interface_Section.AddReg
[Example_Add_Interface_Section.AddReg]
Contoh sebelumnya menggunakan nilai bendera kosong, yang menghasilkan nilai

registri REG_SZ. Ini menghasilkan %13% diubah menjadi jalur file mode pengguna yang
sepenuhnya memenuhi syarat. Dalam banyak kasus, lebih baik memiliki jalur relatif
terhadap variabel lingkungan. Jika nilai bendera 0x20000 digunakan, nilai registri
berjenis REG_EXPAND_SZ dan %13% dikonversi ke jalur dengan variabel lingkungan
yang sesuai untuk mengabstraksi lokasi jalur. Saat mengambil nilai registri ini, panggil
ExpandEnvironmentStrings untuk menyelesaikan variabel lingkungan di jalur.
Jika nilai perlu dibaca oleh komponen mode kernel, nilainya harus menjadi nilai REG_SZ.
Ketika komponen mode kernel membaca nilai tersebut, komponen harus
menambahkannya \??\ sebelum meneruskannya ke API seperti ZwOpenFile.
Untuk mengakses pengaturan ini ketika merupakan bagian dari status perangkat,
pertama-tama aplikasi harus menemukan identitas perangkat. Kode mode pengguna
dapat menggunakan CM_Get_Device_ID_List_Size dan CM_Get_Device_ID_List untuk
mendapatkan daftar perangkat, difilter seperlunya. Daftar perangkat tersebut mungkin
berisi beberapa perangkat, jadi cari perangkat yang sesuai sebelum membaca status
dari perangkat. Misalnya, panggil CM_Get_DevNode_Property untuk mengambil
properti di perangkat saat mencari perangkat yang cocok dengan kriteria tertentu.
Setelah perangkat yang benar ditemukan, panggil CM_Open_DevNode_Key untuk

mendapatkan handel ke lokasi registri tempat status perangkat disimpan.
Kode mode kernel harus mengambil PDO (objek perangkat fisik) ke perangkat dengan
status dan memanggil IoOpenDeviceRegistryKey. Salah satu cara yang mungkin untuk
kode mode kernel untuk mengambil PDO perangkat adalah dengan menemukan
antarmuka yang diaktifkan yang diekspos oleh perangkat dan menggunakan
IoGetDeviceObjectPointer untuk mengambil objek perangkat.
Untuk mengakses pengaturan ini ketika status antarmuka perangkat, Kode mode
pengguna dapat memanggil CM_Get_Device_Interface_List_Size dan
CM_Get_Device_Interface_List.
Selain itu CM_Register_Notification dapat digunakan untuk diberi tahu tentang

kedatangan dan penghapusan antarmuka perangkat sehingga kode akan diberi tahu
ketika antarmuka diaktifkan dan kemudian dapat mengambil status. Mungkin ada
beberapa antarmuka perangkat di kelas antarmuka perangkat yang digunakan dalam
API di atas. Periksa antarmuka tersebut untuk menentukan antarmuka mana yang benar
untuk pengaturan yang akan dibaca.
Setelah antarmuka perangkat yang benar ditemukan, panggil

CM_Open_Device_Interface_Key.
Kode mode kernel dapat mengambil nama tautan simbolis untuk antarmuka perangkat
tempat mendapatkan status. Untuk melakukannya, panggil
IoRegisterPlugPlayNotification untuk mendaftar pemberitahuan antarmuka perangkat
pada kelas antarmuka perangkat yang sesuai. Atau, panggil IoGetDeviceInterfaces
untuk mendapatkan daftar antarmuka perangkat saat ini pada sistem. Mungkin ada
beberapa antarmuka perangkat di kelas antarmuka perangkat yang digunakan dalam
API di atas. Periksa antarmuka tersebut untuk menentukan antarmuka mana yang benar
yang harus memiliki pengaturan yang akan dibaca.
Setelah nama tautan simbolis yang sesuai ditemukan, panggil

IoOpenDeviceInterfaceRegistryKey untuk mengambil handel ke lokasi registri tempat
status antarmuka perangkat disimpan.
７ Catatan
Gunakan bendera CM_GETIDLIST_FILTER_PRESENT dengan

CM_Get_Device_ID_List_Size dan CM_Get_Device_ID_List atau bendera
CM_GET_DEVICE_INTERFACE_LIST_PRESENT dengan
CM_Get_Device_Interface_List_Size dan CM_Get_Device_Interface_List. Ini
memastikan bahwa perangkat keras yang terkait dengan status yang berisi jalur file
ada dan siap untuk komunikasi.
Menghapus paket driver

Secara default, paket driver tidak dapat dihapus dari sistem jika masih diinstal pada
perangkat apa pun. Namun, beberapa opsi untuk menghapus paket driver dari sistem
memungkinkannya untuk dicoba 'paksa' dihapus. Ini mencoba untuk menghapus paket
driver bahkan jika paket driver tersebut masih diinstal pada beberapa perangkat pada
sistem. Penghapusan paksa tidak diperbolehkan untuk paket driver yang memiliki file
apa pun yang 'dijalankan dari Penyimpanan Driver'. Ketika paket driver dihapus dari
sistem, isi Penyimpanan Driver-nya akan dihapus. Jika ada perangkat yang masih diinstal
dengan paket driver tersebut, file 'jalankan dari Penyimpanan Driver' dalam paket driver
tersebut sekarang akan hilang dan file yang hilang tersebut dapat menyebabkan
perangkat tersebut tidak berfungsi. Untuk mencegah menempatkan perangkat ke dalam
keadaan buruk seperti itu, paket driver yang berisi file 'jalankan dari Penyimpanan
Driver' tidak dapat dihapus paksa. Mereka hanya dapat dihapus setelah tidak lagi
diinstal di perangkat apa pun. Untuk membantu penghapusan paket driver tersebut,
DiUninstallDriver atau pnputil /delete-driver <oem#.inf> /uninstall dapat digunakan.
Metode penghapusan ini akan terlebih dahulu memperbarui perangkat apa pun yang
menggunakan paket driver yang dihapus untuk tidak lagi diinstal dengan paket driver
tersebut sebelum mencoba menghapus paket driver.
Pengembangan paket driver
Menguji biner privat

Saat mengembangkan paket driver, jika ada kebutuhan untuk mengganti file tertentu
yang dapat dieksekusi dari paket driver dengan versi privat alih-alih sepenuhnya
membangun kembali dan mengganti paket driver pada sistem, maka disarankan agar
debugger kernel digunakan bersama dengan perintah .kdfiles . Karena jalur lengkap ke
file di Penyimpanan Driver tidak boleh dikodekan secara permanen, disarankan agar
dalam pemetaan .kdfiles, nama file OldDriver hanyalah nama langsung file tanpa
informasi jalur sebelumnya. Untuk memfasilitasi ini (dan skenario lainnya), nama file
dalam paket driver harus seunik mungkin sehingga tidak cocok dengan nama file dari
paket driver yang tidak terkait pada sistem.
Porting INF untuk menggunakan jalankan dari

Driver Store
Jika Anda memiliki paket driver yang ada dengan INF yang tidak menggunakan jalankan
dari Driver Store dan memindahkannya untuk menggunakan jalankan dari Driver Store,
contoh berikut menunjukkan beberapa penggunaan file umum dalam INF dan pola saat
memperbarui file tersebut untuk dijalankan dari DriverStore.
Biner layanan
Jika INF Anda menambahkan layanan dan biner tidak dijalankan dari Driver Store, maka
INF Anda mungkin terlihat seperti:
INF
[DestinationDirs]
; Copy the file to %windir%\system32\drivers
Example_CopyFiles = 12
[ExampleDDInstall]
CopyFiles = Example_CopyFiles
[Example_CopyFiles]
ExampleBinary.sys
AddService = ExampleService,0x2,Example_Service_Inst
DisplayName = %SvcDesc%
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_DEMAND_START%
ErrorControl = %SERVICE_ERROR_NORMAL%
; Point at the file in %windir%\system32\drivers
ServiceBinary = %12%\ExampleBinary.sys
Untuk memindahkan file ini agar dijalankan dari Penyimpanan Driver, Anda perlu
memperbarui entri DestinationDirs tempat file akan disalin dan memperbarui arahan
ServiceBinary yang merujuk lokasi file ini.
INF
[DestinationDirs]
; Update the destination to DIRID 13
[ExampleDDInstall]
[Example_CopyFiles]
ExampleBinary.sys
; Point at the run from Driver Store file using DIRID 13
Biner driver UMDF

Jika INF Anda menambahkan driver UMDF dan biner tidak dijalankan dari Driver Store,
maka INF Anda mungkin terlihat seperti:
INF
[DestinationDirs]
; Copy the file to %windir%\system32\drivers\UMDF
Example_CopyFiles = 12, UMDF
[ExampleDDInstall]
[Example_CopyFiles]
ExampleUmdfDriver.dll
[ExampleDDInstall.Wdf]
UmdfService = ExampleUmdfDriver,Example_UMDF_Inst
...
[Example_UMDF_Inst]
; Point at the file in %windir%\system32\drivers\UMDF
ServiceBinary = %12%\UMDF\ExampleUmdfDriver.dll
...
memperbarui entri DestinationDirs tempat file akan disalin dan memperbarui arahan
ServiceBinary yang merujuk lokasi file ini.
INF
[DestinationDirs]
; Update the destination to DIRID 13
[ExampleDDInstall]
[Example_CopyFiles]
ExampleUmdfDriver.dll
[ExampleDDInstall.Wdf]
UmdfService = ExampleUmdfDriver,Example_UMDF_Inst
...
[Example_UMDF_Inst]
ServiceBinary = %13%\ExampleUmdfDriver.dll
...
File lain
Jika INF Anda menambahkan file yang mungkin dimuat oleh komponen lain dan tidak
dijalankan dari Driver Store, maka INF Anda mungkin terlihat seperti berikut ini. Dalam
contoh ini, hanya nama file yang ditulis ke status registri perangkat. Komponen yang
membaca nilai registri ini untuk menentukan file apa yang akan dimuat tergantung pada
file yang berada di %windir%\system32 atau bergantung pada urutan pencarian
LoadLibrary yang dapat menemukan file.
INF
[DestinationDirs]
; Copy the file to %windir%\system32
[ExampleDDInstall]
CopyFiles=Example_CopyFiles
AddReg=Example_AddReg
[Example_CopyFiles]
ExampleFile.dll
[Example_AddReg]
HKR,,FileLocation,,"ExampleFile.dll"
memperbarui entri DestinationDirs tempat file akan disalin dan memperbarui lokasi
yang disimpan dalam status perangkat. Ini mengharuskan komponen yang membaca
nilai registri tersebut untuk dapat menangani nilai registri tersebut menjadi jalur lengkap
ke file alih-alih file yang relatif terhadap %windir%\system32 .
INF
[DestinationDirs]
Example_CopyFiles = 13 ; update the destination to DIRID 13
[ExampleDDInstall]
CopyFiles=Example_CopyFiles
AddReg=Example_AddReg
[Example_CopyFiles]
ExampleFile.dll
[Example_AddReg]
HKR,,FileLocation,,"%13%\ExampleFile.dll"
Mendukung beberapa versi sistem

operasi
Paket driver umumnya akan mendukung banyak versi sistem operasi Windows. Sebagai
bagian dari mendukung beberapa versi sistem operasi, paket driver mungkin perlu
memiliki perilaku yang berbeda pada versi sistem operasi yang berbeda untuk
menggunakan fitur baru atau untuk memenuhi persyaratan baru dari versi sistem
operasi baru. Misalnya, paket driver mungkin ingin memiliki perilaku yang berbeda pada
sistem operasi setelah versi tertentu untuk memenuhi persyaratan driver Windows.
Bagian berikut menjelaskan bagaimana Anda dapat memiliki perilaku yang berbeda baik
dalam file INF paket driver maupun dalam perilaku runtime biner dalam paket driver.
Dukungan INF
Dekorasi TargetOSVersion pada bagian model INF di INF memungkinkan penulis INF
untuk memberikan instruksi dan pengaturan penginstalan yang berbeda untuk berbagai
versi sistem operasi.
Lihat Menggabungkan ekstensi platform dengan versi sistem operasi untuk informasi
selengkapnya.
Dukungan runtime
Saat mencoba mengubah perilaku saat runtime untuk mendukung beberapa versi
sistem operasi, disarankan untuk memeriksa fitur atau ketersediaan API jika
memungkinkan alih-alih mencoba memeriksa apakah kode berjalan pada versi sistem
operasi tertentu atau yang lebih baru. Misalnya, jika ada API yang ingin Anda gunakan
jika tersedia, Anda dapat mencoba menemukannya secara dinamis alih-alih
menautkannya secara statis. Jika Anda dapat menemukannya, Anda dapat
menggunakannya, namun, jika tidak ada di lingkungan Anda saat ini, Anda dapat
kembali ke beberapa perilaku alternatif.
Mode kernel
Untuk mode kernel, lihat Menulis driver untuk versi Windows yang berbeda untuk
informasi selengkapnya tentang cara mendukung beberapa versi Windows dari satu
driver.
Mode pengguna
Dalam mode pengguna, Anda dapat menggunakan LoadLibraryEx bersama dengan
GetProcAddress untuk memeriksa apakah API tertentu yang ingin Anda gunakan
tersedia di lingkungan yang sedang berjalan dan untuk mendapatkan penunjuk fungsi
untuk digunakan untuk memanggil API tersebut. Lihat Penautan dinamis run-time dan
Menggunakan penautan dinamis run-time untuk informasi selengkapnya.
API Layering
Gambaran Umum
API Layering mensyaratkan bahwa binari dalam paket Driver Windows hanya memanggil
API dan DDI yang termasuk dalam edisi Windows 10 berbasis UWP atau berasal dari
serangkaian API Win32 yang dikuratori. API Layering adalah perpanjangan dari
persyaratan "U" sebelumnya yang merupakan bagian dari prinsip desain DCHU.
Untuk melihat platform mana yang didukung API, kunjungi halaman dokumentasi untuk
API dan periksa entri Platform Target di bagian Persyaratan. Windows Driver hanya
boleh menggunakan API atau DDI yang memiliki Platform Target yang terdaftar sebagai
Universal , yang berarti subset fungsionalitas yang tersedia di semua penawaran
Windows.
Halaman Windows API Sets menjelaskan serangkaian praktik dan alat terbaik untuk
menentukan apakah API tersedia di platform tertentu.
Memvalidasi Layering API

ApiValidator adalah alat utama yang digunakan untuk memvalidasi kepatuhan API
Layering untuk Driver Windows. ApiValidator kapal sebagai bagian dari Windows Driver
Kit (WDK).
Lihat Memvalidasi Driver Windows untuk detail selengkapnya tentang menggunakan

ApiValidator untuk memverifikasi bahwa Driver Windows memenuhi persyaratan
Layering API.
Membangun sopir Windows
Anda dapat menggunakan Microsoft Visual Studio 2019 bersama dengan Windows
Driver Kit (WDK) Versi 2004 untuk membangun Driver Windows. Anda dapat
mengunduh kit dan alat dari Windows Hardware Dev Center .
Dalam banyak kasus, Anda dapat mengolah ulang driver mode kernel warisan sebagai
Driver Windows, selama driver tidak berfungsi dengan komponen mode pengguna apa
pun. Driver WDM dan KMDF warisan harus dikombinasikan ulang sebagai driver
Windows yang menargetkan Windows 10 tanpa perlu konversi. Meskipun driver dapat
dikompilasi tanpa konversi apa pun, ini tidak berarti bahwa driver memenuhi semua
persyaratan driver Windows. Silakan lihat Memulai driver Windows untuk detail
mengenai persyaratan Driver Windows.
Sebaliknya, driver mode pengguna yang ada mungkin memerlukan modifikasi untuk
dikompilasi sebagai driver Windows. Secara khusus, paket driver Anda tidak boleh
memiliki dependensi di luar UWP. Misalnya, hanya beberapa API Win32 yang
merupakan bagian dari UWP.
Mengonversi proyek driver yang ada menjadi

proyek driver Windows
1. Pada Visual Studio 2019, buka proyek driver yang ada.
2. Di panel Penjelajah Solusi, pilih dan tahan (atau klik kanan) solusi dan pilih
Configuration Manager. Atur sistem operasi target ke Windows 10.
3. Pilih dan tahan (atau klik kanan) proyek driver dan pilih Properti. Di bawah
Configuration Properties-Driver>, verifikasi bahwa Platform Target diatur ke
driver Windows. Untuk membuat driver yang berjalan pada Windows 10 hanya
untuk edisi Desktop, pilih Desktop.
4. Bangun drivernya. Anda mungkin melihat kesalahan linker.
5. Perbaiki kesalahan satu per satu dengan melalui log kesalahan. Lihat halaman
referensi individual dalam dokumentasi untuk kemungkinan API alternatif. Jika
penggantian tidak tersedia, Anda mungkin perlu mendesain ulang driver Anda.
Membuat Project Driver Windows Baru di

Microsoft Visual Studio
1. Buat driver baru dari templat (File-New> Project-Create> New Project-Project>
Type-Driver-Select>> the template of interest).
2. Setelah Anda membuat proyek, di panel Penjelajah Solusi, pilih dan tahan (atau klik
kanan) solusi dan pilih Configuration Manager. Atur Konfigurasi solusi aktif ke
versi Windows target yang diinginkan, dan atur Platform solusi aktif ke Win32
atau x64. Jika Arm tidak terdaftar, pilih <Baru...> untuk membangun arm.
Jika Anda memilih Windows 10, model driver default ke Universal.
Untuk mengubah model driver secara manual, pilih dan tahan (atau klik kanan)
proyek driver dan pilih Properti. Di bawah Konfigurasi Properties-Driver>
Pengaturan-General>, temukan entri Platform Target. Pilih Driver Windows.
Microsoft Visual Studio menggunakan pengaturan ini untuk menentukan pustaka
apa yang akan ditautkan.
Catatan Anda tidak dapat membuat Driver Windows untuk versi Windows yang
lebih lama dari Windows 10 Versi 1809.
3. Anda mungkin perlu mengubah file .inf untuk menentukan penyedia, yang
ditentukan sebagai token %ManufacturerName% yang diperluas nanti di bagian
String file INF. Contohnya:
C++
Provider="Contoso"
4. Anda sekarang dapat membangun solusi. Visual Studio tautan terhadap pustaka
yang diperlukan dan menghasilkan file .cat, file .inf, dan biner driver.
Membuat Aplikasi Universal Baru atau Project

DLL di Microsoft Visual Studio
1. Buat driver baru dari templat (File-New> Project-Create> New Project-Project>
Type-Driver-Select>> template of interest) dan pilih Empty Desktop Application
for Drivers (Universal) atau Empty Dll for Drivers (Universal).
2. Setelah Anda membuat proyek, di panel Penjelajah Solusi, pilih dan tahan (atau klik
kanan) solusi dan pilih Configuration Manager. Atur Konfigurasi solusi aktif ke
versi Windows target yang diinginkan, dan atur Platform solusi aktif ke Win32
atau x64. Jika Arm tidak terdaftar, pilih <Baru...> untuk membangun arm.
Jika
Anda memilih Windows 10, model aplikasi default ke Universal.
Untuk mengubah
platform target secara manual, pilih dan tahan (atau klik kanan) proyek driver dan
pilih Properti. Di bawah Konfigurasi Properties-Driver> Pengaturan-General>,
temukan entri Platform Target.
3. Bangun solusinya.
Untuk informasi tentang pengaturan konfigurasi yang dapat Anda gunakan di Visual
Studio saat membangun driver Anda, lihat Membangun Driver dengan WDK.
Memvalidasi Driver Windows
Gunakan alat InfVerif, Driver Verifier Driver Isolation Checks, dan ApiValidator untuk
menguji Driver Windows Anda untuk mematuhi persyaratan yang dijelaskan dalam
Memulai driver Windows.
InfVerif
InfVerif adalah alat yang memvalidasi sintaks INF dan memeriksa apakah INF sesuai
dengan persyaratan dan batasan.
Gunakan InfVerif dengan /w dan /v untuk memverifikasi bahwa Driver Windows:
Memenuhi prinsip deklaratif (D)dari Prinsip Desain DCH

Mematuhi persyaratan isolasi paket driver untuk Memulai driver Windows
Untuk detail selengkapnya, lihat Menjalankan InfVerif dari baris perintah.
Menargetkan versi Windows saat ini dan yang lebih lama

Setiap eksekusi InfVerif menguji satu set aturan, misalnya /w (Windows kompatibilitas
driver) atau /k (pengiriman Hardware Dev Center). Jika INF Anda berisi sintaks yang
diperkenalkan dalam versi Windows yang lebih baru dan Anda juga ingin menargetkan
versi Windows sebelumnya, gunakan dekorasi INF untuk menandai entri INF khusus
versi lalu jalankan InfVerif beberapa kali, misalnya:
INF
infverif /k <INF file>
infverif /w NTAMD64.10.0.0.<build number where w is a requirement> <INF

file>
Jika tidak ada kesalahan, INF memenuhi persyaratan Isolasi Paket Driver Windows Driver.
Misalnya, INF AddEventProvider Directive tersedia mulai dari Windows 10, versi 1809.
Untuk menggunakan direktif ini dalam INF yang menargetkan versi OS sebelum
Windows 10, versi 1809, hiasi kedua bagian penginstalan menggunakan sintaks INF
warisan untuk mendaftarkan penyedia peristiwa ETW serta bagian penginstalan
menggunakan sintaks yang diperbarui.
Untuk kode sampel yang menunjukkan cara menggunakan dekorasi OS, lihat
Menggabungkan Ekstensi Platform dengan Versi Sistem Operasi.
Pemeriksaan Isolasi Driver Verifier Driver

Agar memenuhi syarat sebagai Driver Windows, pengemudi harus memenuhi
persyaratan Isolasi Paket Driver. Mulai Windows 10 Preview Build 19568, Driver Verifier
(DV) memantau pembacaan dan penulisan registri yang tidak diizinkan untuk paket
driver yang terisolasi.
Anda dapat melihat pelanggaran saat terjadi dalam debugger kernel, atau Anda dapat
mengonfigurasi DV untuk menghentikan sistem dan menghasilkan cadangan memori
dengan detail ketika pelanggaran terjadi. Anda dapat memulai pengembangan driver
dengan metode pertama, lalu beralih ke yang kedua saat driver Anda mendekati
penyelesaian.
Untuk melihat pelanggaran saat terjadi, pertama-tama sambungkan debugger kernel

lalu gunakan perintah berikut. Setelah reboot mengaktifkan pengaturan DV, Anda dapat
memantau pelanggaran dalam output debugger kernel.
Untuk mengaktifkan pemeriksaan isolasi driver pada satu driver:
command
verifier /rc 33 36 /driver myDriver.sys
Untuk memeriksa lebih dari satu driver, pisahkan setiap nama driver dengan spasi:
command
verifier /rc 33 36 /driver myDriver1.sys myDriver2.sys
Untuk mengonfigurasi DV ke bugcheck saat pelanggaran terjadi, gunakan sintaks

berikut:
verifier /onecheck /rc 33 36 /driver myDriver1.sys
Anda harus melakukan boot ulang untuk mengaktifkan pengaturan verifikasi. Untuk
melakukan ini dari baris perintah, tentukan:
command
shutdown /r /t 0
Berikut adalah beberapa contoh pesan kesalahan:
Contoh: ZwCreateKey menyediakan jalur absolut penuh:
DRIVER_ISOLATION_VIOLATION: <driver name>: Registry operations should not use
absolute paths. Detected creation of unisolated registry key
\Registry\Machine\SYSTEM
Contoh: ZwCreateKey menyediakan jalur yang relatif terhadap handel yang bukan dari
API yang disetujui:
DRIVER_ISOLATION_VIOLATION: <driver name>: Registry operations should only use key
handles returned from WDF or WDM APIs. Detected creation of unisolated registry key
\REGISTRY\MACHINE\SYSTEM\SomeKeyThatShouldNotExist
Pertimbangkan untuk mengaktifkan pengujian Dasar-Dasar Perangkat dengan

pemeriksaan isolasi driver DV untuk membantu menangkap pelanggaran isolasi driver
lebih awal.
ApiValidator
Alat ApiValidator memverifikasi bahwa API yang dipanggil biner Anda valid untuk Driver
Windows. Alat ini mengembalikan kesalahan jika biner Anda memanggil API yang
berada di luar set API yang valid untuk Driver Windows. Alat ini adalah bagian dari WDK
untuk Windows 10.
ApiValidator memvalidasi bahwa driver mendukung Lapisan API, salah satu persyaratan
untuk driver Windows. Untuk daftar lengkap persyaratan, lihat Memulai driver Windows.
Menjalankan ApiValidator di Visual Studio

Jika properti Platform Target dari proyek driver Anda diatur ke driver Windows, Visual
Studio menjalankan ApiValidator secara otomatis sebagai langkah pasca-build.
Untuk melihat semua pesan yang ditampilkan oleh ApiValidator, navigasikan ke Tools-
Options-Projects>> dan Solutions-Build> and Run, dan atur verbositas output build
proyek MSBuild ke Terperinci. Saat membangun dari baris perintah, tambahkan sakelar
/v:detail atau /v:diag ke perintah build Anda untuk meningkatkan verbositas.
Untuk sampel driver umdf2_fx2, kesalahan validasi API lihat ini:

C++
Warning 1 warning : API DecodePointer in kernel32.dll is not supported.

osrusbfx2um.dll calls this API. C:\Program Files (x86)\Windows
Kits\10\src\usb\umdf2_fx2\driver\ApiValidator.exe osrusbfx2um
Warning 2 warning : API DisableThreadLibraryCalls in kernel32.dll is not

supported. osrusbfx2um.dll calls this API. C:\Program Files (x86)\Windows
Warning 3 warning : API EncodePointer in kernel32.dll is not supported.

osrusbfx2um.dll calls this API. C:\Program Files (x86)\Windows
Warning 4 warning : API GetCurrentProcessId in kernel32.dll is not

Warning 5 warning : API GetCurrentThreadId in kernel32.dll is not

Warning 6 warning : API GetSystemTimeAsFileTime in kernel32.dll is not

Warning 7 warning : API IsDebuggerPresent in kernel32.dll is not

Warning 8 warning : API IsProcessorFeaturePresent in kernel32.dll is not

Warning 9 warning : API QueryPerformanceCounter in kernel32.dll is not

Error 10 error MSB3721: The command ""C:\Program Files (x86)\Windows

Kits\10\bin\x64\ApiValidator.exe" -DriverPackagePath:"C:\Program Files
(x86)\Windows Kits\10\src\usb\umdf2_fx2\Debug\\" -
SupportedApiXmlFiles:"C:\Program Files (x86)\Windows
Kits\10\build\universalDDIs\x86\UniversalDDIs.xml" -
ApiExtractorExePath:"C:\Program Files (x86)\Windows Kits\10\bin\x64"" exited
with code -1. C:\Program Files (x86)\Windows
Kits\10\build\WindowsDriver.common.targets 1531 5 osrusbfx2um
Memperbaiki kesalahan validasi

1. Jika Anda mengalihkan proyek driver UMDF desktop warisan ke driver Windows,
verifikasi bahwa Anda menyertakan pustaka yang benar saat membangun biner
Anda. Pilih dan tahan (atau klik kanan) proyek dan pilih properti. Navigasi ke
Linker-Input>. Dependensi Tambahan harus berisi:
C++
%AdditionalDependencies);$(SDK_LIB_PATH)\OneCoreUAP.lib
Untuk meninjau opsi linker lain untuk menargetkan SKU OneCore, lihat
Membangun untuk OneCore.
2. Hapus atau ganti panggilan API yang tidak diizinkan satu per satu dan jalankan
ulang alat sampai tidak ada kesalahan.
3. Dalam beberapa kasus, Anda dapat mengganti panggilan ini dengan DDI alternatif
yang tercantum di halaman referensi untuk DDI khusus desktop. Anda mungkin
harus membuat kode solusi jika tidak ada pengganti yang sesuai. Jika perlu, tulis
Driver Windows baru mulai dari templat driver di WDK.
Jika Anda melihat kesalahan seperti berikut ini, silakan lihat panduan di Membangun
untuk OneCore.
C++
ApiValidation: Error: FlexLinkTest.exe has a dependency on

'wtsapi32.dll!WTSEnumerateSessionsW' but is missing:
IsApiSetImplemented("ext-ms-win-session-wtsapi32-l1-1-0")

'wtsapi32.dll!WTSFreeMemory' but is missing: IsApiSetImplemented("ext-ms-
win-session-wtsapi32-l1-1-0")
ApiValidation: NOT all binaries are Universal
Menjalankan ApiValidator dari Prompt Perintah

Anda juga dapat menjalankan Apivalidator.exe dari prompt perintah. Dalam
penginstalan WDK Anda, navigasikan ke C:\Program Files (x86)\Windows
Kits\10\binarch<> dan C:\Program Files (x86)\Windows
Kits\10\build\universalDDIsarch<>.
Catatan Penting:
ApiValidator memerlukan file berikut: ApiValidator.exe, Aitstatic.exe,

Microsoft.Kits.Drivers.ApiValidator.dll, dan UniversalDDIs.xml.
UniversalDDIs.xml harus cocok dengan arsitektur biner yang sedang divalidasi,
misalnya untuk driver x64 menggunakan UniversalDDI.xml x64
ApiValidator hanya menguji satu arsitektur pada satu waktu
Lihat Masalah ApiValidator yang diketahui di bawah ini untuk info tambahan
Gunakan sintaks berikut:
Apivalidator.exe -DriverPackagePath: <driver folder path> -SupportedApiXmlFiles:

(path to XML files containing supported APIs for Windows drivers)
Misalnya, untuk memverifikasi API yang dipanggil oleh sampel Aktivitas di WDK,
pertama-tama buat sampel di Visual Studio. Kemudian buka perintah dan navigasikan
ke direktori yang berisi alat, misalnya C:\Program Files (x86\Windows Kits\10\bin\x64 .
Masukkan perintah berikut:
apivalidator.exe -DriverPackagePath:"C:\Program Files (x86)\Windows
Kits\10\src\usb\umdf2\_fx2\Debug" -SupportedApiXmlFiles:"c:\Program Files
(x86)\Windows Kits\10\build\universalDDIs\x64\UniversalDDIs.xml"
Perintah menghasilkan output berikut:
C++
ApiValidator.exe: Warning: API DecodePointer in kernel32.dll is not

supported. osrusbfx2um.dll calls this API.
ApiValidator.exe: Warning: API DisableThreadLibraryCalls in kernel32.dll is

not supported. osrusbfx2um.dll calls this API.
ApiValidator.exe: Warning: API EncodePointer in kernel32.dll is not

ApiValidator.exe: Warning: API GetCurrentProcessId in kernel32.dll is not

ApiValidator.exe: Warning: API GetCurrentThreadId in kernel32.dll is not

ApiValidator.exe: Warning: API GetSystemTimeAsFileTime in kernel32.dll is

ApiValidator.exe: Warning: API IsDebuggerPresent in kernel32.dll is not

ApiValidator.exe: Warning: API IsProcessorFeaturePresent in kernel32.dll is

ApiValidator.exe: Warning: API QueryPerformanceCounter in kernel32.dll is

ApiValidator.exe Driver located at C:\Program Files (x86)\Windows

Kits\10\src\usb\umdf2_fx2\Debug is NOT a Universal Driver
Pemecahan Masalah ApiValidator

Jika ApiValidator.exe menghasilkan kesalahan format yang salah seperti berikut ini:
C++
Error 1 error : AitStatic output file has incorrect format

or analysis run on incorrect file types. C:\Program Files (x86)\Windows
Gunakan solusi ini:

1. Buka properti Project, navigasikan ke Umum, dan ganti nama Direktori Output
menjadi yang berikut ini:
C++
$(SolutionDir)$(Platform)\$(ConfigurationName)\
2. Bangun kembali solusinya.
Masalah ApiValidator yang Diketahui

ApiValidator tidak berjalan di Arm64 karena AitStatic tidak berfungsi di Arm64.
Biner Arm64 dapat diuji pada mesin x64 tetapi tidak pada mesin x86.
ApiValidator dapat berjalan pada x86 untuk menguji biner x86 dan biner Arm.
ApiValidator dapat berjalan pada x64 untuk menguji biner x86, x64, Arm, dan
Arm64.
Contoh Paket Driver DCH-Compliant
Topik ini menjelaskan bagaimana sampel driver DCHU menerapkan prinsip desain
DCH. Anda dapat menggunakannya sebagai model untuk menerapkan prinsip desain
DCH ke paket driver Anda sendiri.
Jika Anda ingin salinan lokal repositori sampel, kloning dari Windows-driver-samples .
Beberapa bagian sampel dapat menggunakan direktif dan API yang hanya tersedia pada
versi Windows 10 dan di atasnya. Silakan lihat Penginstalan Perangkat dan Driver untuk
melihat versi OS apa yang didukung oleh direktif tertentu.
Prasyarat
Sebelum Anda membaca bagian ini, Anda harus terbiasa dengan Prinsip Desain DCH.
Gambaran Umum
Sampel menyediakan contoh skenario di mana dua mitra perangkat keras, Contoso
(pembuat sistem, atau OEM) dan Fabrikam (produsen perangkat, atau IHV) bekerja sama
untuk membuat driver yang sesuai dengan DCH untuk perangkat dalam sistem Contoso
yang akan datang. Perangkat yang dimaksud adalah kit pembelajaran OSR USB FX2 .
Di masa lalu, Fabrikam akan menulis paket driver warisan yang disesuaikan dengan lini
produk Contoso tertentu, dan kemudian menyerahkannya ke OEM untuk menangani
layanan. Ini menghasilkan overhead pemeliharaan yang signifikan, sehingga Fabrikam
memutuskan untuk merefaktor kode dan membuat paket driver yang mematuhi DCH
sebagai gantinya.
Gunakan bagian/arahan deklaratif dan isolasi

INF dengan benar
Pertama, Fabrikam meninjau daftar bagian dan arahan INF yang tidak valid dalam paket
driver yang mematuhi DCH. Selama latihan ini, Fabrikam memperhatikan bahwa mereka
menggunakan banyak bagian dan arahan ini dalam paket driver mereka.
DRIVER INF mereka mendaftarkan penginstal bersama yang menerapkan pengaturan

dan file yang bergantung pada platform. Ini berarti bahwa paket driver lebih besar dari
yang seharusnya, dan lebih sulit untuk melayani driver ketika bug hanya memengaruhi
subset sistem OEM yang mengirim driver. Selain itu, sebagian besar modifikasi khusus
OEM terkait dengan branding, sehingga Fabrikam perlu memperbarui paket driver
setiap kali OEM ditambahkan atau ketika masalah kecil memengaruhi subset sistem
OEM.
Fabrikam menghapus bagian dan arahan non-deklaratif dan menggunakan alat InfVerif
untuk memverifikasi bahwa file INF paket driver baru mengikuti persyaratan INF
deklaratif.
Menggunakan INF ekstensi untuk

menginisialisasi paket driver
Selanjutnya, Fabrikam memisahkan kustomisasi yang khusus untuk mitra OEM (seperti
Contoso) dari paket driver dasar menjadi INF ekstensi.
Cuplikan berikut, yang diperbarui dari [ osrfx2_DCHU_extension.inx ], menentukan

Extension kelas dan mengidentifikasi Contoso sebagai penyedia karena mereka akan
memiliki paket driver ekstensi:
INF
[Version]
Class = Extension
ClassGuid = {e2f84ce7-8efa-411c-aa69-97454ca4cb57}
Provider = Contoso
ExtensionId = {zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz} ; replace with your own

GUID
Dalam [ osrfx2_DCHU_base.inx ], Fabrikam menentukan entri berikut:
INF
[OsrFx2_AddReg]
HKR, OSR, "OperatingMode",, "Default" ; FLG_ADDREG_TYPE_SZ
HKR, OSR, "OperatingParams",, "None" ; FLG_ADDREG_TYPE_SZ
Di [ osrfx2_DCHU_extension.inx ], Contoso mengambil alih nilai registri OperatingParams

yang ditetapkan oleh basis dan menambahkan OperatingExceptions:
INF
[OsrFx2Extension_AddReg]
HKR, OSR, "OperatingParams",, "-Extended"
HKR, OSR, "OperatingExceptions",, "x86"
Perhatikan bahwa ekstensi selalu diproses setelah INF dasar tetapi tidak dalam urutan
yang pasti. Jika INF dasar diperbarui ke versi yang lebih baru, ekstensi masih akan
diterapkan kembali setelah INF dasar baru diinstal.
Menginstal layanan dari file INF

Fabrikam menggunakan layanan Win32 untuk mengontrol LED pada papan OSR.
Mereka melihat komponen ini sebagai bagian dari fungsionalitas inti perangkat,
sehingga mereka menyertakannya sebagai bagian dari INF dasar mereka
([ osrfx2_DCHU_base.inx ]). Layanan mode pengguna (usersvc) ini dapat ditambahkan dan
dimulai secara deklaratif dengan menentukan arahan AddService dalam file INF:
INF
[OsrFx2_Install.NT]
CopyFiles = OsrFx2_CopyFiles
[OsrFx2_Install.NT.Services]
AddService = WUDFRd, 0x000001fa, WUDFRD_ServiceInstall ; Flag 0x2 sets

this as the service for the device
AddService = osrfx2_DCHU_usersvc,, UserSvc_ServiceInstall
[UserSvc_ServiceInstall]
DisplayName = %UserSvcDisplayName%
ServiceType = 0x10 ;
SERVICE_WIN32_OWN_PROCESS
StartType = 0x3 ; SERVICE_DEMAND_START
ErrorControl = 0x1 ; SERVICE_ERROR_NORMAL
ServiceBinary = %13%\osrfx2_DCHU_usersvc.exe
AddTrigger = UserSvc_AddTrigger ; AddTrigger syntax is

only available in Windows 10 Version 2004 and above
[UserSvc_AddTrigger]
TriggerType = 1 ;
SERVICE_TRIGGER_TYPE_DEVICE_INTERFACE_ARRIVAL
Action = 1 ;
SERVICE_TRIGGER_ACTION_SERVICE_START
SubType = %GUID_DEVINTERFACE_OSRFX2% ; Interface GUID
DataItem = 2, "USB\VID_0547&PID_1002" ;
SERVICE_TRIGGER_DATA_TYPE_STRING
[OsrFx2_CopyFiles]
osrfx2_DCHU_base.dll
osrfx2_DCHU_filter.dll
osrfx2_DCHU_usersvc.exe
Perhatikan bahwa layanan seperti itu juga dapat diinstal dalam INF komponen atau
ekstensi, tergantung pada skenarionya.
Menggunakan komponen untuk menginstal
perangkat lunak warisan dari paket driver
Fabrikam memiliki file osrfx2_DCHU_componentsoftware.exe yang dapat dieksekusi yang
sebelumnya diinstal menggunakan penginstal bersama. Perangkat lunak warisan ini
menampilkan kunci registri yang ditetapkan oleh papan dan diperlukan oleh OEM. Ini
adalah executable berbasis GUI yang hanya berjalan pada Windows untuk edisi desktop.
Untuk menginstalnya, Fabrikam membuat paket driver komponen terpisah dan
menambahkannya di INF ekstensi mereka.
Cuplikan berikut dari [ osrfx2_DCHU_extension.inx ] menggunakan direktif

AddComponent untuk membuat perangkat anak virtual:
INF
[OsrFx2Extension_Install.NT.Components]
AddComponent = osrfx2_DCHU_component,,OsrFx2Extension_ComponentInstall
[OsrFx2Extension_ComponentInstall]
ComponentIds=VID_045e&PID_94ab
Kemudian, dalam komponen INF [ osrfx2_DCHU_component.inx ], Fabrikam menentukan

direktif AddSoftware untuk menginstal executable opsional:
INF
[OsrFx2Component_Install.NT.Software]
AddSoftware = osrfx2_DCHU_componentsoftware,,
OsrFx2Component_SoftwareInstall
[OsrFx2Component_SoftwareInstall]
SoftwareType = 1
SoftwareBinary = osrfx2_DCHU_componentsoftware.exe
SoftwareArguments = <<DeviceInstanceId>>
SoftwareVersion = 1.0.0.0
[OsrFx2Component_CopyFiles]
osrfx2_DCHU_componentsoftware.exe
Kode sumber untuk aplikasi Win32 disertakan dalam sampel.
Perhatikan bahwa paket driver komponen hanya didistribusikan pada SKU Desktop
karena penargetan yang ditetapkan di dasbor Windows Hardware Dev Center . Untuk
informasi selengkapnya, lihat Menerbitkan driver ke Windows Update.
Mengizinkan komunikasi dengan aplikasi
dukungan perangkat keras
Fabrikam ingin menyediakan aplikasi pendamping berbasis GUI sebagai bagian dari
paket Driver Windows. Karena aplikasi pendamping berbasis Win32 tidak dapat menjadi
bagian dari paket Driver Windows, mereka memindahkan aplikasi Win32 mereka ke
Universal Windows Platform (UWP) dan memasangkan aplikasi dengan perangkat.
Cuplikan berikut dari osrfx2_DCHU_base/device.c menunjukkan bagaimana paket

driver dasar menambahkan kemampuan kustom ke instans antarmuka perangkat:
C++
WDF_DEVICE_INTERFACE_PROPERTY_DATA PropertyData = { 0 };
static const wchar_t customCapabilities[] =

L"CompanyName.yourCustomCapabilityName_YourStorePubId\0";
WDF_DEVICE_INTERFACE_PROPERTY_DATA_INIT(&PropertyData,
&GUID_DEVINTERFACE_OSRUSBFX2,
&DEVPKEY_DeviceInterface_UnrestrictedAppCapabilities);
Status = WdfDeviceAssignInterfaceProperty(Device,
&PropertyData,
DEVPROP_TYPE_STRING_LIST,
sizeof(customCapabilities),
(PVOID)customCapabilities);
Aplikasi baru (tidak termasuk dalam sampel) aman dan dapat diperbarui dengan mudah
di Microsoft Store. Dengan aplikasi UWP siap, Contoso menggunakan DISM -
Deployment Image Servicing and Management untuk memuat aplikasi terlebih dahulu
pada gambar edisi Windows Desktop.
Menghubungkan beberapa file INF dengan erat

Idealnya, harus ada kontrak penerapan versi yang kuat antara dasar, ekstensi, dan
komponen. Ada keuntungan layanan dalam memiliki ketiga paket ini dilayankan secara
independen (skenario "digabungkan secara longgar"), tetapi ada skenario di mana
mereka perlu dibundel dalam satu paket driver ("digabungkan erat") karena kontrak
penerapan versi yang buruk. Sampel mencakup contoh kedua skenario:
DCHU_Sample\osrfx2_DCHU_extension_loose
DCHU_Sample\osrfx2_DCHU_extension_tight
Ketika ekstensi dan komponen berada dalam paket driver yang sama
("digabungkan erat"), ekstensi INF menentukan arahan CopyINF untuk
menyebabkan INF komponen disalin ke sistem target. Ini ditunjukkan dalam
DCHU_Sample\osrfx2_DCHU_extension_tight\osrfx2_DCHU_extension\osrfx2_DCH
U_extension.inx :
INF
[OsrFx2Extension_Install.NT]
CopyInf=osrfx2_DCHU_component.inf
Arahan ini juga dapat digunakan untuk mengoordinasikan penginstalan file INF di
perangkat multifungsi. Untuk detail selengkapnya, lihat Menyalin file INF.
７ Catatan
Meskipun driver dasar dapat memuat ekstensi (dan menargetkan driver dasar di
label pengiriman), ekstensi yang dibundel dengan driver lain tidak dapat
diterbitkan ke ID perangkat keras ekstensi.
Jalankan dari Driver Store

Untuk mempermudah pembaruan driver, Fabrikam menentukan Driver Store sebagai
tujuan untuk menyalin file driver dengan menggunakan dirid 13 jika memungkinkan.
Menggunakan nilai direktori tujuan 13 dapat mengakibatkan peningkatan stabilitas
selama proses pembaruan driver. Berikut adalah contoh dari [ osrfx2_DCHU_base.inx ]:
INF
[DestinationDirs]
OsrFx2_CopyFiles = 13 ; copy to Driver Store
Lihat halaman jalankan dari Driver Store untuk detail selengkapnya mengenai cara
menemukan dan memuat file secara dinamis dari Driver Store.
Ringkasan
Diagram berikut menunjukkan paket driver yang dibuat Fabrikam dan Contoso untuk
driver yang mematuhi DCH mereka. Dalam contoh yang digabungkan secara longgar,
mereka akan membuat tiga pengiriman terpisah di dasbor Windows Hardware Dev
Center : satu untuk basis, satu untuk ekstensi, dan satu untuk komponen. Dalam
contoh yang digabungkan dengan erat, mereka akan membuat dua pengiriman: dasar
dan ekstensi/komponen.
Perhatikan bahwa INF komponen akan cocok pada ID perangkat keras komponen,
sedangkan basis dan ekstensi akan cocok pada ID perangkat keras papan.
Lihat juga
Memulai Driver Windows
Menggunakan File INF Ekstensi
osrfx2_DCHU_base.inx
"digabungkan secara longgar" osrfx2_DCHU_component.inx
"digabungkan secara longgar" osrfx2_DCHU_extension.inx
"digabungkan erat" osrfx2_DCHU_component.inx
"digabungkan erat" osrfx2_DCHU_extension.inx

Debugging Driver Windows
Untuk informasi umum tentang driver debugging, lihat Memulai dengan debugging
Windows.
Perekam Jejak Dalam Pesawat

Mulai Windows 10, Anda dapat membangun biner driver KMDF atau UMDF Anda
sehingga mendapat informasi debugging driver tambahan melalui Inflight Trace
Recorder. Windows Driver dapat memanfaatkan fitur ini.
Selain itu, jika Anda menggunakan template KMDF Visual Studio, driver Anda
menggunakan Windows software trace preprocessor (WPP) untuk menulis pesan jejak.
Biner driver Anda adalah penyedia ETW dengan penyedia GUID.
Untuk mengirim pesan jejak dari biner driver Anda, gunakan kode ini:
C++
TraceEvents(TRACE_LEVEL_INFORMATION, TRACE_DRIVER, "%!FUNC! Entry");
Anda dapat mengakses log ETW menggunakan Tracelog dengan menggunakan

!wmitrace dalam sesi debugger.
Memindahkan INF untuk mengikuti
isolasi paket driver
Artikel ini dimaksudkan untuk menjadi panduan pencarian cepat untuk membantu Anda
memperbarui file INF untuk mengikuti isolasi paket driver sebagai bagian dari
memperbarui paket driver Anda menjadi Driver Windows. Bagian berikut memberikan
contoh beberapa hal yang lebih umum yang mungkin Anda miliki dalam file INF paket
driver Anda dengan referensi ke informasi tentang cara memperbaruinya agar sesuai
dengan isolasi paket driver. Jika paket driver Anda perlu mendukung cara lama untuk
melakukan sesuatu untuk versi sistem operasi yang lebih lama saat menggunakan cara
baru pada versi sistem operasi yang lebih baru, lihat Menggabungkan Ekstensi Platform
dengan Versi Sistem Operasi untuk cara mencapainya dalam INF.
DestinationDirs bukan DIRID 13

Jika bagian DestinationDirs Anda menentukan tujuan untuk file yang tidak DIRID 13,
maka INF tidak sesuai dengan isolasi paket driver. Semua file dalam paket driver harus
dijalankan dari Driver Store yang berarti menggunakan DIRID 13. Ini mungkin
memerlukan pembaruan untuk lebih dari sekadar bagian DestinationDirs. Operasi lain
yang dilakukan oleh INF yang merujuk ke file yang dimuat oleh INF mungkin perlu
diperbarui juga. Misalnya, Anda mungkin perlu memperbarui arahan ServiceBinary di
bagian penginstalan layanan yang direferensikan oleh direktif AddService atau nilai
registri yang ditulis oleh direktif AddReg. Secara umum, jalankan dari Driver Store
didukung pada versi Windows Windows 10 1709 dan yang lebih baru, tetapi beberapa
tumpukan perangkat mungkin tidak mendukung file yang dicolokkan ke tumpukan
tersebut yang dijalankan dari Penyimpanan Driver hingga rilis selanjutnya. Untuk
informasi selengkapnya, lihat menjalankan dari Penyimpanan Driver.
Menggunakan AddReg untuk mendaftarkan

penyedia ETW dan saluran EventLog
Jika INF Anda menggunakan direktif AddReg untuk mendaftarkan penyedia ETW dan
saluran EventLog, maka INF tidak sesuai dengan isolasi paket driver. Misalnya, INF Anda
mungkin memiliki:
INF
HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\ExampleProvi
der/Analytic", "OwningPublisher", 0x0, "{35356277-0b54-43da-b324-
671006d74759}"
der/Analytic", "Enabled", 0x00010001, 1
der/Analytic", "Isolation", 0x00010001, 1
der/Analytic", "ChannelAccess",0x0, \
"O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x3;;;BO)(A;;0x5;;;SO)
(A;;0x1;;;IU)(A;;0x3;;;SU)(A;;0x1;;;S-1-5-3)(A;;0x2;;;S-1-5-33)(A;;0x1;;;S-
1-5-32-573)"
der/Analytic", "Type", 0x00010001, 2
HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{35356277-
0b54-43da-b324-671006d74759}" , , 0x0, "ExampleProvider"
0b54-43da-b324-671006d74759}", "ResourceFileName", 0x00020000,
"%13%\ExampleBinary.sys"
0b54-43da-b324-671006d74759}", "MessageFileName", 0x00020000,
"%13%\ExampleBinary.sys"
0b54-43da-b324-671006d74759}\ChannelReferences\0", , 0x0,
"ExampleProvider/Analytic"
0b54-43da-b324-671006d74759}\ChannelReferences\0", "Id", 0x00010001, 16
0b54-43da-b324-671006d74759}\ChannelReferences\0", "Flags", 0x00010001, 0
0b54-43da-b324-671006d74759}\ChannelReferences", Count, 0x00010001, 1
Alih-alih menggunakan AddReg untuk mendaftarkan penyedia ETW dan saluran

EventLog, mereka harus terdaftar menggunakan arahan AddEventProvider dari bagian
DDInstall.Events. Contohnya:
INF
[ExampleDDInstall.Events]
AddEventProvider={35356277-0b54-43da-b324-671006d74759},
Example_EVvntProvider_Inst
[Example_EventProvider_Inst]
ProviderName=ExampleProvider
ResourceFile=%13%\ExampleBinary.sys
MessageFile=%13%\ExampleBinary.sys
AddChannel=ExampleProvider/Analytic,0x3,Example_Channel_Inst ; Note that the

type of the channel here is different than in the raw AddReg. Please see the
AddEventProvider documentation for appropriate values
[Example_Channel_Inst]
Isolation=1
Access="O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x3;;;BO)(A;;0x5;;;SO)
(A;;0x1;;;IU)(A;;0x3;;;SU)(A;;0x1;;;S-1-5-3)(A;;0x2;;;S-1-5-33)(A;;0x1;;;S-
1-5-32-573)"
Enabled=1
Value=16
Menggunakan direktif AddEventProvider dari bagian DDInstall.Events didukung pada

versi Windows Windows 10 1809 dan yang lebih baru.
Menggunakan AddReg untuk mendaftarkan

AutoLogger
Jika INF Anda menggunakan direktif AddReg untuk mendaftarkan atau memodifikasi
ETW AutoLogger, maka INF tidak sesuai dengan isolasi paket driver. Misalnya, INF Anda
mungkin memiliki:
INF
HKLM,SYSTEM\CurrentControlSet\Control\WMI\Autologger\ExampleAutoLogger,
BufferSize, %REG_DWORD%, 0x00000040
GUID, %REG_SZ%, "{6f1373c7-eec8-495c-bfe5-1270336368df}"
Start, %REG_DWORD%, 0x00000001
MaximumBuffers, %REG_DWORD%, 0x00000040
LogFileMode, %REG_DWORD%, 0x400
HKLM,SYSTEM\CurrentControlSet\Control\WMI\Autologger\ExampleAutoLogger\
{35356277-0b54-43da-b324-671006d74759}, EnableLevel, %REG_DWORD%, 0x00000004
{35356277-0b54-43da-b324-671006d74759}, MatchAnyKeyword, %REG_QWORD%,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
{35356277-0b54-43da-b324-671006d74759}, Enabled, %REG_DWORD%, 0x00000001
Alih-alih menggunakan AddReg untuk mendaftarkan atau memperbarui AutoLogger,

addau update harus didaftarkan atau diperbarui menggunakan direktif AddAutoLogger
atau UpdateAutoLogger dari bagian DDInstall.Events. Contohnya:
INF
[ExampleDDInstall.Events]
AddAutoLogger=ExampleAutoLogger,{6f1373c7-eec8-495c-bfe5-
1270336368df},Example_AutoLogger_Inst
[Example_AutoLogger_Inst]
Start=1
BufferSize = 0x40
LogFileMode=0x400
MaximumBuffers=0x40
AddAutoLoggerProvider={35356277-0b54-43da-b324-
671006d74759},Example_AutoLoggerProvider_Inst
[Example_AutoLoggerProvider_Inst]
Enabled=1
EnableLevel=0x4
MatchAnyKeyword=0
Menggunakan direktif AddAutoLogger atau UpdateAutoLogger dari bagian

DDInstall.Events didukung pada versi Windows Windows 11 dan yang lebih baru.
Menggunakan AddReg untuk menambahkan

entri ke kunci RunOnce
Jika INF Anda menggunakan direktif AddReg untuk menambahkan entri ke kunci
RunOnce, maka INF tidak sesuai dengan isolasi paket driver. Misalnya, INF Anda
mungkin memiliki:
INF
[ExampleDDInstall]
AddReg = Example_Registry
[Example_Registry]
HKLM, Software\Microsoft\Windows\CurrentVersion\RunOnce, ExampleEntry,

,"application.exe"
Tidak didukung. INF tidak boleh memodifikasi entri registri global. Jika tindakan
penyiapan satu kali diperlukan saat paket driver diinstal, Anda dapat menggunakan
direktif AddSoftware dari dalam file INF komponen untuk meluncurkannya. Ini hanya
untuk tindakan yang tidak penting. Fungsionalitas penting untuk perangkat atau
perangkat yang diinstal dengan paket driver ini tidak boleh bergantung pada tindakan
yang dijalankan yang berada di luar penginstalan perangkat.
Menggunakan AddReg untuk menambahkan

entri ke kunci Jalankan
Jika INF Anda menggunakan direktif AddReg untuk menambahkan entri ke kunci Run,
maka INF tidak sesuai dengan isolasi paket driver. Misalnya, INF Anda mungkin memiliki:
INF
[ExampleDDInstall]
[Example_Registry]
HKLM, Software\Microsoft\Windows\CurrentVersion\Run, ExampleEntry,

,"application.exe"
Tidak didukung. INF tidak boleh memodifikasi entri registri global. Jika entri Jalankan
adalah menambahkan nilai tambah perangkat lunak ke sistem, aplikasi Anda harus
menjadi aplikasi Universal Windows Platform dan diinstal menggunakan direktif
AddSoftware dari bagian DDInstall.Software. Untuk informasi selengkapnya, lihat
Memasangkan driver dengan aplikasi Universal Windows Platform (UWP). Jika perangkat
lunak ini adalah layanan yang tidak perlu menyajikan UI apa pun, maka layanan Win32
dapat didaftarkan dari paket driver dengan arahan AddService. Saat mendaftarkan
layanan yang terkait dengan perangkat, layanan hanya boleh berjalan saat perangkat
ada. Layanan harus memiliki jenis awal 'permintaan mulai' dan harus menggunakan
direktif AddTrigger dari bagian penginstalan layanan untuk menyiapkan pemicu yang
akan menyebabkan layanan dimulai ketika perangkat ada di sistem. Ini dilakukan
dengan mengidentifikasi antarmuka perangkat yang akan diekspos driver pada
perangkat dan menggunakan direktif AddTrigger untuk menentukan bahwa layanan
harus dimulai ketika perangkat keras tersebut muncul. Pada runtime, layanan harus
memantau perangkat yang akan hilang. Jika perangkat dihapus dari sistem sehingga
layanan tidak perlu terus berjalan, layanan harus berhenti sendiri. Untuk mendaftar
pemberitahuan kedatangan dan penghapusan antarmuka perangkat, lihat
CM_Register_Notification.
Menggunakan CopyFiles untuk menambahkan

file ke direktori 'Program Files'
Jika INF Anda menggunakan direktif CopyFiles untuk menambahkan file ke direktori
'Program Files', maka INF tidak sesuai dengan isolasi paket driver. Ini termasuk, tetapi
tidak terbatas pada, penggunaan DIRID 16422, 16426, 16427, dan 16428. Misalnya, INF
Anda mungkin memiliki:
INF
[DestinationDirs]
Example_CopyFiles = 16422, Contoso
[ExampleDDInstall]
[Example_CopyFiles]
ExampleFile.exe
Ini tidak didukung. INF tidak boleh menyalin file ke lokasi global. Direktori 'Program
Files' biasanya digunakan untuk menginstal aplikasi perangkat lunak, bukan driver. Jika
tujuan Anda adalah membangun dan menyediakan aplikasi pendamping untuk
perangkat Anda yang berkomunikasi dengan driver Anda, lihat panduan Aplikasi
Dukungan Perangkat Keras. Misalnya, aplikasi Anda dapat menjadi aplikasi Universal
Windows Platform dan diinstal menggunakan direktif AddSoftware dari bagian
DDInstall.Software. Lihat Memasangkan driver dengan aplikasi Universal Windows
Platform (UWP) untuk informasi selengkapnya. Jika entri CopyFiles tidak untuk
menambahkan aplikasi pendamping ke sistem dan file harus tetap sebagai bagian dari
paket driver, mereka perlu dibuat untuk 'dijalankan dari Driver Store'.
CoInstaller yang meluncurkan UI

Jika INF Anda menggunakan CoInstaller untuk menginstal aplikasi yang harus
berinteraksi dengan pengguna, maka INF tidak sesuai dengan isolasi paket driver.
Misalnya, INF Anda dapat mendaftarkan CoInstaller seperti ini:
INF
[ExampleDDInstall.CoInstallers]
CopyFiles = CoInstallerCopyFilesSection
AddReg = Example_CoInstallers_AddReg
[CoInstallerCopyFilesSection]
ExampleCoInstall.dll
[Example_CoInstallers_AddReg]
HKR,,CoInstallers32,0x00010000,"ExampleCoInstall.dll,ExampleCoInstallEntryPo
int"
Sebagai gantinya, aplikasi Anda harus menjadi aplikasi Universal Windows Platform dan
diinstal menggunakan direktif AddSoftware dari bagian DDInstall.Software. Untuk
informasi selengkapnya, lihat Memasangkan driver dengan aplikasi Universal Windows
Platform (UWP). Direktif AddSoftware didukung pada Windows versi Windows 10 1703
dan yang lebih baru.
Menggunakan AddReg untuk mengubah

layanan yang tidak ditambahkan oleh INF
Jika INF Anda menggunakan arahan AddReg untuk memodifikasi status layanan yang
tidak ditambahkan oleh direktif AddService di INF Anda, maka INF tidak sesuai dengan
isolasi paket driver. Misalnya, INF Anda mungkin memiliki:
INF
[ExampleDDInstall]
[Example_Registry]
HKLM,SYSTEM\CurrentControlSet\Services\ServiceNotCreatedByThisInf\ExampleKey
, ExampleValue, %REG_DWORD%, 1
Tidak didukung. INF hanya boleh mengubah pengaturan pada layanan yang dibuat oleh
INF tersebut dan INF harus menghapus AddReg ini.
Menggunakan AddReg untuk mengubah status

di akar layanan
Jika INF Anda menggunakan direktif AddReg untuk membuat kunci atau nilai di akar
status layanan, maka INF tidak sesuai dengan isolasi paket driver. Misalnya, INF Anda
mungkin memiliki:
INF
AddReg = Example_Service_Registry
[Example_Service_Registry]
HKR,,ExampleValue,%REG_DWORD%,0x00000040
HKR,CustomSubkey,ExampleValue,%REG_DWORD%,0x00000040
Agar sesuai dengan isolasi paket driver, direktif AddReg yang menyediakan kunci dan
nilai registri layanan hanya dapat memodifikasi kunci dan nilai di bawah subkuntang
Parameter layanan. Pengaturan perlu dipindahkan di bawah subkunci Parameter layanan
dan subkunci Parameter dapat diakses saat runtime dengan IoOpenDriverRegistryKey
menggunakan RegKeyType dari DriverRegKeyParameters. IoOpenDriverRegistryKey
didukung pada Windows versi Windows 10 1803 dan yang lebih baru.
Menggunakan HKCR AddReg untuk

mendaftarkan APO
Jika INF Anda menggunakan direktif AddReg dengan akar registri HKCR untuk
mendaftarkan Objek Pemrosesan Audio (APO), maka INF tidak sesuai dengan isolasi
paket driver. Misalnya, INF Anda mungkin memiliki:
INF
HKCR,AudioEngine\AudioProcessingObjects\%EXAMPLE_CLSID%, "FriendlyName", ,
%APO_FriendlyName%
HKCR,AudioEngine\AudioProcessingObjects\%EXAMPLE_CLSID%, "Copyright", ,
%MfgName%
HKCR,AudioEngine\AudioProcessingObjects\%EXAMPLE_CLSID%, "MajorVersion",
0x00010001, 1
HKCR,AudioEngine\AudioProcessingObjects\%EXAMPLE_CLSID%, "MinorVersion",
0x00010001, 1
HKCR,AudioEngine\AudioProcessingObjects\%EXAMPLE_CLSID%, "Flags",
0x00010001, 0x0000000d
HKCR,AudioEngine\AudioProcessingObjects\%EXAMPLE_CLSID%,
"MinInputConnections", 0x00010001, 1
"MaxInputConnections", 0x00010001, 1
"MinOutputConnections", 0x00010001, 1
"MaxOutputConnections", 0x00010001, 1
HKCR,AudioEngine\AudioProcessingObjects\%EXAMPLE_CLSID%, "MaxInstances",
0x00010001, 0xffffffff
HKCR,AudioEngine\AudioProcessingObjects\%EXAMPLE_CLSID%, "NumAPOInterfaces",
0x00010001, 1
HKCR,AudioEngine\AudioProcessingObjects\%EXAMPLE_CLSID%, "APOInterface0", ,
"{b0a50980-ded6-4f45-84cb-19d2d1245f6d}"
Sebagai gantinya, informasi pendaftaran APO harus berada di bagian yang

direferensikan oleh direktif AddReg dari bagian DDInstall. Akar registri HKCR harus
diubah ke akar registri HKR untuk menempatkan pengaturan relatif terhadap "perangkat
lunak" perangkat (juga dikenal sebagai lokasi status registri "driver"). Untuk informasi
selengkapnya, lihat Mendaftarkan API untuk Mode Pemrosesan dan Efek dalam File INF.
Versi driver UMDF kurang dari 2

Jika paket driver Anda memuat driver User-Mode Driver Framework (UMDF) yang
menggunakan versi UMDF yang lebih lama dari versi 2, maka itu tidak sesuai dengan
"Driver Windows". Untuk informasi selengkapnya tentang cara memindahkan driver
UMDF Anda ke versi UMDF yang lebih baru, lihat Porting Driver dari UMDF 1 ke UMDF
2.
Membuat Pengandar Fungsi Perangkat
Baru
Dalam topik ini kami menjelaskan cara menggunakan Visual Studio untuk mulai menulis
driver fungsi perangkat baru. Driver fungsi perangkat berbeda dari driver filter, driver
perangkat lunak, dan driver sistem file, yang kita bahas dalam topik lain. Untuk
mempelajari tentang driver fungsi perangkat dan bagaimana perbedaannya dari jenis
driver lainnya, lihat Apa itu Driver?, Memilih Model Driver, dan Node Perangkat dan
Tumpukan Perangkat.
Untuk memulai, pertama-tama tentukan di mana perangkat Anda cocok dalam daftar
teknologi yang dijelaskan dalam Teknologi Perangkat dan Driver. Untuk mempelajari
tentang model driver mana yang tersedia untuk perangkat Anda, lihat dokumentasi
untuk teknologi tertentu tersebut. Model driver yang direkomendasikan bervariasi dari
satu teknologi ke teknologi berikutnya. Untuk beberapa teknologi, dokumentasi
merekomendasikan penggunaan User Mode Driver Framework (UMDF) atau Kernel
Mode Driver Framework (KMDF). Untuk teknologi lain, dokumentasi menjelaskan cara
membuat minidriver yang merupakan bagian dari pasangan driver. Minidrivers pergi
dengan berbagai nama, termasuk miniport dan miniclass.
Selanjutnya, tentukan mana dari kasus berikut yang menjelaskan rekomendasi model
driver Anda dan ikuti langkah-langkahnya:
Kasus 1: Dokumentasi untuk teknologi Anda

merekomendasikan UMDF.
1. Di Visual Studio, pada menu File, pilih | Baru Project.
2. Dalam kotak dialog Project Baru, di panel kiri, temukan dan pilih Visual C ++ | |
Pengemudi Windows WDF.
3. Di panel tengah, pilih Driver Mode Pengguna (UMDF).
4. Isi kotak Nama dan Lokasi , lalu pilih OK. Untuk detail selengkapnya, lihat Menulis
Driver UMDF Berdasarkan Templat.
Nota Saat Anda membuat driver UMDF baru,
Anda harus memilih nama driver yang memiliki 32 karakter atau kurang. Batas
panjang ini didefinisikan dalam wdfglobals.h.
5. Pada titik ini, Anda memiliki proyek driver yang menerapkan kode umum yang
diperlukan oleh sebagian besar driver UMDF. Sekarang Anda dapat menyediakan
kode yang spesifik untuk perangkat Anda. Lihat dokumentasi untuk teknologi
Anda untuk belajar tentang antarmuka yang perlu Anda terapkan.
merekomendasikan KMDF.
2. Dalam kotak dialog Project Baru, di panel kiri, temukan dan pilih WDF.
3. Di panel tengah, pilih Kernel Mode Driver (KMDF).
Driver KMDF Berdasarkan Templat.
Nota Saat Anda membuat driver KMDF baru,
Anda harus memilih nama driver yang memiliki 32 karakter atau kurang. Batas
panjang ini didefinisikan dalam wdfglobals.h.
diperlukan oleh sebagian besar driver KMDF. Sekarang Anda dapat menyediakan
kode yang spesifik untuk perangkat Anda. Lihat dokumentasi untuk teknologi
Anda untuk belajar tentang metode yang perlu Anda terapkan.
Kasus 3: Dokumentasi untuk teknologi Anda menjelaskan

model minidriver.
Jika teknologi perangkat Anda memiliki miniport, miniclass, atau jenis model minidriver
lainnya, periksa untuk melihat apakah Visual Studio memiliki template khusus untuk
model tersebut.

2. Dalam kotak dialog Project Baru, di panel kiri, temukan dan pilih Templat | visual C
++ | sopir Windows.
3. Telusuri daftar templat yang diinstal untuk menemukan templat untuk jenis
minidriver yang perlu Anda tulis.
4. Jika tidak ada template untuk jenis minidriver Anda di bawah Driver Windows,
pilih Online dan telusuri templat yang tersedia secara online.
5. Jika Anda menemukan templat untuk jenis minidriver Anda, pilih templat, isi kotak
Nama dan Lokasi , dan pilih OK.
diperlukan oleh minidriver Anda. Sekarang Anda dapat menyediakan kode yang
spesifik untuk perangkat Anda. Lihat dokumentasi untuk teknologi Anda untuk
mempelajari tentang fungsi yang perlu Anda terapkan.
Jika teknologi perangkat Anda memiliki model minidriver, dan Anda tidak dapat
menemukan template tertentu untuk jenis minidriver Anda, template Windows Driver
Model (WDM) kemungkinan besar akan menjadi titik awal Anda. Lihat dokumentasi
khusus teknologi Anda untuk panduan. Dalam kasus yang jarang terjadi, Anda dapat
menggunakan KMDF untuk menulis minidriver, tetapi biasanya titik awalnya adalah
WDM.
2. Di Visual Studio, dalam kotak dialog Project Baru, di bawah Driver Windows, pilih
WDM.
3. Isi kotak Nama dan Lokasi , lalu pilih OK.
4. Pada titik ini, Anda memiliki proyek driver WDM kosong. Di jendela Penjelajah
Solusi, pilih dan tahan (atau klik kanan) proyek driver Anda, dan pilih Tambahkan |
Item Baru.
5. Dalam kotak dialog Tambahkan Item Baru, pilih File C++ (.cpp), masukkan nama
untuk file Anda, dan pilih OK.
Nota Jika Anda ingin membuat file .c alih-alih file .cpp, masukkan nama yang
memiliki ekstensi .c .
6. Lihat dokumentasi untuk teknologi Anda untuk mempelajari tentang fungsi yang
perlu Anda terapkan. Saat Anda menerapkan dan mengatur fungsi Anda, Anda
mungkin memutuskan untuk menambahkan file tambahan .cpp atau .c.
Membuat Driver Filter Baru
driver filter baru. Driver filter berbeda dari driver fungsi perangkat, driver perangkat
lunak, dan driver sistem file, yang kita bahas dalam topik lain. Untuk mempelajari
tentang driver filter dan perbedaannya dari jenis driver lainnya, lihat topik berikut.
Apa itu pengemudi?

Memilih Model Driver
Node Perangkat dan Tumpukan Perangkat
Filter Driver
Jenis Driver WDM
Untuk memulai, pertama-tama tentukan model driver mana yang sesuai untuk driver
filter Anda. Untuk bantuan menentukan model mana yang terbaik untuk Anda, lihat
Memilih Model Driver. Jika Anda menulis driver filter untuk perangkat keras, tentukan di
mana perangkat Anda cocok dalam daftar teknologi yang dijelaskan dalam Teknologi
Perangkat dan Driver. Lihat dokumentasi untuk teknologi tertentu untuk melihat apakah
ada panduan untuk memilih model driver filter. Model driver filter yang
direkomendasikan bervariasi dari satu teknologi ke teknologi berikutnya. Untuk
beberapa teknologi, dokumentasi merekomendasikan penggunaan User Mode Driver
Framework (UMDF), Kernel Mode Driver Framework (KMDF), atau Windows Driver
Model (WDM). Untuk teknologi lain, dokumentasi memberikan detail eksplisit tentang
cara menulis driver filter. Beberapa teknologi memiliki model filter mini. Untuk beberapa
teknologi, mungkin tidak ada rekomendasi untuk model driver filter.
Selanjutnya, tentukan mana dari kasus berikut yang menjelaskan rekomendasi model
driver Anda dan ikuti langkah-langkahnya:

merekomendasikan UMDF.
2. Dalam kotak dialog Project Baru, di panel kiri, temukan dan pilih Visual C ++ | |
Pengemudi Windows WDF.
3. Di panel tengah, pilih Driver Mode Pengguna (UMDF).
4. Isi kotak Nama dan Lokasi , lalu pilih OK. Untuk informasi selengkapnya, lihat
Menulis Driver UMDF Berdasarkan Templat.
Nota Saat Anda membuat driver
UMDF baru, Anda harus memilih nama driver yang memiliki 32 karakter atau
kurang. Batas panjang ini didefinisikan dalam wdfglobals.h.
diperlukan oleh sebagian besar driver UMDF. Sekarang Anda dapat memberikan
kode yang spesifik untuk filter Anda.

merekomendasikan KMDF.
4. Isi kotak Nama dan Lokasi , lalu pilih OK. Untuk informasi selengkapnya, lihat
Menulis Driver KMDF Berdasarkan Templat.
Nota Saat Anda membuat driver KMDF
baru, Anda harus memilih nama driver yang memiliki 32 karakter atau kurang.
Batas panjang ini didefinisikan dalam wdfglobals.h.
diperlukan oleh sebagian besar driver KMDF. Sekarang Anda dapat memberikan
kode yang spesifik untuk filter Anda.

menjelaskan filter atau model filter mini
tertentu.
Jika teknologi perangkat Anda memiliki filter atau model minifilter tertentu, periksa
untuk melihat apakah Visual Studio memiliki templat untuk model tersebut.

2. Dalam kotak dialog Project Baru, di panel kiri, temukan dan pilih Templat | visual C
++ | sopir Windows.
3. Telusuri daftar templat yang diinstal untuk melihat apakah ada templat untuk jenis
filter yang perlu Anda tulis. Misalnya, Anda dapat memilih templat Filter Driver:
NDIS di bawah Jaringan.
4. Jika tidak ada template untuk jenis driver filter Anda di bawah Driver Windows,
pilih Online dan telusuri templat yang tersedia secara online.
5. Jika Anda menemukan templat untuk jenis pengandar filter, pilih templat, isi kotak
Nama dan Lokasi , dan pilih OK.
diperlukan oleh driver filter Anda. Sekarang Anda dapat memberikan kode yang
spesifik untuk filter Anda. Lihat dokumentasi untuk teknologi Anda untuk
mempelajari tentang fungsi yang perlu Anda terapkan.
Jika teknologi perangkat Anda memiliki model filter tertentu atau model minifilter, dan
Anda tidak dapat menemukan templat untuk jenis driver filter, lihat dokumentasi khusus
teknologi untuk panduan untuk menentukan apakah akan menggunakan UMDF, KMDF,
atau WDM.

merekomendasikan WDM.
WDM.
Item Baru.
Nota Jika Anda ingin membuat file .c alih-alih file .cpp, masukkan nama yang
6. Terapkan fungsi yang diperlukan oleh filter Anda. Saat Anda menerapkan dan
mengatur fungsi Anda, Anda mungkin memutuskan untuk menambahkan file
tambahan .cpp atau .c.

tidak memiliki rekomendasi untuk model driver
filter.
1. Tentukan apakah UMDF, KMDF, atau WDM adalah model terbaik untuk driver filter
Anda. Untuk bantuan, lihat Memilih Model Driver.

salah satu templat berikut:
| WDF Driver Mode Pengguna (UMDF)

| WDF Driver Mode Kernel (KMDF)
| WDM Pengandar Kernel Kosong
Nota Saat Anda membuat driver KMDF atau UMDF baru, Anda harus memilih
nama driver yang memiliki 32 karakter atau kurang. Batas panjang ini didefinisikan
dalam wdfglobals.h.
4. Terapkan fungsi yang diperlukan oleh filter Anda. Buat file .c atau .cpp baru sesuai
kebutuhan.
Jika Anda tidak yakin template mana yang akan digunakan, pertimbangkan untuk
membaca atau memposting ke forum WDK dan Pengembangan Driver Windows
Perangkat Keras .
Pemesanan driver filter perangkat
Microsoft telah mengembangkan metode untuk menambahkan filter secara deklaratif

dengan mengekspresikan niat filter, bukan posisi tumpukan, yang dikenal sebagai
pemesanan driver filter perangkat.
Kebutuhan akan pemesanan driver filter

perangkat
Sebelum Windows 10 versi 1903, satu-satunya cara yang didukung untuk mendaftarkan
driver filter perangkat adalah dengan penambahan entri registri (menggunakan direktif
AddReg). Namun, metode manipulasi registri ini tidak memberikan fleksibilitas untuk
menentukan pada posisi mana yang tepat untuk mendaftarkan filter tertentu.
Memfilter pendaftaran menggunakan direktif AddReg hanya menambahkan filter ke

akhir daftar filter. Pendekatan ini menggunakan daftar nilai di mana urutan penting dan
menentukan di mana dalam tumpukan filter dimuat.
Menggunakan satu daftar nilai yang diurutkan kurang ideal, terutama ketika
AddReghanyamenambahkanke akhir, karena ada konsekuensi negatif ketika lebih dari
satu driver menambahkan filter ke perangkat yang sama.
Dalam skenario di mana setidaknya ada satu Extension INF yang terlibat, jika INF secara
tidak benar menggunakan AddReg (dengan kata lain tidak menggunakan bendera
penambahan), mereka dapat menghapus filter yang ditambahkan oleh INF yang
berbeda.
Selain itu, beberapa Extension INF dapat menambahkan filter, dan pengurutan relatif
filter tersebut mungkin penting; namun, platform Plug and Play (PnP) tidak menjamin
urutan penginstalan untuk ekstensi. Hasilnya adalah urutan "tambahan" tidak dijamin.
Menerapkan pemesanan driver filter perangkat

Untuk menyediakan metode deklaratif yang fleksibel untuk mendaftarkan filter
perangkat, Microsoft telah mengembangkan metode menambahkan filter secara
deklaratif dengan mengekspresikan niat filter, bukan posisi tumpukan. Solusi ini
memberikan kemampuan kepada penulis driver fungsi untuk mengekspresikan dalam
INF mereka serangkaian posisi yang diurutkan (disebut tingkat) yang dapat
didaftarkan oleh filter itu sendiri.
Selain tingkat tertentu, filter dapat secara deklaratif mendaftar hanya sebagai filter
tingkat atas atau bawah .
Infrastruktur didasarkan pada metode pendaftaran filter baru untuk menentukan driver
pesanan apa yang akan disertakan dalam tumpukan perangkat. Metode baru tidak
merusak kompatibilitas untuk cara lama menambahkan filter. Namun, hal ini
memungkinkan filter baru untuk berpindah ke mekanisme pendaftaran yang lebih kuat
dan fleksibel.
Metode ini diaktifkan dengan meminta INF dasar menentukan daftar yang diurutkan
dari satu atau beberapa "level". INF dasar dan INF ekstensi apa pun dapat mendaftarkan
filter deklaratif melalui arahan INF baru yang menentukan nama dan tingkat layanan
tempat filter berada. Filter atas dan bawah masing-masing diwakili oleh daftar tingkat
yang diurutkan masing-masing.
Daftar filter atas dan bawah ini dibuat dengan mengurutkan semua driver filter menurut
tingkatnya. Urutan filter dalam setiap tingkat harus dianggap arbitrer, di mana tidak ada
dependensi yang dapat diambil pada urutan filter dalam tingkat tertentu. Dalam
skenario di mana urutan relatif dua filter harus dijamin, filter harus didaftarkan ke
tingkat yang berbeda.
Pertimbangkan contoh driver perangkat berikut:
INF dasar driver perangkat mendeklarasikan dua tingkat filter atas, A dan B (dalam
urutan tersebut). Dalam INF Ekstensi terkait INF dasar, dua filter ditambahkan ke
masing-masing dari dua tingkat.
Hasil penginstalan driver perangkat adalah urutan tumpukan perangkat yang

menggabungkan daftar driver filter sambil menghormati posisi dan pemesanan yang
diinginkan. Urutan tumpukan perangkat yang dihasilkan memastikan bahwa filter apa
pun yang ditempatkan di tingkat "A" hadir sebelum filter apa pun di tingkat "B". Namun,
dalam setiap tingkatan, urutannya segan-segan.
Seperti yang ditunjukkan dalam contoh, Filter3 bisa datang sebelum Filter5 atau bisa
datang setelah Filter5. Bagaimanapun, Filter3 dan Filter5 akan datang sebelum filter di
tingkat berikutnya, "B".
Saat merancang rangkaian tingkat yang dapat didaftarkan filter, daripada membuat
serangkaian tingkat demi pemesanan, tingkat harus diberi nama dan diurutkan
sedemikian rumit sehingga mereka memetakan ke niat filter. Misalnya, perangkat I/O
dapat menentukan tingkat Enkripsi, tempat filter enkripsi apa pun harus didaftarkan. Ini
memungkinkan niat filter untuk mudah dipahami dan dikelola, dan membuat tumpukan
lebih kuat terhadap perubahan yang melanggar pada driver fungsi.
７ Catatan
Bahkan tanpa tingkat yang ditentukan oleh INF dasar, filter deklaratif dapat
mendaftar hanya sebagai atas atau bawah. Ketika tingkat tidak ditentukan, ini
secara logis setara dengan menambahkan filter ke akhir nilai registri
UpperFilters/LowerFilters. Ketika tingkat didefinisikan, salah satu tingkat harus
ditandai sebagai tingkat default di driver dasar, dan dalam hal ini filter akan
didaftarkan ke tingkat tersebut.
Skenario
Pertimbangkan driver perangkat I/O yang mengenkripsi data yang masuk melalui
tumpukan. Implementasi umum dapat menggunakan driver filter yang lebih rendah
tepat di bawah driver fungsi untuk menyelesaikan ini. Untuk memastikan bahwa filter
enkripsi ditempatkan pada posisi yang tepat yang diinginkan penulis driver, mereka
dapat menggunakan filter deklaratif seperti yang ditunjukkan di bawah ini:
INF Dasar menetapkan dua tingkat filter yang lebih rendah, "Enkripsi" dan "Pemantauan"
(Default). "Pemantauan" (Default) dalam contoh ini adalah filter lain yang lebih rendah
yang mungkin ada untuk perangkat khusus ini. Dengan secara eksplisit menempatkan
driver filter "Enkripsi" di tingkat "Enkripsi", driver memastikan bahwa urutan tumpukan
perangkat yang dihasilkan akan menempatkan driver filter "Enkripsi" sebelum filter lain
yang lebih rendah dan segera mengikuti driver fungsi.
Mari kita ambil contoh satu langkah lebih jauh. Bayangkan versi driver yang lebih baru
keluar dan penulis telah membangun enkripsi ke driver fungsi. Ini menghilangkan
kebutuhan akan driver filter "Enkripsi" terpisah. Penulis hanya perlu menghapus tingkat
yang berisi filter "Enkripsi" dari BASE INF dan ketika driver diperbarui, tumpukan
dibangun lagi secara dinamis.
Jika filter menyatakan dirinya berada dalam tingkat eksplisit yang tidak ada, filter tidak
berakhir di tumpukan perangkat. Dalam contoh, INF Dasar telah diperbarui dan
meskipun Extension INF tetap sama, tumpukan perangkat yang dihasilkan
mengecualikan filter "Enkripsi" karena tidak termasuk dalam deklarasi tingkat BASE INF.
Tingkat filter default

Untuk menghasilkan tumpukan filter akhir, semua sumber informasi filter digabungkan
ke dalam satu daftar. Penting untuk dicatat bahwa logika penggabungan dilakukan saat
membuat tumpukan perangkat. Jika filter baru ditambahkan dengan menginstal basis
baru/diperbarui atau driver ekstensi, perangkat akan dimulai ulang selama penginstalan
dan mengambil daftar filter baru.
Beberapa sumber filter tidak memiliki informasi posisi apa pun, yaitu filter yang
ditambahkan melalui nilai registri UpperFilters/LowerFilters warisan, atau melalui sintaks
deklaratif khusus posisi (dibahas di bawah).
Untuk mendukung penggabungan yang efektif saat tidak memiliki informasi posisi,
informasi tambahan harus ditentukan oleh INF Dasar: tingkat filter default. Tingkat filter
default adalah posisi di mana filter, tingkat kurang atau informasi posisi, akan disisipkan.
Misalnya, tingkat filter dapat didefinisikan dalam INF Dasar sebagai:
INF
Level Order: A, B, C
DefaultFilterLevel: C
Menentukan tingkat default sebagai tingkat akhir menunjukkan bahwa filter apa pun
yang tidak memiliki informasi posisi akan ditambahkan ke daftar filter. Atau, pembuat
driver mungkin ingin tumpukan selalu diakhiri dengan filter yang secara eksplisit
terdaftar ke tingkat C:
INF
Level Order: A, B, C
DefaultFilterLevel: B
Karena tingkat filter default diatur ke B, filter tambahan apa pun tanpa informasi posisi
akan dimasukkan antara filter A dan filter C.
Sintaks
Mendaftarkan filter
Lihat bagian INF DDInstall.Filters dan dokumentasi direktif AddFilter untuk informasi
selengkapnya.
INF
[DDInstall.Filters]
AddFilter = <FilterName>, [Flags], FilterSection
FilterLevel OR FilterPosition dapat ditentukan dengan salah satu dari dua cara:
Opsi 1:
INF
[FilterSection]
FilterLevel=<LevelName>
Opsi 2:
INF
[FilterSection]
FilterPosition=Upper/Lower
Ini dapat dilakukan di INF Dasar dan Ekstensi.
[DDInstall.Filters]
FilterName adalah nama layanan pada sistem.
Bendera saat ini tidak digunakan dan harus dibiarkan kosong atau diatur ke 0.
FilterSection adalah bagian yang menjelaskan filter.
[Bagian Filter]
Bagian filter harus berisi tepat salah satu dari dua arahan berikut: FilterLevel atau
FilterPosition.
FilterLevel adalah tempat khusus untuk menyisipkan filter perangkat pada tumpukan,
yang ditentukan oleh INF Dasar. Dalam setiap tingkat, urutan filter bersifat arbitrer.
FilterPosition digunakan dalam kasus di mana kelas memiliki satu tempat khusus untuk
filter pihak ketiga yang akan disisipkan.
Menentukan Tingkat Filter

INF
[DDInstall.HW]
AddReg = FilterLevel_Definition
[FilterLevel_Definition]
HKR,,UpperFilterLevels,%REG_MULTI_SZ%,"LevelA","LevelB","LevelC"
HKR,,UpperFilterDefaultLevel,,"LevelC"
HKR,,LowerFilterLevels,%REG_MULTI_SZ%,"LevelD","LevelE","LevelF"
HKR,,LowerFilterDefaultLevel,,"LevelE"
Ini hanya dapat dilakukan oleh driver dasar .
Daftar deklaratif lengkap filter untuk perangkat tertentu dapat diambil dengan
mengkueri properti berikut:
INF
DEVPKEY_Device_CompoundUpperFilters
DEVPKEY_Device_CompoundLowerFilters
Pendaftaran filter yang setara dengan warisan

Mari kita periksa cara mencapai pendekatan warisan mencoba menambahkan filter atas
melalui INF:
INF
[DDInstall.HW]
AddReg = Filters
[Filters]
HKR,,"UpperFilters", 0x00010008, "MyFilter"
Sintaks ini akan menambahkan "MyFilter" ke akhir daftar filter atas.
Dengan sintaks baru yang telah diperkenalkan, bagian di atas secara logis mirip dengan:
INF
[DDInstall.Filters]
AddFilter = MyFilter,,MyUpperFilterInstall
[MyUpperFilterInstall]
FilterPosition = Upper
Ini menentukan bahwa filter "MyFilter" harus ditambahkan ke daftar filter atas. Jika INF
dasar telah menentukan tingkat filter, menggunakan FilterPosition akan mendaftarkan
filter di tingkat default untuk posisi tersebut.
Jika tingkat filter tidak ditentukan, filter ini akan didaftarkan sebagai filter atas dalam
urutan arbitrer.
Lihat juga
Bagian INF DDInstall.Filters
Direktif AddFilter
Membuat Driver Perangkat Lunak Baru
driver perangkat lunak baru. Driver perangkat lunak berbeda dari driver fungsi
perangkat, driver filter, dan driver sistem file, yang kita bahas dalam topik lain. Untuk
informasi lebih lanjut tentang driver perangkat lunak dan bagaimana mereka berbeda
dari jenis driver lain, lihat Apa itu Driver? dan Memilih Model Driver.
Untuk memulai, pertama-tama tentukan model driver mana yang sesuai untuk driver
perangkat lunak Anda. Ketiga opsi tersebut adalah Kernel Mode Driver Framework
(KMDF), model driver NT lama, dan Windows Driver Model (WDM). Untuk bantuan
menentukan model mana yang terbaik untuk Anda, lihat Memilih Model Driver.
Kasus 1: Anda ingin menggunakan KMDF

Driver KMDF Berdasarkan Templat.
７ Catatan
Saat Anda membuat driver KMDF baru, Anda harus memilih nama driver yang
memiliki 32 karakter atau kurang. Batas panjang ini didefinisikan dalam
wdfglobals.h.
diperlukan oleh sebagian besar driver KMDF. Sekarang Anda dapat menyediakan
kode yang khusus untuk driver perangkat lunak Anda.
Kasus 2: Anda ingin menggunakan model NT

lama
WDM | Pengemudi WDM kosong.
７ Catatan
Anda tidak akan menulis driver WDM, tetapi Anda memerlukan template
Driver WDM Kosong .
Item Baru.
７ Catatan
Jika Anda ingin membuat file .c alih-alih file .cpp, masukkan nama yang
6. Termasuk ntddk.h.
7. Terapkan fungsi yang diperlukan oleh driver perangkat lunak Anda. Saat Anda
menerapkan dan mengatur fungsi Anda, Anda mungkin memutuskan untuk
menambahkan file header dan file .cpp atau .c tambahan.
Kasus 3: Anda ingin menggunakan WDM

Sangat tidak mungkin Anda ingin menggunakan WDM untuk driver perangkat lunak.
Tetapi jika Anda melakukannya, ikuti langkah-langkah ini.
WDM.
Item Baru.
７ Catatan
Jika Anda ingin membuat file .c alih-alih file .cpp, masukkan nama yang
6. Termasuk wdm.h.
7. Terapkan fungsi yang diperlukan oleh driver perangkat lunak Anda. Saat Anda
menerapkan dan mengatur fungsi Anda, Anda mungkin memutuskan untuk
menambahkan file header dan file .cpp atau .c tambahan.
Membuat driver primitif baru
Gunakan driver primitif untuk menangani dan mengelola perangkat lunak yang
menggunakan instalasi berbasis INF tetapi tidak harus terkait dengan perangkat keras
tertentu.
Latar belakang dan manfaat driver primitif

Sebelum Windows 10 versi 1903, beberapa jenis perangkat lunak yang menggunakan
instalasi berbasis INF tetapi tidak selalu terkait dengan perangkat keras tertentu tidak
sepenuhnya didukung oleh OS. Sementara perangkat lunak ini menggunakan file INF
sebagai manifes untuk instalasi, OS tidak secara langsung menyadari skenario ini dan
tidak memiliki dukungan untuk menanganinya secara native.
Karena perangkat lunak ini tidak terkait dengan perangkat keras, mereka akan
menginstal pada seluruh sistem terlepas dari perangkat keras. Akibatnya, tidak ada
jaminan bahwa perangkat lunak ini diinstal, dihapus, atau ditangani dengan benar pada
peningkatan OS.
Dimulai dengan Windows 10 versi 1903, platform Plug and Play menangani dan
mengelola jenis paket perangkat lunak ini sebagai entitas tingkat atas, menghasilkan
peningkatan keandalan dan menjamin perilaku yang tepat dari perangkat lunak
tersebut, terutama selama peningkatan OS dan mengatur ulang skenario.
Jenis perangkat lunak yang memanfaatkan dukungan platform baru ini disebut driver
primitif. Driver primitif terus menggunakan instalasi berbasis INF dan platform yang
mendasarinya menggunakan Driver Store untuk melacak semua file yang relevan.
Platform Plug and Play yang mendasarinya kemudian dengan anggun menginstal,
menghapus instalasi, dan mempertahankan status driver pada peningkatan OS.
Secara konseptual, INF ini dikelola secara berbeda. Sebelumnya, [DefaultInstall] (dan
sering, [DefaultUninstall]) diproses oleh SetupAPI dengan cara seperti skrip, di mana INF
digunakan sebagai manifes dan SetupAPI menjalankan instruksi di bagian yang relevan
atas nama penelepon.
Membatalkan perubahan (untuk melakukan penghapusan instalasi) diperlukan

menentukan bagian INF yang melakukan serangkaian instruksi yang berlawanan sebagai
bagian instalasi. Namun, driver primitif yang memanfaatkan INF tidak memerlukan
bagian penghapusan instalasi.
Driver primitif menggunakan API instalasi dan penghapusan instalasi yang sama dengan
driver perangkat, di mana API penghapusan instalasi akan melakukan serangkaian
operasi terbalik sebagai operasi penginstalan, dan tindakan menginstal atau menghapus
paket driver akan memproses bagian-bagian tersebut.
Persyaratan INF untuk mengakses

fungsionalitas driver primitif
Bagian Versi harus lengkap, seperti driver PnP.
Arahan Penyedia harus diisi.
Arahan Kelas harus diisi.
Arahan ClassGuid harus diisi.
Pengemudi harus Sesuai dengan DCH.
Tidak ada bagian [Produsen] yang mungkin ada.
Bagian [DefaultInstall] harus didekorasi arsitektur, dan tidak ada versi yang tidak
didekorasi yang mungkin ada.
Benar: [DefaultInstall.NTamd64]
Salah: [DefaultInstall]
[DefaultUninstall] mungkin tidak ada di INF (lihat kompatibilitas lama untuk

pengecualian).
Driver primitif yang hanya menargetkan versi

Windows 10 1903 dan versi lebih baru
Driver primitif yang ditargetkan hanya untuk versi Windows 10 1903 dan yang lebih
baru harus menggunakan DiInstallDriver dan DiUninstallDriver untuk menginstal dan
menghapus perangkat lunak mereka dengan benar di / dari toko driver.
Driver juga harus menggunakan Dirid 13 untuk menentukan Driver Store dengan benar
sebagai tujuan yang diinginkan untuk diinstal.
Kompatibilitas Lama
Sementara [DefaultUninstall] dilarang di Driver Primitif, pengecualian dibuat demi
kompatibilitas OS tingkat bawah. Windows memperkenalkan direktif INF yang
menyebabkan versi OS yang mendukung Driver Primitif mengabaikan bagian
[DefaultUninstall]. Jika paket driver Anda perlu mendukung versi OS tingkat bawah,
sertakan sintaks berikut untuk memastikan bahwa platform akan menangani kasus
tersebut dengan tepat:
INF
[DefaultUninstall.NTamd64]
LegacyUninstall=1
Bagian [DefaultInstall] dan [DefaultUninstall] harus tetap didekorasi arsitektur; namun,

dengan LegacyUninstall=1 memasukkan , Windows mengabaikan bagian
[DefaultUninstall] (di Windows 10 versi 1903 dan yang lebih baru). Dengan demikian,
Anda dapat memasukkan bagian itu di INF Anda, di mana ia dapat digunakan di tingkat
bawah dengan aplikasi instal / uninstall lama untuk menghapus paket driver primitif.
Dimulai dengan versi Windows 10 1903, jika Anda melewati bagian [DefaultInstall] atau
[DefaultUninstall] yang didekorasi arsitektur ke API InstallHInfSection di setupapi.dll,
paket driver akan diperiksa untuk menentukan apakah itu mendukung fungsionalitas
driver primitif. Jika mendukung fungsionalitas driver primitif, alih-alih memproses
bagian yang ditentukan dengan cara lama, INF diteruskan ke DiInstallDriver atau
DiUninstallDriver, sebagaimana mestinya. Dengan cara ini, installer tunggal dapat
menggunakan driver primitif pada versi OS yang kompatibel dan mempertahankan
dukungan untuk versi OS sebelumnya.
Mengonversi dari inf driver perangkat

Mengonversi INF yang menggunakan [Manufacturer] menjadi YANG menggunakan
[DefaultInstall] memerlukan perubahan kecil pada INF. Tidak seperti bagian [Produsen],
bagian [DefaultInstall] adalah titik masuk dan bagian penginstalan. Ini secara konseptual
menggabungkan bagian [Manufacturer], [Models], dan [DDInstall] menjadi satu.
INF berikut akan menerima kesalahan 1297 di InfVerif karena tidak diinstal pada
perangkat keras apa pun:
ini
[Manufacturer]
%Company% = Driver, NTx86, NTamd64
[Driver.NTx86]
%DeviceDesc% = InstallSection_32,
[Driver.NTamd64]
%DeviceDesc% = InstallSection_64,
[InstallSection_64]
CopyFiles = MyCopyFiles_64
AddReg = MyAddReg
[InstallSection_64.Services]
AddService = MyService,, MyService_Install
[InstallSection_32]
CopyFiles = MyCopyFiles_x86
AddReg = MyAddReg
[InstallSection_32.Services]
INF di atas dapat dikonversi ke INF berbasis [DefaultInstall], seperti yang ditunjukkan di
bawah ini.
ini
[DefaultInstall.NTamd64]
CopyFiles = MyCopyFiles_64
AddReg = MyAddReg
[DefaultInstall.NTamd64.Services]
[DefaultInstall.NTx86]
CopyFiles = MyCopyFiles_x86
AddReg = MyAddReg
[DefaultInstall.NTx86.Services]
Membuat Driver Dari File Sumber yang

Ada
WDK terintegrasi dengan Microsoft Visual Studio, dan menggunakan compiler dan
membangun alat yang sama yang Anda gunakan untuk membangun solusi dan proyek
Visual Studio. MSBuild menggantikan Windows Build Utility (Build.exe) yang digunakan
dalam versi WDK sebelum Windows Driver Kit (WDK) 8.
Untuk mengonversi driver yang dibuat dengan WDK versi sebelumnya, buat solusi driver
Windows baru di Visual Studio menggunakan salah satu templat driver Windows yang
disediakan. Jika Anda mulai dengan template untuk model driver Anda, struktur proyek
akan berada di tempat dan set alat platform yang benar akan dipilih. Anda kemudian
dapat menambahkan file sumber Anda ke solusi. Untuk informasi tentang memilih
templat, lihat Membuat Pengandar Fungsi Perangkat Baru, Membuat Pengandar Filter
Baru, atau Membuat Pengandar Perangkat Lunak Baru.
Topik terkait
WDK dan lingkungan Visual Studio membangun
ProjectUpgradeTool
MSBuild
Panduan: Menggunakan MSBuild
Membuat Pengandar Fungsi Perangkat Baru
Membuat Driver Filter Baru
Membuat Driver Perangkat Lunak Baru
Menggunakan Visual Studio atau
MSBuild untuk membangun driver
Topik ini menjelaskan bagaimana Anda dapat membangun driver menggunakan

lingkungan pengembangan Visual Studio, atau dari baris perintah dengan
menggunakan Microsoft Build Engine (MSBuild).
Penting Mulai Windows Driver Kit (WDK) 8, MSBuild menggantikan Windows Build
Utility (Build.exe). WDK sekarang menggunakan alat kompilator dan build yang sama
dengan yang Anda gunakan untuk membangun proyek Visual Studio. Proyek driver
yang dibangun dengan versi WDK sebelumnya harus dikonversi agar berfungsi di
lingkungan Visual Studio. Anda dapat menjalankan utilitas konversi dari baris perintah,
atau Anda dapat mengonversi driver yang ada dengan membuat proyek Visual Studio
baru dari sumber yang ada. Untuk informasi selengkapnya, lihat Membuat Driver Dari
File Sumber yang Ada dan WDK dan lingkungan build Visual Studio.
Membangun Driver Menggunakan Visual

Studio
Anda membangun driver dengan cara yang sama seperti Anda membangun proyek atau
solusi apa pun di Visual Studio. Saat Anda membuat proyek driver baru menggunakan
templat driver Windows, templat menentukan konfigurasi proyek default (aktif) dan
konfigurasi build solusi default (aktif).
Catatan Anda dapat mengonversi proyek dan solusi yang Anda buat dengan WDK 8
atau Windows Driver Kit (WDK) 8.1 untuk bekerja dengan Windows Driver Kit (WDK) 10
dan Visual Studio 2019. Sebelum Anda membuka proyek atau solusi, jalankan
ProjectUpgradeTool. ProjectUpgradeTool mengonversi proyek dan solusi sehingga
dapat dibangun menggunakan WDK 10.
Untuk informasi tentang mengelola dan mengedit konfigurasi build, lihat Membangun
di Visual Studio.
Konfigurasi build Solusi default adalah Debug dan Win32.
Untuk memilih konfigurasi dan membangun driver
1. Pastikan Anda memiliki versi SDK dan WDK yang sama yang terinstal di komputer
Anda.
2. Buka proyek atau solusi driver di Visual Studio.
3. Pilih dan tahan (atau klik kanan) solusi di Penjelajah Solusi dan pilih Configuration
Manager.
4. Dari Configuration Manager, pilih konfigurasi solusi Aktif (misalnya, Debug atau
Rilis) dan platform solusi Aktif (misalnya, Win32) yang sesuai dengan jenis build
yang Anda minati.
5. Pilih dan tahan (atau klik kanan) proyek Avshws dan pilih Properti. Buka Driver
Pengaturan > Umum, dan atur Versi OS Target dan Platform Target.
6. Konfigurasikan properti proyek untuk driver atau paket driver Anda. Anda dapat
mengatur properti untuk penyebaran, penandatanganan driver, atau tugas lainnya.
Untuk informasi selengkapnya, lihat Mengonfigurasi properti proyek untuk driver
dan paket driver Anda.
7. Dari menu Build , pilih Build Solution (Ctrl+Shift+B).
Membangun Driver Menggunakan Baris

Perintah (MSBuild)
Anda dapat membangun driver dari baris perintah menggunakan jendela Visual Studio
Command Prompt dan Microsoft Build Engine (MSBuild)
Untuk membangun driver menggunakan jendela Visual Studio Command Prompt
1. Buka jendela Perintah Pengembang untuk VS2019 .
Dari jendela ini Anda dapat menggunakan MSBuild.exe untuk membangun proyek
Visual Studio dengan menentukan file proyek (.vcxproj) atau solusi (.sln).
2. Navigasi ke direktori proyek dan masukkan perintah MSbuild untuk target Anda.
Misalnya, untuk melakukan build bersih proyek driver Visual Studio yang disebut
MyDriver.vcxproj menggunakan Platform dan Konfigurasi default, navigasikan ke
direktori proyek dan masukkan perintah MSBuild berikut:
C++
msbuild /t:clean /t:build .\MyDriver.vcxproj
Sintaks - Untuk menentukan konfigurasi dan platform tertentu, gunakan sintaks

perintah berikut:
C++
msbuild /t:clean /t:build ProjectFile /p:Configuration=<Debug|Release>
/p:Platform=architecture /p:TargetPlatformVersion=a.b.c.d
/p:TargetVersion=OS
Misalnya, perintah berikut membangun driver untuk konfigurasi "Debug", platform

"Win32", dan untuk Windows 10.
C++
msbuild /t:clean /t:build .\MyDriver.vcxproj /p:Configuration="Debug"

/p:Platform=Win32 /p:TargetVersion=”Windows10”
/p:TargetPlatformVersion=”10.0.10010.0”
Pengaturan TargetPlatformVersion bersifat opsional dan memungkinkan Anda

menentukan versi kit yang akan dibuat. Defaultnya adalah menggunakan kit
terbaru.
Mengonfigurasi properti proyek untuk driver

dan paket driver Anda
Anda menggunakan halaman properti untuk mengonfigurasi dan mengatur opsi untuk
driver dan paket driver Anda. Anda dapat memilih untuk mengonfigurasi driver
sehingga secara otomatis ditandatangani saat Anda membangun solusi, atau secara
otomatis disebarkan ke komputer uji jarak jauh.
WDK menyediakan sejumlah alat baris perintah, seperti Stampinf dan WPP Preprocessor
(WPP Tracing), yang biasanya disertakan dalam proses build. Alat-alat ini tidak
didistribusikan dengan Visual Studio. Untuk menggabungkan alat-alat ini dengan
lingkungan build Visual Studio mereka dibungkus sebagai tugas WDK untuk MSBuild.
Jika Anda menggunakan salah satu templat driver atau memiliki driver yang sudah ada
yang telah Anda konversi, halaman properti ini mungkin sudah ada untuk proyek Anda.
Jika tidak, halaman properti secara otomatis ditambahkan ke proyek Anda saat Anda
menambahkan jenis file terkait ke proyek atau solusi (misalnya, file .mc atau .man untuk
pengkompilasi pesan). Untuk informasi selengkapnya, lihat WDK dan lingkungan build
Visual Studio
Anda dapat mengatur properti untuk driver individual atau untuk seluruh paket driver.
Tabel berikut ini memperlihatkan beberapa properti yang tersedia yang dapat Anda
konfigurasi khusus untuk driver dan paket driver.
Properti Project Driver Properti Paket Driver

Properti Project Driver Properti Paket Driver
Menandatangani properti untuk file driver Properti penandatanganan untuk paket driver
individual (lihat Menandatangani Driver) (lihat Menandatangani Driver)
Penghitung Properti Praprosesor Manifes untuk Properti Penyebaran untuk Proyek Paket Driver
Proyek Driver (untuk CTRPP) (lihat Menyebarkan Driver ke Komputer Uji)
Properti Pengaturan Model Driver untuk Proyek Properti Pemverifikasi Driver untuk Proyek
Driver Paket Driver
Properti Pengkompilasi Pesan untuk Proyek Properti Pemverifikasi KMDF untuk Proyek
Driver Paket Driver
Properti Stampinf untuk Proyek Driver Properti Pemverifikasi UMDF untuk Proyek
Paket Driver
WPP Preprocessor (Pelacakan WPP) Properti Inf2Cat untuk Proyek Paket Driver
(lihat alat Inf2Cat )
Tip pemecahan masalah untuk membangun

driver
Tips berikut dapat membantu Anda memecahkan masalah saat menggunakan WDK dan
Visual Studio untuk membangun driver.
Untuk meningkatkan verbositas output build menggunakan opsi di Visual Studio
1. PilihOpsiAlat>.
2. Pilih folder Project dan Solusi dan pilih Bangun dan Jalankan.
3. Ubah opsi untuk verbositas output build proyek MSBuild dan verbositas file log
build proyek MSBuild. Secara default, ini diatur ke Minimal.
Topik terkait
Bangunan di Visual Studio
Membangun Driver untuk Berbagai Versi Windows
Menggunakan Microsoft C Runtime dengan Driver User-Mode dan Aplikasi
Desktop
ProjectUpgradeTool
MSBuild
Membuat Driver Dari File Sumber yang Ada
WDK dan lingkungan build Visual Studio
Menandatangani Driver
Menyebarkan Driver ke Komputer Uji
Bangunan untuk OneCore
Saat Anda menggunakan Visual Studio untuk membuat kode mode pengguna untuk
Windows 10, Anda dapat menyesuaikan opsi linker untuk menargetkan versi Windows
tertentu. Pertimbangkan faktor-faktor berikut:
Haruskah biner yang dibangun hanya berjalan pada versi terbaru dari Windows?
Atau haruskah itu berjalan pada versi sebelumnya, seperti Windows 7?
Apakah proyek Anda memiliki dependensi UWP ?
Misalnya, saat Anda membuat proyek driver UMDF v2 baru, Visual Studio tautan secara
OneCoreUAP.lib default. Ini menghasilkan biner yang berjalan pada versi terbaru
Windows, dan memungkinkan penambahan fungsionalitas UWP.
Namun, tergantung pada kebutuhan Anda, Anda dapat memilih untuk menautkan ke
OneCore.lib . Tabel berikut menunjukkan skenario yang berlaku untuk setiap pustaka:
Pustaka Skenario
OneCore.lib Semua edisi Windows 7 dan yang lebih baru, tidak ada dukungan UWP
OneCoreUAP.lib Windows 7 dan yang lebih baru, edisi UWP (Desktop, IoT, HoloLens, tetapi
bukan Nano Server) dari Windows 10
７ Catatan
Untuk mengubah opsi linker di Visual Studio, pilih properti proyek dan navigasikan
ke Dependensi Linker-Input-Additional>>.
Subset api Windows dikompilasi dengan bersih tetapi mengembalikan kesalahan

runtime pada edisi OneCore non-Desktop (misalnya Seluler atau IoT).
Misalnya, fungsi InstallApplication kembali ERROR_ NOT_SUPPORTED pada edisi OneCore

non-Desktop. Alat ApiValidator juga melaporkan masalah ini. Bagian selanjutnya
menjelaskan cara memperbaikinya.
Memperbaiki kesalahan ApiValidator dengan

menggunakan IsApiSetImplemented
Jika kode Anda memanggil API non-universal, Anda mungkin melihat kesalahan
ApiValidator berikut:
Error: <Binary Name> has unsupported API call to <Module Name><Api Name>
Jika aplikasi atau driver dasar Anda perlu berjalan di Windows 10 serta versi
Windows yang lebih lama, Anda harus menghapus panggilan API dalam kategori
di atas.
Error: <Binary Name> has a dependency on <Module Name><Api Name> but is

missing: IsApiSetImplemented("<contract-name-for-Module>)
Panggilan API dalam kategori di atas mengkompilasi dengan baik, tetapi mungkin
tidak berperilaku seperti yang diharapkan saat runtime, tergantung pada sistem
operasi target. Untuk melewati persyaratan API Layering untuk Driver Windows,
bungkus panggilan ini dengan IsApiSetImplemented.
Ini memungkinkan Anda untuk mengkompilasi kode Anda tanpa kesalahan. Kemudian
saat runtime, jika mesin target tidak memiliki API yang diperlukan,
IsApiSetImplemented mengembalikan FALSE.
Sampel kode berikut mengilustrasikan cara melakukan ini.
Sampel kode: Penggunaan LANGSUNG API,

tanpa mengevaluasi keberadaan
Kode ini berjalan dengan baik pada versi Windows lebih awal dari Windows 10, tetapi
menjalankannya pada edisi OneCore Windows 10 menghasilkan kegagalan
WTSEnumerateSessions: 78 atau ERROR_CALL_NOT_IMPLEMENTED 120 (0x78).
Sampel kode ini gagal memenuhi persyaratan API Layering dari Windows Drivers
dengan kesalahan ApiValidator berikut:
C++

'wtsapi32.dll!WTSEnumerateSessionsW' but is missing:
IsApiSetImplemented("ext-ms-win-session-wtsapi32-l1-1-0")

'wtsapi32.dll!WTSFreeMemory' but is missing: IsApiSetImplemented("ext-ms-
win-session-wtsapi32-l1-1-0")
ApiValidation: NOT all binaries are Universal
Berikut adalah kodenya:

C++
#include <windows.h>
#include <stdio.h>
#include <Wtsapi32.h>
int __cdecl wmain(int /* argc */, PCWSTR /* argv */ [])
PWTS_SESSION_INFO pInfo = {};

DWORD count = 0;
if (WTSEnumerateSessionsW(WTS_CURRENT_SERVER_HANDLE, 0, 1, &pInfo,
&count))
wprintf(L"SessionCount = %d\n", count);
for (ULONG i = 0; i < count; i++)
PWTS_SESSION_INFO pCurInfo = &pInfo[i];
wprintf(L" %s: ID = %d, state = %d\n", pCurInfo-

>pWinStationName, pCurInfo->SessionId, pCurInfo->State);
WTSFreeMemory(pInfo);
else
wprintf(L"WTSEnumerateSessions failure : %x\n", GetLastError());
return 0;
Sampel kode: Penggunaan LANGSUNG API,

setelah mengevaluasi keberadaannya
Sampel ini menunjukkan cara memanggil IsApiSetImplemented. Sampel ini melewati
persyaratan API Layering driver Windows dengan output ApiValidator berikut:
C++
ApiValidation: All binaries are Universal
Berikut adalah kodenya:
C++
#include <windows.h>
#include <stdio.h>
#include <Wtsapi32.h>
int __cdecl wmain(int /* argc */, PCWSTR /* argv */ [])
PWTS_SESSION_INFO pInfo = {};

DWORD count = 0;
if (!IsApiSetImplemented("ext-ms-win-session-wtsapi32-l1-1-0"))
wprintf(L"IsApiSetImplemented on ext-ms-win-session-wtsapi32-l1-1-0
returns FALSE\n");
else
if (WTSEnumerateSessionsW(WTS_CURRENT_SERVER_HANDLE, 0, 1, &pInfo,
&count))
wprintf(L"SessionCount = %d\n", count);
for (ULONG i = 0; i < count; i++)
PWTS_SESSION_INFO pCurInfo = &pInfo[i];
wprintf(L" %s: ID = %d, state = %d\n", pCurInfo-

>pWinStationName, pCurInfo->SessionId, pCurInfo->State);
WTSFreeMemory(pInfo);
}
else
wprintf(L"WTSEnumerateSessions failure : %x\n", GetLastError());
return 0;
Tindakan yang disarankan

Tinjau opsi linker di atas dan perbarui proyek Visual Studio Anda sesuai dengan itu.
Gunakan alat ApiValidator di WDK. Alat ini berjalan secara otomatis saat Anda
membuat driver di Visual Studio.
Gunakan pengujian runtime untuk memverifikasi bahwa kode mode pengguna
Anda berjalan seperti yang Anda harapkan pada edisi OneCore non-Desktop.
Perhatikan bahwa API yang dibentangkan dapat menghasilkan kode kesalahan
yang berbeda.
Lihat juga
Memvalidasi Driver Windows
OneCore
Membangun Driver untuk Berbagai
Versi Windows
Jika Anda menulis driver untuk berbagai versi Windows, bagian berikut memberikan
beberapa panduan tentang bagaimana Anda harus membangun driver tersebut
menggunakan Windows Driver Kit (WDK), Visual Studio, dan MSBuild.
Panduan yang berlaku untuk membangun

driver mode pengguna dan mode kernel
Bangun driver Anda menggunakan konfigurasi target dan platform yang
disediakan WDK. Selalu gunakan WDK versi terbaru yang mendukung versi
Windows yang ingin Anda targetkan. Untuk info tentang WDK dan dukungan versi
sistem operasi, lihat Menginstal versi pratinjau Windows Driver Kit dan Unduh
Windows Driver Kit.
Jika driver Anda hanya harus berjalan pada satu versi Windows, buat driver untuk
konfigurasi target dan platform yang cocok dengan versi Windows target Anda.
Jika Anda ingin driver Anda berjalan pada beberapa versi Windows, tetapi tanpa
fitur yang hanya tersedia pada versi yang lebih baru, buat driver untuk versi tertua
yang Anda ingin didukung oleh driver.
Jika Anda menargetkan Windows 7, Windows 8, atau Windows 8.1, atur TargetVersion
menggunakan Configuration Manager atau secara manual di file .vcxproj, misalnya
<TargetVersion>Windows7</TargetVersion> .
Jika Anda menargetkan Windows 10 atau Windows 11, tetapkan TargetVersion dan
_NT_TARGET_VERSION, misalnya <TargetVersion>Windows10</TargetVersion>
<_NT_TARGET_VERSION>0xA000006</_NT_TARGET_VERSION> .
_NT_TARGET_VERSION nilai tercantum dalam file header Sdkddkver.h dalam formulir

NTDDI_WIN10_* , misalnya #define NTDDI_WIN10_RS5 0x0A000006 .
Panduan yang berlaku untuk membuat driver

mode kernel
Jika Anda ingin driver mode kernel Anda berjalan pada beberapa versi Windows
dan secara dinamis menentukan fitur yang tersedia untuk driver, buat driver
menggunakan konfigurasi build untuk versi terbaru dari sistem operasi. Misalnya,
jika Anda ingin driver Anda mendukung semua versi Windows dimulai dengan
Windows 8.1, tetapi untuk menggunakan fitur tertentu yang pertama kali tersedia
di Windows 10 saat driver Anda berjalan pada versi sistem operasi Windows 10
atau yang lebih baru, tentukan Windows 10 (Win10) sebagai konfigurasi target.
Gunakan fungsi RtlIsNtDdiVersionAvailable dan RtlIsServicePackVersionInstalled

untuk menentukan versi Windows yang tersedia untuk driver Anda pada waktu
yang dijalankan. Untuk informasi selengkapnya, lihat Menulis driver untuk berbagai
versi Windows.
Buat prototipe untuk petunjuk ke fungsi yang harus dipanggil driver Anda secara
kondisional.
Jika Anda memiliki driver WDM, atau driver mode kernel non-KMDF, dan Anda
menargetkan Windows 8.1 atau Windows 8 tetapi juga ingin menjalankan versi
Windows yang lebih lama, Anda perlu mengganti opsi linker
$(KernelBufferOverflowLib). Saat Anda memilih konfigurasi Windows 8 atau
Windows 8.1, driver ditautkan dengan BufferOverflowFastFailK.lib, yang tidak
tersedia di versi Windows sebelumnya. Untuk Windows 7 dan Vista, Anda harus
menautkan dengan BufferOverflowK.lib sebagai gantinya.
Ada dua cara untuk mengganti opsi linker $(KernelBufferOverflowLib),

menggunakan MSBuild atau Visual Studio.
Menggunakan MSBuild:
C++
msbuild /p:KernelBufferOverflowLib="C:\Program Files (x86)\Windows

Kits\8.1\Lib\win8\km\x64\BufferOverflowK.lib" /p:platform=x64
/p:Configuration="Win8 Release" myDriver.sln
Menggunakan Visual Studio:
Menggunakan Notepad, atau editor teks lain, buka file proyek driver (*.vcxproj).
Dalam file proyek, temukan <PropertyGroup> untuk konfigurasi yang didukung
driver Anda, dan tambahkan baris berikut untuk mengganti opsi penautan default:
XML
XML
<KernelBufferOverflowLib>$(DDK_LIB_PATH)\BufferOverflowK.lib</KernelB
ufferOverflowLib>
Misalnya, jika driver Anda mendukung Windows 8.1 dan Windows 8 debug dan
rilis build, bagian konfigurasi tersebut akan terlihat seperti berikut:
XML
XML
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8.1
Debug|Win32'" Label="Configuration">
<TargetVersion>WindowsV6.3</TargetVersion>
<UseDebugLibraries>true</UseDebugLibraries>
ufferOverflowLib>
<PlatformToolset>WindowsKernelModeDriver8.1</PlatformToolset>
<ConfigurationType>Driver</ConfigurationType>
<DriverType>KMDF</DriverType>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8.1
Release|Win32'" Label="Configuration">
<TargetVersion>WindowsV6.3</TargetVersion>
<UseDebugLibraries>false</UseDebugLibraries>
ufferOverflowLib>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8
Debug|Win32'" Label="Configuration">
<TargetVersion>Windows8</TargetVersion>
<UseDebugLibraries>true</UseDebugLibraries>
ufferOverflowLib>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8
Release|Win32'" Label="Configuration">
<TargetVersion>Windows8</TargetVersion>
<UseDebugLibraries>false</UseDebugLibraries>
ufferOverflowLib>
</PropertyGroup>
Elemen <KernelBufferOverflowLib> harus muncul di file proyek driver sebelum

elemen yang mengimpor Microsoft.Cpp.props, yang mengimpor set alat.
Setelah Anda memodifikasi dan menyimpan file proyek driver, Anda dapat
membuka file proyek di Visual Studio dan membangun driver.
Topik terkait
Menulis driver untuk berbagai versi Windows
Membangun Driver
Membangun Driver Arm64 dengan
WDK
Windows 10 dapat berjalan pada mesin yang didukung oleh prosesor Arm64. Namun,
karena Windows 10 di Arm tidak mendukung emulasi driver x86 kernel-mode atau
UMDF, Anda harus mengkompilasi ulang driver ini ke Arm64 menggunakan instruksi di
bawah ini.
Siapkan
1. Unduh Visual Studio 2017 atau 2019 . Anda akan membutuhkan minimal versi
15.9.
2. Pada menu mulai Windows, ketik Visual Studio Installer. Kemudian pada tab
Beban Kerja , pilih Pengembangan desktop dengan C++.
3. Pada tab Komponen Individual , pilih opsi berikut ini:
Pengkompilasi dan pustaka Visual C++ untuk Arm

Pengkompilasi dan pustaka Visual C++ untuk Arm64
4. Instal dan mulai ulang Visual Studio.
5. Unduh SDK Windows. Pastikan Anda memiliki SDK versi 16299 (Windows 10, versi
1709) atau yang lebih baru.
6. Unduh WDK. Pastikan Anda memiliki WDK versi 16299 atau yang lebih baru.
Membangun Driver Arm64 dengan WDK

1. Di Visual Studio, buka solusi driver. Anda dapat menggunakan sendiri, atau dari
repositori Windows-driver-samples .
2. Pilih Platform solusi dan pilih Configuration Manager.
3. Di bawah Platform Solusi Aktif, pilih Baru.
4. Dari Jenis atau Pilih Platform baru, pilih Arm64. Salin pengaturan dari Win32. Pilih
OK dan Tutup.
5. Pilih Arm64 sebagai platform target dan bangun kembali.
Lihat juga
Men-debug Arm64
Windows 10 di Arm
Panduan Memulai HLK Arm64
Menggunakan WDK Enterprise
Enterprise Windows Driver Kit (Enterprise WDK) adalah lingkungan build baris perintah
yang tidak memerlukan instalasi apa pun sebelum digunakan. Setelah Mengunduh
EWDK, Anda dapat mengelolanya dengan perangkat lunak kontrol versi atau Anda
dapat zip file dan menyalin sesuai kebutuhan. File .zip yang dibuat dengan WDK
Enterprise berisi semua kompiler, tautan, alat build, header, dan libs yang diperlukan
untuk membangun proyek driver berbasis Visual Studio.
WDK Enterprise berisi elemen yang diperlukan untuk membangun driver dan aplikasi uji
driver Win32 dasar. Gunakan editor kode favorit Anda untuk memodifikasi kode sumber
dan file proyek. Karena berbasis baris perintah, Enterprise WDK tidak memiliki beberapa
fitur yang dimasukkan ke dalam Visual Studio, seperti IDE, penyebaran driver dan
pengujian driver.
Memulai
７ Catatan
Mulai Windows 10 versi 1709, Enterprise WDK berbasis ISO. Untuk memulai, unduh
dan pasang ISO, lalu jalankan LaunchBuildEnv .
1. Unduh EWDK dari: unduhan WDK & EWDK

2. Perluas file .zip ke direktori bernama tepat, seperti d:\ewdk.
3. Dari command prompt Administrator, navigasikan ke folder yang diperluas di
langkah sebelumnya, lalu jalankan LaunchBuildEnvcmd untuk membuat
lingkungan build. Misalnya: D:\EWDK\LaunchBuildEnv
Setelah membuat lingkungan build, Anda dapat menggunakannya untuk mengerjakan

file atau membangun proyek Visual Studio. Contohnya.
cd directory_containing_project_files
Msbuild projectname.vsproj
Perintah MSBuild dasar untuk proyek dan solusi:
Proyek Msbuild.vcxproj /p:configuration=[release | debug] /p:platform=[arm | |

Win32 x64]
Untuk membuat pintasan desktop:

%comspec% /k mendorong <drive\dir> && LaunchBuildEnv.cmd
Di mana <drive\dir> lokasi file diekstraksi, misalnya, d:\ewdk
%comspec% /k mendorong "d:\ewdk" && LaunchBuildEnv.cmd
Lihat juga
Referensi MSBuild
Memasang Lingkungan Build WDK 8.1 di
Lab
Windows Driver Kit (WDK) 8.1 menyediakan fitur yang memungkinkan Anda menyalin
komponen Visual Studio dan WDK ke lokasi baru dan kemudian meluncurkan
lingkungan build dari baris perintah. Dari sini Anda dapat membangun driver Windows
tanpa harus menjalankan program instalasi Visual Studio atau WDK.
Anda mungkin menemukan fitur ini berguna jika Anda perlu mengintegrasikan WDK
dengan proses pembuatan Anda, atau jika Anda ingin mendistribusikan proses
pembuatan di laboratorium atau lingkungan pengujian.
Nota Anda hanya dapat menggunakan fitur ini untuk membangun driver dan aplikasi
yang menggunakan C dan C ++. Fitur ini tidak dapat digunakan untuk kode terkelola
atau aplikasi UWP.
1. Unduh file pengaturan Visual Studio dan

WDK dan SDK
Untuk menjalankan skrip pengaturan yang memungkinkan fitur ini, Anda perlu
menyediakan jalur ke file penyiapan Visual Studio dan WDK. Pastikan untuk menyimpan
file-file ini (daripada menginstalnya).
1. Unduh Visual Studio Professional 2013 atau Visual Studio Ultimate 2013 .
Unduh Tata Letak Produk (misalnya, vs_ultimate_download.exe). Ketika Anda
ditanya apakah Anda ingin menjalankan atau menyimpan
vs_ultimate_download.exe, pilih Jalankan lalu pilih opsi unduh dan tentukan jalur
unduhan sebagai C:\VSSetup (ini membuat langkah selanjutnya lebih mudah). Pilih
Unduh untuk mengunduh dan menginstal salinan lokal tata letak DVD di
komputer.
2. Unduh SDK mandiri. Saat Anda ditanya apakah Anda ingin menjalankan atau
menyimpan sdksetup.exe, pilih Jalankan lalu tentukan lokasi unduhan sebagai
C:\Kits\SDK. Pilih Berikutnya dan ikuti petunjuk untuk mengunduh SDK mandiri.
3. Unduh WDK 8.1. Saat Anda ditanya apakah Anda ingin menjalankan atau
menyimpan wdksetup.exe, pilih Jalankan lalu tentukan lokasi unduhan sebagai
C:\Kits\WDK. Pilih Berikutnya dan ikuti petunjuk untuk mengunduh WDK. Jika
Anda telah menginstal WDK di komputer, program instalasi web akan memberi
tahu Anda bahwa fitur yang diinstal pada komputer sudah diperbarui. Untuk
mengunduh file penyiapan WDK sehingga Anda dapat menyebarkan lingkungan
build, pilih Berikutnya dan tentukan jalur C:\Kits\WDK .
2. Unduh file BuildLabSupport

Untuk dapat menginstal lingkungan build WDK pada komputer di laboratorium, Anda
harus terlebih dahulu mengunduh file dukungan lab build di komputer Anda.
1. Unduh BuildLabSupportfiles.zip .
2. Ekstrak konten file terkompresi ke komputer Anda. File yang diekstraksi termasuk
direktori BuildLabSupport dan menyertakan file penyiapan dan utilitas yang Anda
butuhkan.
3. Pasang lingkungan build WDK 8.1

File dukungan build lab termasuk file perintah PowerShellsetup.ps1, yang mengekstrak
komponen Visual Studio dan WDK yang diperlukan dan menyalinnya ke direktori target
(folder). Anda kemudian dapat menyalin direktori ini ke lokasi lain, dari mana Anda
dapat membangun proyek di lingkungan pengembangan antarmuka baris perintah (CLI)
yang Visual Studio.
Buka jendela Command Prompt dengan hak istimewa yang ditinggikan (Jalankan
sebagai administrator) dan buka direktori tempat Anda mengekstrak file
dukungan lab build. Skrip perintah PowerShell setup.ps1 ada di < direktori
root>\BuildLabSupport.
Sintaks untuk perintah PowerShell adalah sebagai berikut:
PowerShell
powershell –executionpolicy bypass –file Setup.ps1 –DeployBuildLab –

VSInstallerPath <VSInstallerFilePath> -KitInstallersPath
<KitInstallersPath> -ExpansionRoot <Target Directory> –LogFilePath
<LogFilePath> -CatalogFile <Filename.xml>
<VSInstallerFilePath> adalah jalur ke program instalasi Visual Studio (misalnya,

Vs_ultimate.exe) dan direktori yang berisi tata letak produk.
<KitInstallersPath> adalah jalur ke file pengaturan WDK dan SDK.
<Direktori> Target adalah direktori target untuk konten yang diekstraksi.
<LogFilePath> adalah tujuan target untuk file log.
<>Filename.xml adalah nama CatalogFile, yang berisi daftar file instalasi
Windows Microsoft (MSI) untuk diperluas sebagai bagian dari instalasi. Nama
file files.xml.
Misalnya, perintah berikut menjalankan skrip dari direktori BuildLabSupport dan

menginstal lingkungan build di direktori C:\BuildLabInstall.
C++
c:\BuildLabSupport>powershell -executionpolicy bypass -file Setup.ps1 -

DeployBuildLab -VSInstallerPath c:\VSSetup -KitInstallersPath c:\Kits -
E
xpansionRoot C:\BuildLabInstall -CatalogFile files.xml
4. Bangun proyek dan solusi driver Windows

Menggunakan skrip perintah lingkungan build
1. Buka jendela Prompt Perintah. Temukan file LaunchBuildEnv.cmd yang terletak di

direktori target (misalnya, C:\BuildLabInstall).
2. Luncurkan lingkungan build dengan menjalankan LaunchBuildEnv.cmd.
3. Gunakan perintah MSBuild untuk membangun proyek dan solusi driver Anda.
Contohnya:
C++
msbuild /t:clean /t:build .\MyDriver.vcxproj /p:Configuration="Win8.1

Debug" /p:Platform=Win32
Topik terkait
Membangun Driver
MSBuild
Menggunakan Microsoft C Runtime
dengan Driver User-Mode dan Aplikasi
Desktop
Jika Anda membangun aplikasi atau driver untuk Windows 10, Anda hanya perlu
membaca bagian ini. Jika Anda menggunakan versi Visual Studio lebih awal dari Visual
Studio 2015, lewati bagian ini dan mulailah dengan Mendistribusikan Kembali Runtime C
(berlaku sebelum Visual Studio 2015).
Mulai tahun Visual Studio 2015, Universal C Runtime (UCRT) mencakup runtime C.
Bagian lain yang diperlukan untuk program lengkap (Fitur Bahasa C / C ++,
Perpustakaan C ++) disediakan oleh Visual Studio di VC ++ Redistributable. Untuk
menghindari persyaratan redistribusi runtime, potongan-potongan tersebut
dihubungkan secara statis.
２ Peringatan
Saat membangun proyek driver mode pengguna di Visual Studio, jika Anda
mengatur PlatformToolset ke WindowsUserModeDriver10.0 , toolset mengabaikan
pustaka runtime apa pun yang ditentukan dalam proyek dan sebagai gantinya
menautkan secara statis terhadap Runtime VC ++ dan secara dinamis melawan
UCRT. Saat menggunakan toolset ini, perilaku penautan hibrid ini tidak dapat
dikonfigurasi ulang.
Jika Anda tidak menggunakan WindowsUserModeDriver10.0 toolset, gunakan prosedur

berikut untuk melakukan modifikasi (misalnya sertakan DLL lain):
1. Atur untuk menautkan secara statis secara umum: Pustaka Runtime Pembuatan >
Kode Properti > C/C++ > = Multi-threaded (/MT)
2. Hapus UCRT yang terhubung secara statis: Input > Tautan > Properti > Abaikan
Pustaka Default Tertentu += libucrt.lib
3. Tambahkan UCRT yang terhubung secara dinamis: Properties > Linker > Input >
Dependensi Tambahan += ucrt.lib, Input > Linker > Properti > Abaikan Pustaka
Default Tertentu += libucrt.lib
Mendistribusikan kembali Runtime C (berlaku
sebelum Visual Studio 2015)
７ Catatan
Semua informasi di bawah titik ini hanya berlaku untuk pra-2015. Sebelum 2015,
ada dua versi terpisah dari C Runtime: Visual C ++ Runtime (VCRT,
misalnya msvcr120.dll ) dan warisan Windows CRT ( msvcrt.dll ).
Visual Studio menginstal versi terbaru VCRT ke System32 dalam direktori. Jika file tidak
berada di lokasi ini, Anda dapat menyalinnya langsung ke direktori build proyek Visual C
++Anda.
Jika driver mode pengguna atau aplikasi desktop Anda menggunakan VCRT, Anda harus
mendistribusikan pustaka tautan dinamis yang sesuai. Gunakan Paket Visual C ++
Redistributable ( VCRedist_x86.exe , , VCRedist_x64.exe VCRedist_arm.exe ). Rantai paket
yang dapat didistribusikan kembali dengan binari lain, dan paket yang dapat
didistribusikan kembali akan menerima pembaruan otomatis.
Jika Anda ingin mencapai isolasi atau menghindari ketergantungan pada VC ++

redistributable, Anda dapat menghubungkan secara statis ke CRT sebagai gantinya.
Sementara proyek non-driver biasanya dapat menyalin DLL Visual C / C + + tertentu ke
folder lokal aplikasi (tempat aplikasi diinstal) untuk menghindari ketergantungan pada
VC ++ yang dapat didistribusikan ulang, penyebaran aplikasi-lokal tidak sesuai untuk
driver.
Jangan menyalin komponen CRT individual alih-alih System32 menggunakan paket yang
dapat didistribusikan ulang. Hal ini dapat menyebabkan CRT tidak diservis secara
otomatis, dan berpotensi ditimpa.
Pertimbangan khusus berikut berlaku untuk pengandar pencetak:
Driver ini harus menyertakan file CRT yang diperlukan di INF, sehingga file CRT
disalin ke toko driver sebagai bagian dari muatan driver.
Driver cetak V4 tidak dapat menggunakan penginstal bersama untuk penyiapan,
sehingga INF harus menyalin binari yang relevan dari pustaka runtime C/C++ ke
penyimpanan driver. Untuk melakukan ini, rujuk file yang sesuai di bagian
[COPY_FILES] dari paket driver.
Driver cetak V3 tidak boleh menggunakan penginstal bersama untuk penyiapan,
karena tidak dijalankan selama koneksi Titik dan Cetak. Driver ini harus
mereferensikan file yang sesuai di bagian [COPY_FILES] dari paket driver.
Berikut ini adalah contoh cara memasukkan binari CRT di bagian [COPY_FILES] dari INF:
INF
[COPY_FILES]
;CRT
Msvcr120.dll
; other files
* [SourceDisksFiles]
Msvcr120.dll = 2
; other files
* [SourceDisksNames.amd64]
1 = %Location%,,,
2 = %Location%,,,"amd64"
Untuk driver UMDF:
Tautkan driver Anda secara statis ke CRT untuk menyertakan runtime dalam biner.
Dalam hal ini, Anda tidak perlu mendistribusikan kembali CRT.
Menautkan kode Anda dengan pustaka

Runtime C (berlaku sebelum Visual Studio
2015)
Untuk menentukan DLL mana yang harus Anda distribusikan kembali dengan aplikasi
Anda, kumpulkan daftar DLL yang bergantung pada aplikasi Anda. Salah satu cara untuk
mengumpulkan daftar adalah menjalankan Dependency Walker ( depends.exe ).
Untuk informasi selengkapnya, lihat Menentukan DLL Mana yang akan Didistribusikan
Ulang dan Memilih Metode Penyebaran.
Anda tidak dapat mendistribusikan kembali semua file yang disertakan dalam Visual
Studio; Anda hanya diizinkan untuk mendistribusikan kembali file yang ditentukan
dalam Kode Redistributable untuk Pratinjau Visual Studio 2013 dan Pratinjau SDK Visual
Studio 2013 . Versi debug aplikasi dan berbagai pustaka visual C ++ dynamic-link tidak
dapat didistribusikan ulang.
Pustaka berikut berisi fungsi pustaka run-time C:
Istilah Deskripsi
Msvcr120.dll Runtime C
Istilah Deskripsi
Msvcp120.dll Runtime C++
Msvcr120d.dll Versi debug runtime C - tidak ada redistribusi yang diizinkan
Msvcp120d.dll Versi debug runtime C++ - tidak ada redistribusi yang diizinkan
Menghindari Kesalahan Floating Point di
Lingkungan Build Kustom
Informasi ini ditujukan untuk pengembang dan insinyur build yang mengkompilasi
driver mode kernel untuk Windows. Di Microsoft Visual Studio Professional 2012,
arsitektur default untuk kompiler Visual C ++ (VC ++) berubah dari IA32 ke set instruksi
Streaming SIMD Extensions 2 (SSE2). Sebagai hasil dari perubahan ini, instruksi floating
point (FP) SSE2 yang disuntikkan ke dalam biner pada waktu kompilasi dapat
menghasilkan kesalahan floating-point jika tidak diperhitungkan. Masalah ini dapat
dihadapi oleh mereka yang menggunakan kompiler Microsoft VC ++, atau lingkungan
build khusus untuk mengembangkan driver Windows. Namun, masalah ini tidak
mempengaruhi pengembang yang menggunakan lingkungan pengembangan Microsoft
Visual Studio, atau yang menggunakan utilitas MSbuild untuk membangun driver
dengan toolset yang tidak dimodifikasi.
Kesalahan floating point dapat menyebabkan

kerusakan data atau crash komputer
Jika Anda mengkompilasi driver tanpa menggunakan WDK, Visual Studio, dan toolset
platform yang direkomendasikan untuk driver Windows
(WindowsKernelModeDriver8.0), driver mungkin tidak mengelola operasi floating point
dengan benar, bahkan jika driver mengkompilasi tanpa kesalahan.
Kompiler VC ++ profesional Visual Studio 2012 memancarkan kode yang menggunakan

instruksi SSE2 yang ditetapkan dengan mengatur opsi kompiler /arch:sse2. Dimulai
dengan Visual Studio Professional 2012, ini adalah opsi default untuk pembuatan kode
kompiler x86 VC ++. Secara khusus, nilai default berubah dari /arch:ia32 ke /arch:sse2.
Untuk aplikasi perubahan ini menghasilkan kode yang berkinerja lebih baik dan
menggunakan lebih sedikit waktu prosesor selama eksekusi. Namun, untuk driver
kernel-mode perubahan ini tidak akan mengelola status floating point (FP) dengan
benar. Hal ini disebabkan oleh kompiler VC ++ yang memperkenalkan urutan instruksi
FP di tempat-tempat di mana konteksnya belum disimpan. Setiap sistem floating-point
biner hanya dapat mewakili sejumlah nilai floating-point yang terbatas dalam bentuk
yang tepat, dengan sisanya adalah perkiraan. Keadaan kontrol floating-point, seperti,
mode pembulatan atau presisi, adalah apa yang membuat operasi FP selaras satu sama
lain. Ketika status tidak terdefinisi, ini mengarah ke kesalahan perhitungan FP. Kesalahan
perhitungan ini sulit dideteksi karena dalam banyak kasus korupsi negara aplikasi adalah
satu-satunya tanda masalah ini. Korupsi ini dapat memanifestasikan dirinya dalam
banyak hal, mulai dari crash acak hingga korupsi data.
Larutan
Untuk menghindari masalah ini dengan perhitungan floating-point, tambahkan bendera
/kernel ke baris perintah kompiler dan linker C ++ untuk mencegah menghasilkan
instruksi SSE2. Bendera /kernel mengubah nilai default /arch:sse2 kembali ke
/arch:ia32.
Selain itu, jika Anda membangun driver menggunakan WDK dan lingkungan
pengembangan Visual Studio Professional 2012, atau menggunakan MSBuild, di jendela
prompt Command Visual Studio, toolset platform yang disediakan Microsoft
(WindowsKernelModeDriver8.0) menetapkan bendera /kernel. Akibatnya, kesalahan
generasi floating-point dihindari.
C++
msbuild myProject.vcxproj /p:PlatformToolset=WindowsKernelModeDriver8.0
Rekomendasi
Berikut adalah solusi yang direkomendasikan berdasarkan jenis lingkungan
pengembangan yang Anda gunakan:
Set alat Microsoft (MSBuild) - Tidak perlu pekerjaan. Gunakan

WindowsKernelModeDriver8.0 sebagai toolset platform / kernel secara otomatis
ditambahkan jika sesuai.
Microsoft VC ++ Compiler - Tambahkan bendera /kernel untuk mencegah
kompiler memancarkan SSE2.
Custom Tooling /Non-Microsoft Compiler - Anda harus memperhitungkan
instruksi perakitan yang digunakan dalam biner yang dihasilkan secara manual.
Properti Preprosesor Manifes Counter
untuk Proyek Driver
Mengatur properti untuk alat CTRPP yang mengurai dan memvalidasi manifes
penghitung Anda. Untuk informasi tentang bekerja dengan penghitung kinerja, lihat
Penghitung Kinerja. Untuk informasi tentang menggunakan penghitung kinerja dalam
mode kernel Windows driver, lihat Pemantauan Kinerja Mode Kernel.
Mengatur properti Counters Manifest

Preprocessor untuk proyek driver
1. Buka halaman properti untuk proyek driver Anda. Pilih dan tahan (atau klik kanan)
proyek driver di Penjelajah Solusi dan pilih Properti.
2. Di halaman properti untuk proyek pengandar, pilih Properti Konfigurasi lalu pilih
Properti Preprosesor Manifes Penghitung.
3. Atur properti untuk proyek.
Jika Anda ingin menambahkan halaman properti ini ke proyek Anda sehingga Anda
dapat menjalankan alat CTRPP selama proses pembuatan, lihat lingkungan build WDK
dan Visual Studio dan tugas Ctrpp.
Opsi Deskripsi
Tambahkan Awalan Menentukan awalan yang akan digunakan

untuk variabel dan fungsi global yang
ditentukan dalam file header yang dihasilkan
(sama dengan opsi perintah -awalan .)
Opsi Tambahan Menentukan opsi tambahan ke alat CTRPP .
Kompatibilitas Ke Belakang Menghasilkan kode yang kompatibel dengan

biner dengan versi Windows sebelum Windows
7 (sama dengan opsi perintah -backcompat).
Aktifkan Warisan Kembali ke menghasilkan kode menggunakan

templat kode Vista Windows. Opsi ini
menyebabkan CTRPP menghasilkan empat file
output: dua file header (.h, _r.h), file sumber
daya (.rc), dan file kode sumber (c). (-warisan)
Opsi Deskripsi
Buat file header untuk berisi nama penghitung Membuat file header yang menetapkan simbol
dan GUID ke nama set penghitung dan GUID untuk setiap
penghitung yang ditetapkan dalam manifes.
Membuat file header untuk penyedia Menentukan nama file header yang dihasilkan
alat. Jika Anda tidak menentukan jalur, file
dihasilkan di folder saat ini.
Hasilkan Rutinitas Memori Hasilkan alokasi memori/templat rutin gratis. (-

MemoryRoutines)
Menghasilkan Callback Notifikasi Buat templat callback notifikasi yang

disesuaikan. (-NotificationCallback )
Menghasilkan file sumber daya Menentukan nama file sumber daya yang
dihasilkan alat. Jika Anda tidak menentukan
jalur, file dihasilkan di folder saat ini.
Hasilkan File Global Ringkasan Menghasilkan file penghitung biner per

penyedia. (-summarypath)
Menghasilkan ringkasan file global

GenSumResource.BIN.
Jalur File Penghitung yang Dihasilkan Menentukan jalur untuk menghasilkan file
penghitung biner. (-sumPathpath)
Jika tidak ada jalur yang ditentukan, direktori

saat ini digunakan.
Nama File Header Untuk Penghitung Menghasilkan file header untuk berisi nama
dan id penghitung. (-chfilename)
Header FileName Untuk Penyedia Menghasilkan file header untuk penyedia. Ini
menggantikan nama default. (-ofilename)
Nama File Sumber Daya Menentukan nama untuk file sumber daya. Ini
menggantikan nama default. (-rcfilename)
Komentar
Nama default file yang dihasilkan alat didasarkan pada nama file manifes yang Anda
lewati ke alat CTRPP .
Topik terkait
CTRPP
Penghitung Performa
Pemantauan Kinerja Mode Kernel
Properti Pengaturan Model Driver untuk
Proyek Driver
Mengatur properti dasar untuk driver mode kernel atau mode pengguna, termasuk versi
pustaka WDF dan definisi pra-prosesor.
Mengatur properti model driver untuk proyek

driver
proyek driver di Průzkumník řešení dan pilih Properti.
2. Di halaman properti untuk proyek driver, pilih Properti Konfigurasi lalu pilih
Pengaturan Model Driver.
Jenis driver
Jenis driver ketika jenis Konfigurasi driver adalah Driver. Perhatikan bahwa opsi ini
hanya tersedia saat proyek menggunakan toolset WindowsKernelModeDriver8.0 .
Potensi nilai:
WDM (termasuk semua driver miniport/port seperti NDIS atau StorPort).

KMDF Pengemudi KMDF.
Driver ekspor (WDM) Driver WDM yang mengekspor fungsi yang dapat dipanggil
driver lain. Untuk informasi selengkapnya, lihat Membuat Driver Ekspor.
Jurusan Versi KMDF
Ketika jenis driver adalah KMDF, opsi ini menentukan versi utama KMDF yang akan
digunakan saat mengkompilasi driver Anda.
Entri KMDF_VERSION_MAJOR menginformasikan utilitas MSBuild bahwa ia harus

menautkan driver ke pustaka KMDF.
Untuk informasi selengkapnya, lihat Penerapan Versi Pustaka Kerangka Kerja.
KMDF Version Minor (Versi Target) (adalah KMDF Version Minor sebelum Windows 10,
versi 1803) Ketika jenis driver adalah KMDF, opsi ini menentukan versi minor KMDF yang
akan digunakan saat mengkompilasi driver Anda.
Untuk informasi selengkapnya, lihat Penerapan Versi Pustaka Kerangka Kerja. Jika Anda
tidak menentukan Versi KMDF Minor (Versi Target), Visual Studio menggunakan default
berikut:
Windows 10 / Windows 11: 1.15

Windows 8 / Windows 8.1: 1.11
Windows 7: 1.9
KMDF Version Minor (Minimum Required) (opsional, tersedia mulai dari Windows 10,
versi 1803) Mulai dari KMDF versi 1.25 dan UMDF versi 2.25 pada Windows 10 versi
1803 (Redstone 4), Anda dapat membangun driver KMDF yang menargetkan rentang
versi kerangka kerja. Gunakan pengaturan opsional ini untuk menentukan versi KMDF
minimum rentang ini.
Untuk detailnya, lihat Membangun driver WDF untuk beberapa versi Windows.
UMDF Version Major
Ketika Anda memiliki driver UMDF, opsi ini menentukan versi utama UMDF yang akan
digunakan saat mengkompilasi driver Anda. Lihat Riwayat Versi UMDF. Ketika Anda
memiliki driver UMDF, jenis Konfigurasi adalah Pustaka Dinamis (.dll).
UMDF Version Minor (Versi Target) (adalah UMDF Version Minor sebelum Windows 10,
versi 1803) Ketika Anda memiliki driver UMDF, opsi ini menentukan versi minor UMDF
yang akan digunakan saat mengkompilasi driver Anda. Jika Anda tidak menentukan
UmDF Version Minor (Versi Target), Visual Studio menggunakan default berikut:
Untuk versi utama = 2:
Windows 10 / Windows 11: 2.15

Lainnya: 2.0
Untuk versi utama = 1:
Windows 8 ke atas: 1.11

Windows 7: 1.9
UMDF Version Minor (Minimum Required) (opsional, tersedia mulai dari Windows 10,
versi 1803)
Mulai dari KMDF versi 1.25 dan UMDF versi 2.25 pada Windows 10 versi 1803 (Redstone
4), Anda dapat membangun driver UMDF yang menargetkan rentang versi kerangka
kerja. Gunakan pengaturan opsional ini untuk menentukan versi UMDF minimum
rentang ini.
Untuk detailnya, lihat Membangun driver WDF untuk beberapa versi Windows.
Izinkan Tanggal, Waktu, dan Tanda Waktu
Menentukan makro C/CPP standar untuk __DATE__, __TIME__, __TIMESTAMP__.
Mengesampingkan Definisi Prapemroseduran Konfigurasi Target
Mengesampingkan nilai default untuk simbol pra-pemrosesan: _WIN32_WINNT,

WINVER, WINNT, dan NTDDI_VERSION untuk file sumber Anda. Perhatikan bahwa nilai
default dikontrol oleh konfigurasi target saat ini.
Topik terkait
Penerapan Versi Pustaka Kerangka Kerja
Membangun dan Memuat Driver Berbasis Kerangka Kerja
Riwayat Versi UMDF
Membangun Driver UMDF
Membuat Driver Ekspor
Properti Kompiler Pesan untuk Proyek
Driver
Mengatur properti untuk alat Penyusun Pesan (MC.exe ). Kompiler menghasilkan file
sumber daya pesan yang dapat Anda tambahkan ke proyek Anda.
Misalnya, jika Anda menggunakan API mode kernel Pelacakan Peristiwa untuk Windows
(ETW) untuk menambahkan penelusuran peristiwa ke driver mode kernel, Anda dapat
menggunakan kompiler pesan untuk membuat file header yang berisi definisi untuk
penyedia peristiwa, atribut peristiwa, saluran, dan peristiwa. Anda harus menyertakan file
header ini dalam kode sumber Anda. Kompiler pesan membuat skrip kompiler sumber
daya (*.rc) yang Anda tambahkan ke file proyek Anda.
Mengatur properti Penyusun Pesan untuk

proyek driver
Penyusun Pesan.
Halaman properti ini tersedia jika Anda menambahkan file teks pesan (.mc) atau manifes
(.man) ke solusi Anda.
Opsi Deskripsi
Opsi Tambahan Menentukan opsi tambahan untuk diteruskan

ke alat Penyusun Pesan (MC.exe ).
Berkas Input Ansi Menentukan bahwa file input berisi konten

ANSI (ini adalah default). (-a)
Pesan Ansi dalam file Bin Menentukan bahwa pesan dalam file output
.bin harus ANSI. (-A)
Jalur Dasar Jalur harus mengarah ke folder yang berisi . BIN

file yang operasi baseline dibuat. (-tdirectory)
Jalur Sumber Daya Dasar Folder yang berisi file manifes dasar. (-
sdirectory)
Opsi Deskripsi
Jalur Output Debug Jalur tempat untuk menempatkan file .dbg C

disertakan. (-xpath)
Aktifkan Makro Panggilan Menambahkan makro callout untuk memanggil

kode pengguna saat masuk. Tidak tersedia
untuk C #, dan diabaikan. (-co)
Aktifkan Jalur Keluaran Debug Memungkinkan kompiler untuk menempatkan

file sertakan .dbg C yang ditentukan oleh
properti Jalur Output Debug .
Ekstensi file untuk header yang dihasilkan Menentukan ekstensi file header yang
dihasilkan. (-eextension)
Hasilkan Sumber Daya Dasar Membuat garis dasar instrumentasi Anda.
Hasilkan kelas pencatatan C# (terkelola) Menghasilkan kelas pencatatan C# (terkelola)

yang menyertakan metode yang akan Anda
panggil untuk mencatat peristiwa dalam
manifes Anda. (-csnamespace)
Buat file header untuk berisi nama Gunakan opsi ini untuk menentukan folder
penghitung dan GUID tempat Anda ingin kompiler menempatkan file
header yang dihasilkan.
Hasilkan Makro Pencatatan Mode Kernel Menghasilkan makro pencatatan mode kernel.
(-km)
Hasilkan File MOF Hasilkan dukungan tingkat bawah untuk semua

fungsi dan makro yang dihasilkan. File MOF
akan dihasilkan dari manifes. File MOF akan
ditempatkan di lokasi yang ditentukan oleh
opsi -h (-mof).
Hasilkan Header OLE2 Menghasilkan file header OLE2. (-o)
Hasilkan kelas pencatatan C# (terkelola) statis Menghasilkan kelas pencatatan C# (terkelola)

statis yang mencakup metode yang akan Anda
panggil untuk mencatat peristiwa dalam
manifes Anda. (-cssnamespace)
Hasilkan Makro Pencatatan Mode Pengguna Hasilkan makro pencatatan mode pengguna. (-
um)
Nama Dasar File yang Dihasilkan Menentukan nama dasar semua file yang
dihasilkan. (-zbasename)
Jalur File Pesan RC dan Biner yang Dihasilkan Menentukan jalur ke file pesan RC dan biner
yang dihasilkan.
Opsi Deskripsi
Jalur File Header Menentukan jalur file header yang dihasilkan. (-

hpath)
Panjang Pesan Maksimum Gunakan argumen ini agar kompiler

menghasilkan peringatan jika ada pesan yang
melebihi karakter panjang. (-mlength)
Nama Makro Awalan Gunakan argumen ini untuk mengganti awalan

default yang digunakan kompiler untuk nama
makro pencatatan dan nama metode. (-pprefix)
Jalur Berkas RC Folder tempat Anda ingin kompiler

menempatkan skrip kompiler sumber daya
yang dihasilkan (file.rc) dan file .bin yang
dihasilkan. (-rpath)
Hapus karakter dari nama simbolik Gunakan argumen ini untuk menghapus
karakter dari awal nama simbolik yang Anda
tentukan untuk acara tersebut. (-Pprefix)
Atur Bit Pelanggan Mengatur bit Pelanggan di seluruh Id pesan. (-

c)
Mengakhiri Pesan Dengan Null Mengakhiri semua string dengan null di tabel
pesan. (-n)
Unicode Input File Menentukan bahwa file input berisi konten

Unicode. (-u)
Defaultnya adalah ANSI.
Pesan Unicode Dalam File Bin Menentukan bahwa pesan dalam file output
.bin adalah Unicode. (-U)
Ini adalah default.
Gunakan nama dasar input Gunakan argumen ini agar kompiler

menggunakan nama dasar file input untuk
nama file output .bin. (-b)
Menggunakan Nilai Desimal Gunakan argumen ini untuk menggunakan nilai

desimal untuk konstanta Keparahan dan
Fasilitas dalam file header, bukan nilai
heksadesimal. (-d)
Validasi Terhadap Sumber Daya Dasar Gunakan argumen ini saat Anda membuat versi
baru manifes Anda dan ingin memeriksa
kompatibilitas aplikasi terhadap garis dasar
yang Anda buat menggunakan opsi -s .
Opsi Deskripsi
Penyedehanaan kata Gunakan opsi ini untuk menghasilkan output

bertele-tele. (-v)
Topik terkait
Kompiler Pesan (MC.exe)
WDK dan Visual Studio membangun lingkungan Tugas kompiler pesan
Aktivitas Pelacakan untuk Windows (ETW)
Properti Kompiler MOF untuk Proyek
Driver
Kompiler Managed Object Format (MOF) (mofcomp.exe) mengurai file MOF dan
menambahkan kelas dan instans kelas yang ditentukan dalam file ke repositori WMI.
Gunakan halaman properti Mofcomp untuk mengkompilasi file MOF dengan driver
Anda. Untuk informasi lebih lanjut tentang Mofcomp.exe dan WMI, lihat mofcomp,
Mengkompilasi File MOF, dan Menyusun File MOF Driver.
Mengatur properti Kompiler Managed Object

Format (MOF) untuk proyek driver
2. Di halaman properti untuk proyek driver, pilih Properti Konfigurasi lalu pilih
Kompiler Mof.
Halaman properti ini tersedia jika Anda menambahkan file Managed Object Format
(MOF) (.mof) ke solusi Anda.
Opsi Deskripsi
Opsi Tambahan Menentukan opsi tambahan untuk diteruskan

ke alat mofcomp .
Perubahan Membagi file MOF menjadi versi netral bahasa

dan -spesifik. (-AMANDEMEN:Lokal)
Wewenang Menentukan Otoritas sebagai otoritas (nama

domain) untuk digunakan saat masuk ke WMI.
(-A:Otoritas)
Pemulihan Otomatis Menambahkan file MOF bernama ke daftar file

yang dikompilasi selama pemulihan repositori.
(-autorecover)
Buat File Mof Biner Meminta agar kompiler membuat versi biner
dari file MOF dengan nama file nama tanpa
membuat modifikasi apa pun pada repositori
WMI. (-B:Nama file)
Opsi Deskripsi
Output Netral Bahasa Nama output netral bahasa. (-MOF:Jalur)
Output Khusus Bahasa Nama output spesifik bahasa. (-MFL:Jalur)
Kelas Mof Membuat atau memperbarui kelas MOF.
Buat Saja (-class:createonly) Meminta agar

kompiler tidak membuat perubahan apa pun
pada kelas yang ada. Ketika sakelar ini
digunakan, operasi kompilasi berakhir jika kelas
yang ditentukan dalam file MOF sudah ada.
Pembaruan Gaya (class:forceupdate) Memaksa

pembaruan kelas ketika kelas anak yang
bertentangan ada.
Brankas Update (-class:safeupdate)

Memungkinkan pembaruan kelas meskipun
ada kelas anak, selama perubahan tersebut
tidak menyebabkan konflik dengan kelas anak.
Perbarui Saja (-class:updateonly) Meminta

agar kompiler tidak membuat kelas baru.
Lihat mofcomp untuk informasi lebih lanjut.
NamespacePath Meminta agar kompiler memuat file MOF ke

dalam namespace yang ditentukan sebagai
namespacepath. (-N:namespacepath)
Lokal Sumber Daya Mengekstrak deskripsi MOF lokal dari MOF

biner saat digunakan dengan sakelar -ER. (-
L:ResourceLocale)
Nama Sumber Daya Mengekstrak MOF biner dari sumber daya

bernama. (-ER:Nama Sumber Daya)
Pemeriksaan Sintaks Meminta agar kompiler melakukan

pemeriksaan sintaks saja dan mencetak pesan
kesalahan yang sesuai. Tidak ada opsi lain yang
dapat digunakan dengan opsi Syntax Check .
Pemeriksaan Sintaks WMI Meminta agar kompiler melakukan

pemeriksaan sintaks WMI -WMI . Jika Anda
memilih opsi ini, Anda juga harus memilih opsi
Buat File Mof Biner (-B:Nama file)
Topik terkait
Menyusun File MOF
Menyusun File MOF Driver
mofcomp
Properti Stampinf untuk Proyek Driver
Mengatur properti untuk alat Stampinf . Anda dapat menggunakan Stampinf untuk
memperbarui arahan file INF dan INX umum saat Anda membuat driver.
Mengatur properti Stampinf untuk proyek

driver
Stampinf.
Jika Anda ingin menambahkan halaman properti ini ke proyek Anda, sehingga Anda
dapat menjalankan Stampinf selama proses pembuatan, lihat lingkungan WDK dan
Visual Studio build dan tugas Stampinf.
Opsi Stampinf Deskripsi
Aktifkan Arsitektur Memungkinkan penggantian variabel $ARCH$

yang digunakan dalam file INX. Jika diaktifkan,
nilai yang ditentukan untuk Arsitektur
digunakan. Jika Tidak ditentukan, variabel
$ARCH$ akan dihapus. Misalnya,
"Standard.NT$ARCH$" menjadi "Standard.NT".
Arsitektur Menentukan string arsitektur untuk

menggantikan variabel $ARCH$ yang
digunakan dalam file INX. Nilai default adalah
$(InfArch), makro yang memilih konfigurasi
aktif saat ini di Visual Studio. Nilai yang
mungkin termasuk x86, x64. Pengaturan ini
setara dengan menentukan opsi Stampinf-a
[architecture].
Aktifkan VersionStamp Mengaktifkan stempel waktu versi. Jika

diaktifkan, Nomor Versi Driver tidak boleh
kosong. Nomor Versi Driver menentukan
waktu yang tertulis dalam direktif INF
DriverVer untuk nomor versi. Jika tidak
diaktifkan, lihat deskripsi perilaku default untuk
opsi ini di bawah Nomor Versi Driver.
Nomor Versi Driver Menentukan waktu yang tertulis dalam direktif

INF DriverVer untuk nomor versi. Format untuk
waktu adalah
hours.minutes.seconds.milliseconds (misalnya,
11.30.20.15). Opsi ini berguna selama
pengembangan karena menyediakan cara yang
nyaman untuk meningkatkan jumlah versi
driver. Pengaturan ini setara dengan
menentukan opsi Stampinf-v [time| ].
Untuk menggunakan waktu saat ini, tentukan

tanda bintang () dengan parameter ini.
Perilaku default:
Jika Nomor Versi Driver tidak ditentukan, atau

jika Aktifkan VersionStampTidak atau tidak
ditentukan, Stampinf menggunakan salah satu
nilai nomor versi berikut:
Jika variabel lingkungan

STAMPINF_VERSION diatur, Stampinf
menggunakan nilai nomor versi yang
ditentukan oleh variabel lingkungan ini.
Jika variabel lingkungan
STAMPINF_VERSION tidak ditentukan,
Stampinf mengekstrak nomor versi dari
file ntverp.h.
Nota Secara default, variabel

lingkungan STAMPINF_VERSION
tidak diatur saat Anda membuat
driver kecuali Anda mengaturnya
sebagai variabel lingkungan sistem.
Untuk menentukan variabel
lingkungan ini dalam lingkungan
build Visual Studio, lihat Cara:
Gunakan Variabel Lingkungan
dalam Build.
Aktifkan DateStamp Mengaktifkan stempel tanggal. Jika diaktifkan,

Tanggal Direktif Versi Driver tidak boleh
kosong. Jika tidak diaktifkan, lihat deskripsi
perilaku default untuk opsi ini di bawah
Tanggal Direktif Versi Driver.
Tanggal Direktif Versi Driver Menentukan tanggal yang tertulis dalam

direktif INF DriverVer. Format untuk tanggal
adalah monthdateyear// (misalnya, 10/20/2011).
Untuk menggunakan tanggal saat ini, tentukan

tanda bintang () dengan parameter ini.
Perilaku default:
Jika parameter Tanggal Direktif Versi Driver

tidak ditentukan, atau jika Aktifkan
DateStampTidak ada atau tidak ditentukan,
Stampinf menggunakan salah satu nilai tanggal
berikut:
Jika variabel lingkungan STAMPINF_DATE

diatur, Stampinf menggunakan nilai
tanggal yang ditentukan oleh variabel
lingkungan ini.
Jika variabel lingkungan STAMPINF_DATE
tidak ditentukan, Stampinf menggunakan
tanggal saat ini.
Pengaturan ini setara dengan menentukan opsi

Stampinf-d [tanggal|].
Nota Secara default, variabel

lingkungan STAMPINF_DATE tidak
diatur saat Anda membuat driver
kecuali Anda mengaturnya sebagai
variabel lingkungan sistem. Untuk
menentukan variabel lingkungan ini
dalam lingkungan build Visual
Studio, lihat Cara: Gunakan Variabel
Lingkungan dalam Build.
Bagian Direktif Versi Driver Menentukan bagian INF untuk menempatkan

direktif INF DriverVer. Lokasi default untuk
direktif ini adalah bagian Versi INF.

Stampinf-ssection.
Nomor Versi KMDF Menentukan versi KMDF yang menjadi

tanggungan pengemudi ini. Ini digunakan
untuk menyesuaikan nama co-installer
KmdfLibraryVersion dan KMDF dalam file INF.
Opsi ini menggantikan kata kunci
$KMDFVERSION$ dan
$KMDFCOINSTALLERVERSION$ dalam file INF.
String memiliki format berikut:
<>major_version.<>minor_version
Misalnya, jika Anda menentukan 1.5 sebagai

string versi, nilai 1.5 dan 01005 digunakan
untuk dua kata kunci (masing-masing).

Stampinf-kKMDFversion.
Nomor Versi UMDF Menentukan versi UMDF yang menjadi

tanggungan pengemudi ini. Opsi ini digunakan
untuk menentukan nama penginstal bersama
UmdfLibraryVersion dan UMDF dalam file INF.
Versi yang ditentukan menggantikan kata kunci
$UMDFVERSION$ dan
$UMDFCOINSTALLERVERSION$ dalam file INF.
String versi memiliki format berikut:
<>major_version.<>minor_version.
<>service_version
(di mana <service_version> biasanya nol).
Misalnya, jika Anda menentukan 1.5.0 sebagai

string versi, nilai 1.5.0 dan 01005 digunakan
untuk kata kunci utama dan minor (masing-
masing).

Stampinf-uUMDFversion.
Nama File Katalog Menentukan nilai yang ditulis dalam direktif

CatalogFile di bagian Versi INF. Secara default,
direktif CatalogFile tidak ditulis.

Stampinf-ccatalogfile.
Penyedehanaan kata Memperlihatkan output Stampinf verbose.

Stampinf-n .
Jalur Header Versi Menentukan lokasi file Ntverp.h. Jalur mewakili

lokasi direktori yang sepenuhnya memenuhi
syarat yang berisi Ntverp.h.

Stampinf-ipath.
Topik terkait
Stampinf
Direktif Inf DriverVer
Bagian Versi INF
WDK dan Visual Studio membangun lingkungan
Tugas Stampinf
Cara: Gunakan Variabel Lingkungan dalam Build
Konversi Proyek WDK 8.1 menjadi WDK
10
Topik ini menjelaskan cara mengonversi proyek driver yang dibuat menggunakan
Microsoft Visual Studio 2013 dan Windows Driver Kit (WDK) 8.1 menjadi proyek driver
yang dibangun di Microsoft Visual Studio 2015 dengan Windows Driver Kit (WDK) 10.
Visual Studio 2015 memiliki peringatan dan kesalahan kompiler baru. Bahkan jika proyek
driver Anda dibangun tanpa kesalahan pada Visual Studio 2013, Anda mungkin melihat
kesalahan saat anda membangunnya di Visual Studio tahun 2015.
Gunakan langkah-langkah ini untuk mengonversi proyek dalam solusi driver.
1. Pada Visual Studio 2015, buka solusi driver lama.
Visual Studio secara otomatis menjalankan ProjectUpgradeTool untuk mengonversi

proyek dalam solusi ini. Anda juga dapat menjalankan alat ini dari baris perintah.
Secara default, saat Anda menginstal WDK, ProjectUpgradeTool.exe penginstalan
di Windows Kits\10\bin\x86.
Visual Studio membuka dialog Tinjau Tindakan Solusi dengan judul Upgrade VC
++ Compiler dan Libraries. Pilih OK dan Visual Studio mencoba untuk
meningkatkan semua proyek dalam solusi.
Jika Anda melihat dialog Terdeteksi Modifikasi File , pilih Muat Ulang Semua.
2. Di panel Penjelajah Solusi, pilih dan tahan (atau klik kanan) nama proyek driver dan
pilih Properti. Pilih tombol Configuration Manager. Dalam daftar Konfigurasi
solusi aktif , pilih <Baru...>. Ketik nama dan salin pengaturan dari konteks proyek
Windows 8.1. PilihOK.
Biasanya, solusi yang dikonversi berisi dua profil konfigurasi, satu untuk debug
(pengujian) dan satu untuk rilis. Untuk membuat lingkungan yang serupa dengan
WDK 10, cukup pilih <New...> dua kali. Untuk membuat profil debug, salin dari
profil Win 8.1 Debug . Untuk membuat profil rilis, salin dari profil Rilis Win 8.1 .
3. Dalam versi WDK sebelum WDK 10, solusi driver Anda selalu membutuhkan proyek
paket. Di WDK 10, Anda hanya memerlukan proyek paket jika Anda menyertakan
beberapa driver dalam paket driver. Gunakan panduan berikut:
Jika Anda hanya memiliki satu driver dalam solusi dan proyek paket ada,
hapus.
Jika Anda memiliki lebih dari satu driver dalam solusi, pastikan solusi Anda
berisi proyek paket. Kemudian, untuk setiap proyek driver dalam solusi, buka
properti proyek dan navigasikan ke Configuration Properties > Driver
Pengaturan. Atur BuildPackage ke No. Jika Anda membangun dari baris
perintah, atur /p:SupportsPackaging=false.
4. Sekali lagi di properti proyek driver, pilih Properti. Navigasikan ke Driver Properti
> Konfigurasi Pengaturan > Versi OS Target Umum>. Pilih Windows 10.
Verifikasi bahwa Platform Target diatur ke Desktop, dan buat solusinya. Perbaiki
kesalahan yang terjadi.
5. Setelah solusi berhasil dibangun, ubah Target Platform ke Universal.
Bangun solusinya lagi. Pada titik ini, satu-satunya kesalahan berasal dari alat
ApiValidator, yang memeriksa apakah driver memanggil fungsi non-universal.
Ganti panggilan apa pun ke DDI non-universal dengan panggilan ke DDI universal.
Untuk informasi selengkapnya tentang ApiValidator, lihat Memvalidasi driver

Windows Universal.
Untuk mempelajari cara menentukan platform target untuk DDI tertentu, lihat
Platform target di halaman referensi driver.
Model konvergensi driver untuk
Windows 10
Untuk membuat perangkat Anda berfungsi pada rilis Windows dan Windows Phone
sebelum Windows 10, Anda mungkin perlu menulis dua driver terpisah, misalnya satu
untuk Windows 8.1 dan satu untuk Windows Phone 8.1. Dalam Windows 10, dalam
banyak kasus, Anda dapat menulis satu driver yang akan berjalan pada versi Windows
10. Topik ini menjelaskan rencana konvergensi untuk antarmuka driver perangkat di
Windows 10 dan memberikan detail ketika ada perbedaan khusus versi. Ini menjawab
pertanyaan-pertanyaan ini:
Untuk driver lama, apakah driver Windows 8.1 akan berfungsi di Windows 10 untuk
edisi desktop (Home, Pro, and Enterprise) dan/atau Windows 10 Mobile?
Untuk driver baru, dapatkah saya membuat satu driver dengan kit Windows 10
yang akan berfungsi Windows 10 untuk edisi desktop dan Windows 10 Mobile?
Teknologi Windows 8.1 driver binary Perubahan untuk Windows

berjalan di Windows 10? 10
Audio Ya Mulai Windows 10, Anda

dapat menulis driver audio
Kernel-Mode Driver
Framework (KMDF) yang
memanggil antarmuka KMDF
untuk PnP, manajemen daya,
dan manajemen idle. Untuk
penanganan I/O, driver audio
KMDF tidak boleh
menggunakan fungsi antrean
I/O di WDF, melainkan harus
menggunakan antarmuka
COM yang ada yang
disediakan oleh PortClass.
Namun, driver Anda dapat
menggunakan dukungan
kerangka kerja untuk timer,
interupsi, DMA, dan target I /O
jarak jauh. Driver audio KMDF
bekerja pada kedua Windows
10 untuk edisi desktop dan
Windows 10 Mobile.
Driver Windows 8.1 yang ada

yang menautkan ke PortClass
terus mengerjakan Windows
10 untuk edisi desktop dan
Windows 10 Mobile.
Biometrik Ya Windows Biometric Framework

(WBF) tersedia di kedua
Windows 10 untuk edisi
desktop dan Windows 10
Mobile.
Jika Anda mengembangkan

driver biometrik baru untuk
Windows 10 Mobile, Anda
dapat menggunakan driver
WBF Windows 8.1 sebagai titik
awal.
Bluetooth Ya Dalam Windows 10, antarmuka

pengemudi transportasi
Bluetooth untuk semua
perangkat disatukan dan
menggunakan model driver
Bluetooth universal. Anda
dapat menulis satu driver yang
berjalan di semua platform
perangkat Windows.
Luas permukaan driver audio

Bluetooth menyimpang
selama Windows 10 dan
memungkinkan dua opsi
berikut:
Anda dapat menulis

driver audio universal
baru yang berfungsi
untuk perangkat
desktop dan seluler.
Driver audio Bluetooth
8.1 Windows Phone
yang ada akan berjalan
pada Windows 10
Mobile.
Kamera Ya Fitur yang sebelumnya

tersedia di Windows Phone 8.1
(seperti fokus otomatis dan
HFR) akan tersedia di kedua
Mobile. Driver kamera lama
dari Windows 8.1 akan
memerlukan modifikasi untuk
memanfaatkan fitur-fitur ini.
Paket Ya Windows 10 terus mendukung

MBIM 1.0 (Mobile Broadband
Interface Model) untuk kartu
data di PC.
Manajemen koneksi seluler

dan wi-fi yang setara
menggunakan tumpukan
konvergen. Operator seluler
dapat menggunakan
konfigurasi Open Mobile
Alliance Manajemen Perangkat
(OMA DM) dari pengaturan
seluler di kedua Windows 10
untuk edisi desktop dan
Windows 10 Mobile. Selain itu,
OEM akan memiliki akses ke
provisi Multivarian di kedua
Mobile, sementara Mobile
Broadband Account
Experience (MBAE) masih akan
tersedia dalam Windows 10
untuk edisi desktop.
Tampilan Ya Sudah menyatu. Windows

Display Driver Model (WDDM)
1.3 berjalan pada Windows 8.1
dan Windows Phone 8.1.
WDDM 1.3 terus didukung
dalam Windows 10. WDDM 2.0
adalah yang baru untuk
Windows 10. Untuk
menggunakan runtime dan
fitur Direct3D (D3D) 12, harus
memiliki driver WDDM 2.0.
Lokasi Ya Adaptor Global Navigation

Satellite System (GNSS) baru
DDI untuk Windows 10.
Windows 8.1 akan didukung

menggunakan PE warisan
Global Navigation Satellite
System (GNSS).
NFC Ya Windows 10 DDI baru untuk

kartu Pintar, Radio Manager,
SE.
Driver NFC Windows 8.1 terus

bekerja, tetapi tidak dapat
memanfaatkan fitur-fitur baru.
Sensor Ya Pengemudi baru untuk

Windows 10 dapat menulis
User-Mode Driver Framework
(UMDF) 2. x driver yang
menggunakan tumpukan
sensor umum (mirip dengan
model Windows Phone 8.1)
dan paket driver yang sama
bekerja pada Windows 10
untuk edisi desktop dan
Windows 10 Mobile.
Ekstensi kelas sensor Windows

8.1 menggunakan UMDF 1.
Windows Phone 8.1 sensor
class extension menggunakan
UMDF 2. Untuk Windows 10,
ekstensi kelas sensor baru
menggunakan UMDF 2 seperti
Windows Phone 8.1. Untuk
membangun menggunakan kit
Windows 10, harus
menggunakan yang terakhir.
Driver biner dari Windows 8.1
masih berjalan pada Windows
10. Driver kelas HID masih
masuk kotak masuk untuk
Windows 10, tidak ada driver
yang disediakan vendor dan
tidak ada perubahan firmware
yang diperlukan jika Anda
menggunakan jenis HID yang
sudah ditentukan dari
Windows 8.1.
Touch/Precision Touchpad Ya Dalam Windows 10, driver HID

(PTP) dan touch miniport akan
didukung. Vendor dapat
memperbarui driver HID lama
atau menerapkan driver
miniport sentuh baru.
Untuk Windows 10 Mobile,

pembatasan bus dihapus, tidak
lagi terbatas pada USB, I2C.
Pengemudi kelas saat ini tetap
di tempat, bus lain
memerlukan sopir miniport
HID. Dapat menyediakan
driver filter untuk mendukung
gerakan khusus.
USB Ya Windows 8.1 menyediakan

tumpukan pengontrol host.
Windows 10 menambahkan
tumpukan fungsi yang
memungkinkan perangkat
dengan pengontrol host (PC /
tablet / telepon) berfungsi
sebagai perangkat periferal.
Kerangka Kerja Windows Ya Windows 10 kapal dengan

Driver (WDF) KMDF 1.15, UMDF 2.15, UMDF
1.11, dan versi kerangka kerja
sebelumnya. Windows 10
Mobile juga dikirimkan
dengan KMDF 1.15, UMDF
2.15, dan versi kerangka kerja
sebelumnya. Perhatikan bahwa
UMDF versi 1 tidak tersedia
dalam Windows 10 Mobile.
Hanya KMDF dan UMDF versi
2 yang dapat digunakan untuk
menulis Windows driver.
WLAN Ya WDI (WLAN Device Driver

Interface) adalah model driver
WLAN universal baru untuk
Windows 10. Produsen
perangkat WLAN dapat
menulis driver miniport WDI
tunggal yang berjalan di
semua platform perangkat,
dan membutuhkan kode lebih
sedikit daripada model driver
WLAN asli sebelumnya. Semua
fitur WLAN baru yang
diperkenalkan pada Windows
10 memerlukan driver berbasis
WDI.
Driver WLAN asli yang

disediakan vendor terus
bekerja di Windows 10, tetapi
fungsionalitas terbatas pada
versi Windows yang mereka
kembangkan.
Platform target pada halaman referensi
driver
Di blok Persyaratan di bagian bawah halaman referensi driver Microsoft, Anda akan
melihat entri yang disebut Platform Target. Baris ini mencantumkan edisi Windows
tempat halaman diterapkan.
Berikut adalah contoh entri seperti itu:
Nilai yang ditentukan dalam peta Platform Target ke nilai yang dapat Anda gunakan di
Visual Studio, di properti Platform Target di bawah Properti Konfigurasi-Driver>
Pengaturan-Umum>. Windows Driver dapat menggunakan DDI apa pun yang
menentukan Universal sebagai Platform Target.
Berikut adalah nilai yang mungkin Anda lihat untuk Platform Target, dan apa artinya:
Jangka Deskripsi
Waktu
Universal Biner driver dalam Driver Windows dapat memanggil antarmuka driver perangkat
(DDI) ini. Untuk informasi selengkapnya, lihat Memulai driver Windows.
Desktop Biner driver untuk Windows 10 untuk edisi desktop atau Windows Server 2016 dapat
memanggil DDI ini.
Driver Windows berjalan pada edisi Windows berbasis Universal Windows Platform
(UWP) berikut:
Windows 11
Windows Server 2022
Windows Server 2019
Windows 10 untuk edisi desktop (Beranda, Pro, dan Perusahaan)
Windows 10 dalam Mode-S
Windows 10 IoT Core
Server Windows 2016
Menganalisis Driver Menggunakan Alat
Analisis dan Verifikasi Kode
Alat analisis dan verifikasi kode dapat membantu meningkatkan stabilitas dan keandalan
driver Anda dengan menganalisis kode sumber secara sistematis. Alat analisis dan
verifikasi kode dapat mendeteksi kesalahan yang terlewatkan oleh kompiler dan dengan
pengujian runtime konvensional. Selain itu mereka dapat menentukan apakah driver
berinteraksi dengan benar dengan kernel sistem operasi Windows. Menggunakan
Microsoft Visual Studio dan Windows Driver Kit (WDK), Anda dapat mengonfigurasi
analisis kode dan alat verifikasi untuk dijalankan sebagai bagian dari proses pembuatan,
atau Anda dapat menjadwalkan alat untuk menganalisis driver Anda pada waktu yang
telah ditentukan.
Alat Analisis Kode C/C++ untuk Driver

Windows
Rilis WDK yang Windows 8 memberikan peningkatan pada alat Analisis Kode C / C ++
yang disertakan dengan Visual Studio. Secara khusus, WDK menyediakan modul driver
khusus yang dirancang untuk mendeteksi kesalahan dalam kode driver mode kernel.
Modul driver ini diintegrasikan ke dalam alat Analisis Kode C /C ++.
Kapan harus menggunakan: Anda dapat menjalankan alat Analisis Kode C / C ++ untuk
driver sangat awal dalam siklus pengembangan, segera setelah kode dikompilasi
dengan benar.
Untuk informasi tentang alat Analisis Kode di Visual Studio, lihat:
Menganalisis Kualitas Aplikasi menggunakan Analisis Kode

Analisis Kode untuk Driver
Cara menjalankan Analisis Kode untuk driver
Menggunakan Anotasi SAL untuk Mengurangi Cacat Kode C /C++
Anotasi SAL 2.0 untuk Pengemudi Windows
Nota Dalam versi WDK sebelumnya, modul khusus driver untuk analisis kode adalah
bagian dari alat mandiri yang disebut PREfast for Drivers (PFD). PREfast for Drivers juga
diintegrasikan ke dalam lingkungan WDK Build, sebagai bagian dari Microsoft
Automated Code Review (OACR).
Verifikator Driver Statis
Static Driver Verifier (SDV) adalah alat verifikasi statis yang secara sistematis
menganalisis kode sumber driver mode kernel Windows. SDV menentukan apakah
driver berinteraksi dengan benar dengan kernel sistem operasi Windows. SDV dapat
diluncurkan dari menu Driver di Visual Studio atau dari jendela Command Prompt
Visual Studio.
Kapan harus menggunakan: Jalankan Static Driver Verifier di awal siklus pengembangan
pada driver yang mengkompilasi dengan benar. Jalankan Static Driver Verifier sebelum
Anda memulai siklus pengujian.
Untuk informasi tentang Static Driver Verifier, lihat:
Gambaran Umum: Verifikasi Driver Statis

Cara: Menggunakan Static Driver Verifier untuk menemukan cacat pada driver
Mempersiapkan Komputer untuk
Penyebaran Driver Manual
Anda dapat menyebarkan driver secara otomatis atau manual. Dalam kedua kasus, Anda
perlu menyiapkan komputer target terlebih dahulu. Di sini kami menjelaskan cara
menyiapkan komputer target jika Anda memilih untuk menyebarkan driver Anda secara
manual.
Biasanya komputer tempat Anda menginstal dan menguji driver terpisah dari komputer
tempat Anda mengembangkan dan membangun paket driver. Komputer tempat Anda
membangun driver disebut komputer host, dan komputer tempat Anda menginstal dan
menguji driver disebut komputer target atau komputer uji. Proses memindahkan paket
driver ke komputer target dan menginstal driver itu disebut menyebarkan driver.
1. Di komputer target, buka jendela Command Prompt sebagai Administrator.

Masukkan bcdedit /set TESTSIGNING ON. Reboot komputer target.
2. Salin alat DevCon ke folder di komputer target (misalnya, c:\Tools). Alat DevCon
termasuk dalam Windows Driver Kit (WDK). Anda dapat menemukannya di bawah
direktori Alat (misalnya, C:\Program Files (x86)\Windows
Kits\10\Tools\x64\devcon.exe).
3. Buat atau dapatkan file sertifikat (.cer) yang dapat Anda instal di komputer target.
Misalnya, saat Anda membuat salah satu driver sampel WDK, proses pembuatan
membuat file sertifikat (.cer). Lokasi file sertifikat bervariasi tergantung pada apa
yang telah Anda tentukan untuk konfigurasi dan platform. Misalnya, jika
konfigurasi Anda adalah Win7 Debug dan platform Anda adalah x64, maka file
sertifikat ada di folder solusi Anda di bawah C ++\x64\Win7Debug.
4. Salin file sertifikat ke folder di komputer target Anda (misalnya c:\Certificates).
5. Pada komputer target, pilih dan tahan (atau klik kanan) file sertifikat, dan pilih
Instal. Bekerja melalui wizard instalasi.
Saat Anda membuat salah satu sampel driver WDK, proses pembuatan membuat
sertifikat penandatanganan pengujian. Anda perlu menginstal sertifikat
penandatanganan uji coba hanya sekali. Jika Anda telah menginstal sertifikat dari
sampel driver WDK, Anda dapat menginstal sampel driver lain tanpa menginstal
sertifikat lagi.
Apa yang terjadi ketika Anda
menyediakan komputer (WDK 8.1)
Menggunakan Microsoft Visual Studio untuk mengkonfigurasi dan mengatur

penyebaran driver dan pengujian driver disebut penyediaan komputer target atau
penyediaan komputer uji. Untuk informasi tentang provisi, lihat Menyediakan komputer
untuk penyebaran dan pengujian driver (WDK 8.1). Di sini kami menunjukkan apa yang
terjadi ketika Anda menggunakan versi 8.1 dari Windows Driver Kit (WDK) untuk
menyediakan komputer target.
Saat Anda menyediakan komputer (WDK 8.1)

Penyediaan komputer melakukan tugas-tugas berikut:
Menyalin berkas penginstalan ke %SystemDrive%\DriverTest

Membuat pengguna bernama WDKRemoteUser dan beralih ke pengguna tersebut
Menginstal .NET 4.0 jika belum diinstal
Menginstal Microsoft Visual C++ Redistributable
Menginstal Test Authoring and Execution Framework (TAEF) (WDK Client)
Menginstal debugger
Menginstal Windows Device Testing Framework (WDTF)
Menonaktifkan AutoReboot
Mengaktifkan dump crash memori kernel
Menonaktifkan Penghemat Layar
Menonaktifkan kebijakan kunci workstation
Menonaktifkan ForceGuest
Mengatur kebijakan daya ke konfigurasi daya tinggi, yang mencegah sistem
memasuki Mode Siaga atau Hibernasi saat idle
Mengaktifkan timer RTC Wake
Mengaktifkan dan mengonfigurasi debugging kernel
Memungkinkan penandatanganan pengujian driver
Me-reboot komputer target jika perlu
Membuat titik pemulihan sistem
Menghapus provisi dari komputer target

Setelah Anda menyediakan komputer target, Anda tidak dapat sepenuhnya menghapus
provisi. Namun, Anda dapat menghapus sebagian besar provisi dari komputer target
dengan menggunakan Visual Studio di komputer host. Berikut langkah-langkahnya.
1. Di komputer host, di Visual Studio, pada menu Driver, pilih Test > Configure
Computers.
2. Pilih nama komputer target, dan pilih Hapus komputer.
3. Pilih Hapus provisi dan hapus komputer. Pilih Selanjutnya.
4. Setelah proses penghapusan selesai, pilih Selesai.
5. Hapus instalan WDK Test Target Setup dari komputer target.
Saat Anda menghapus provisi (WDK 8.1)

Saat Anda menghapus provisi dari komputer target, item ini akan dihapus:
Kerangka Kerja Otomatisasi Uji

Debugger
Kerangka Pengujian Driver Windows
%SystemDrive%\DriverTest folder dan konten
Akun WDKRemoteUser
Kebijakan kunci workstation
Menghapus provisi tidak mengubah item ini:
Visual C ++ Dapat Didistribusikan Kembali

Pengaturan AutoReboot
Pengaturan dump crash memori kernel
Pengaturan penghemat layar
Pengaturan ForceGuest
Kebijakan daya
Pengaturan timer RTC Wake
Setelan debugging kernel
Pengaturan penandatanganan uji
Apa yang terjadi ketika Anda
menyediakan komputer (WDK 8.0)
Menggunakan Microsoft Visual Studio untuk mengkonfigurasi dan mengatur

penyebaran driver dan pengujian driver disebut penyediaan komputer target atau
penyediaan komputer uji. Untuk informasi tentang penyediaan dengan Windows Driver
Kit (WDK) 8 , lihat Penyediaan komputer untuk penyebaran dan pengujian driver (WDK
8). Di sini kami menunjukkan apa yang terjadi ketika Anda menggunakan versi 8.0 dari
Windows Driver Kit (WDK) untuk menyediakan komputer target.
Nota WDK 8 bukanlah versi terbaru dari WDK. Kami menyarankan Anda mendapatkan
versi WDK saat ini dan menyediakan komputer target Anda sesuai dengan instruksi
provisi di sini.
Saat Anda menyediakan komputer (WDK 8.0)

Penyediaan komputer melakukan tugas-tugas berikut:
Menyalin berkas penginstalan ke %SystemDrive%\DriverTest

Membuat pengguna bernama WDKRemoteUser dan beralih ke pengguna tersebut
Menginstal .NET 4.0 jika belum diinstal
Menginstal Microsoft Visual C++ Redistributable
Menginstal Test Authoring and Execution Framework (TAEF) (WDK Client)
Menginstal debugger
Menginstal Windows Device Testing Framework (WDTF)
Menonaktifkan AutoReboot
Mengaktifkan dump crash memori kernel
Menonaktifkan Penghemat Layar
Menonaktifkan kebijakan kunci workstation
Menonaktifkan ForceGuest
Mengatur kebijakan daya ke konfigurasi daya tinggi, yang mencegah sistem
memasuki Mode Siaga atau Hibernasi saat idle
Mengaktifkan timer RTC Wake
Mengaktifkan dan mengonfigurasi debugging kernel
Memungkinkan penandatanganan pengujian driver
Me-reboot komputer target jika perlu
Membuat titik pemulihan sistem
Menghapus provisi dari komputer target
Setelah Anda menyediakan komputer target, Anda tidak dapat sepenuhnya menghapus
provisi. Namun, Anda dapat menghapus sebagian besar provisi dari komputer target
dengan menggunakan Visual Studio di komputer host. Berikut langkah-langkahnya.
1. Di komputer host, di Visual Studio, pada menu Driver, pilih Test > Configure
Computers.
2. Pilih nama komputer target, dan pilih Hapus komputer.
3. Pilih Hapus provisi dan hapus komputer. Pilih Selanjutnya.
4. Setelah proses penghapusan selesai, pilih Selesai.
Saat Anda menghapus provisi (WDK 8.0)

Saat Anda menghapus provisi dari komputer target, item ini akan dihapus:
Visual C ++ Dapat Didistribusikan Kembali

Kerangka Kerja Otomatisasi Uji
Debugger
%SystemDrive%\DriverTest folder dan konten
Akun WDKRemoteUser
Menghapus provisi tidak mengubah item ini:
Pengaturan AutoReboot
Pengaturan dump crash memori kernel
Pengaturan penghemat layar
Kebijakan kunci workstation
Pengaturan ForceGuest
Kebijakan daya
Pengaturan timer RTC Wake
Setelan debugging kernel
Pengaturan penandatanganan uji
Konfigurasi Pemecahan Masalah
Penyebaran Driver, Pengujian, dan
Debugging
Penyediaan komputer target dijelaskan dalam Penyediaan komputer untuk penyebaran

dan pengujian driver (WDK 8.1). Di sini kami memberikan beberapa tips pemecahan
masalah untuk proses penyediaan.
Tips umum
Konfigurasi perintah menu Komputer tidak aktif
Provisi gagal
Provisi gagal
Jalur jaringan tidak ditemukan
Nama jaringan tidak dapat ditemukan
Tidak dapat mengakses mesin jarak jauh
Debugger tidak akan terhubung atau masuk

Koneksi jaringan Debugger
Koneksi Debugger 1394
Koneksi serial Debugger
Konfigurasi perintah menu Komputer tidak

aktif
Saat pertama kali memulai Microsoft Visual Studio, perintah Test > Configure
Computers pada menu Driver mungkin tidak aktif (berwarna abu-abu). Jika Anda
menunggu sekitar 20 detik, lalu pilih menu Driver lagi, perintah Test > Configure
Computers akan tersedia.
Provisi gagal: Tips umum

Jika provisi gagal, baca urutan pesan di jendela Konfigurasi Komputer. Biasanya, jendela
ini juga menampilkan lokasi log konfigurasi. Lihat log dan catat lokasinya sehingga Anda
dapat merujuknya nanti.
Jalur ke log mungkin berisi folder tersembunyi. Misalnya, di jalur berikut, AppData
adalah folder tersembunyi.
C:\Users\currentUser\AppData\Roaming\Microsoft\DriverTest\Install
File log akan memiliki nama yang mirip dengan ini:
Konfigurasi Komputer Uji Driver 20121115130459167.log
Provisi gagal: Jalur jaringan tidak ditemukan

Saat Anda mulai menyediakan komputer target, Anda mungkin melihat pesan yang
mengatakan Jalur jaringan tidak ditemukan.
Di komputer target, pastikan Anda telah mengaktifkan Network Discovery dan Anda
telah mengaktifkan Berbagi File dan Printer untuk profil jaringan yang sesuai. Misalnya,
jika komputer host dan target digabungkan ke domain jaringan, Anda harus
mengaktifkan penemuan jaringan dan berbagi file dan printer untuk profil jaringan
Domain . Untuk informasi selengkapnya, lihat Menyediakan komputer untuk
penyebaran dan pengujian driver (WDK 8.1).
Pastikan Anda dapat melakukan ping ke komputer target dari komputer host. Di
komputer host, buka jendela Command Prompt, dan masukkan
pingtargetComputerName, di mana targetComputerName adalah nama komputer target.
Nota Anda mungkin melihat beberapa pesan sebelum melihat pesan Jalur jaringan
tidak ditemukan. Beberapa pesan tersebut mungkin membuat Anda berpikir bahwa
jalur jaringan ditemukan dan langkah pertama penyediaan berhasil. Bahkan, jalur
jaringan tidak ditemukan dan tidak ada bagian dari penyediaan yang berhasil. Misalnya,
Anda mungkin melihat ini:
C++
Connecting to computer "MyComputer"
Installing driver test automation service
Getting computer system information
Copying driver test automation files
The network path was not found.
Provisi gagal: Nama jaringan tidak dapat

ditemukan
mengatakan Nama jaringan tidak dapat ditemukan. Periksa kembali nama komputer
target. Jika nama komputer yang Anda masukkan awalnya salah, mulai panduan provisi
lagi (Driver > Test > Configure Computers). Pilih nama komputer yang salah, dan pilih
Berikutnya. Untuk Nama komputer, masukkan nama yang benar dari komputer target,
dan selesaikan wizard.
Nota Anda mungkin melihat beberapa pesan sebelum melihat pesan Nama jaringan
tidak dapat ditemukan. Beberapa pesan tersebut mungkin membuat Anda berpikir
bahwa nama komputer ditemukan dan langkah pertama penyediaan berhasil. Faktanya,
nama komputer tidak ditemukan, dan tidak ada bagian dari penyediaan yang berhasil.
Misalnya, Anda mungkin melihat ini:
C++
Connecting to computer "NonExistentComputer"
Getting computer system information
Copying driver test automation files
The network name cannot be found.
Nota Pesan yang ditampilkan saat Anda memasukkan nama komputer target yang salah
dapat bervariasi. Misalnya, Anda mungkin melihat pesan tentang mengaktifkan
penemuan jaringan.
C++
Connecting to computer "NonExistentComputer"
Could not access remote machine "NonExistentComputer" over the network.
Error:53. Automatic configuration of machines over the network requires
that network discovery and file and print sharing be enabled on the
target machine.
Atau Anda mungkin diminta untuk memasukkan kredensial.
C++
Enter your password to connect to: NonExistentComputer
Provisi gagal: Tidak dapat mengakses mesin

jarak jauh
mengatakan Tidak dapat mengakses "computerName" mesin jarak jauh melalui
jaringan. Pesan ini dapat ditampilkan karena beberapa alasan. Verifikasi bahwa
komputer host dan target Anda sama-sama bergabung ke domain yang sama atau grup
kerja yang sama. Untuk informasi selengkapnya, lihat Menyediakan komputer untuk
penyebaran dan pengujian driver (WDK 8.1). Verifikasi bahwa Anda memasukkan nama
yang benar untuk komputer target. Verifikasi bahwa Anda telah mengaktifkan
penemuan jaringan dan berbagi file dan cetak di komputer target.
Breakpoint debugger tidak dipicu untuk driver

mode kernel
1. Sebarkan driver dengan breakpoint dinonaktifkan.
2. Masuk secara manual ke debugger mode kernel.
3. Tetapkan pengecualian pada beban modul:
C++
sxe ld <DriverName>
4. Aktifkan breakpoint dan lanjutkan eksekusi.

5. Pada komputer target, nonaktifkan simpul perangkat dan kemudian aktifkan
kembali.
Debugger tidak akan terhubung atau masuk:

Koneksi jaringan
Verifikasi bahwa aplikasi debugging Anda diizinkan melalui firewall untuk semua jenis
jaringan.
Periksa dengan administrator jaringan tentang port yang memungkinkan debugging

jaringan.
Jika komputer target memiliki lebih dari satu adaptor jaringan, Anda harus menentukan
parameter bus adaptor jaringan yang ingin Anda gunakan untuk debugging.
Untuk informasi selengkapnya, lihat Pemecahan masalah Tips untuk Debugging melalui
Kabel Jaringan
koneksi 1394
Jika komputer target memiliki lebih dari satu pengontrol 1394, Anda harus menentukan
parameter bus pengontrol 1394 yang ingin Anda gunakan untuk debugging. Untuk
informasi selengkapnya, lihat Pemecahan masalah Tips untuk Debugging melalui Kabel
1394.

Koneksi serial
Periksa nomor port COM pada host dan komputer target. Verifikasi bahwa Anda telah
mengonfigurasi kecepatan baud yang sama untuk debugging pada komputer host dan
target. Untuk informasi selengkapnya, lihat Pemecahan masalah Tips untuk Debugging
melalui Kabel Serial
Membuat Paket Driver
Proyek dan paket driver

Proyek driver adalah proyek Microsoft Visual Studio yang menghasilkan biner driver
(seperti file .sys), dan berpotensi file INF driver.
Paket driver adalah kumpulan file yang digunakan selama penginstalan perangkat. Paket
driver mencakup file INF, serta file dan biner yang direferensikan oleh INF tersebut.
Visual Studio menggunakan paket driver untuk menyebarkan dan men-debug driver
Anda secara otomatis ke target jarak jauh.
Paket driver adalah proyek terpisah yang mengumpulkan output dari satu atau
beberapa proyek, seperti proyek driver. Proyek paket driver, ketika dibangun, kemudian
menghasilkan paket driver yang Visual Studio gunakan untuk menyebarkan driver.
Catatan
Jika Anda menggunakan templat driver untuk membuat solusi driver, maka templat
harus secara otomatis membuat solusi yang berisi dua proyek. Satu untuk driver, dan
satu lagi untuk paket driver.
Membuat paket driver secara manual

Jika solusi Anda tidak memiliki paket driver, Anda dapat membuatnya secara manual di
Visual Studio dengan memilih Project Baru > dari menu File. Untuk contoh cara
membuat paket driver, lihat Menulis Driver Pertama Anda.
Untuk membuat paket driver baru secara manual untuk solusi yang sudah ada yang
belum memilikinya, gunakan templat "Paket Penginstalan Driver". Pilih File-Baru-
Project>>. Kemudian pilih Windows Paket > Driver > "Paket Penginstalan Driver" dari
dialog. Kemudian di menu drop-down Solusi , pilih Tambahkan ke solusi dan pilih Ok.
Mengubah paket driver yang ada

Jika solusi Anda sudah berisi paket driver, Anda dapat memodifikasinya untuk
mereferensikan proyek lain dalam solusi.
Di panel Penjelajah Solusi, buka proyek paket driver, pilih dan tahan (atau klik kanan)
Referensi, pilih Tambahkan Referensi... dan pilih proyek yang akan dirujuk.
Untuk menghapus referensi ke proyek yang sudah ada, pilih dan tahan (atau klik kanan)
proyek yang sudah ada yang tidak ingin Anda referensikan lagi dan pilih Hapus.
Beberapa driver dalam solusi
Anda dapat menambahkan beberapa driver dan paketnya ke solusi Anda. Mirip dengan
"Memodifikasi paket driver yang ada" Anda dapat membuat solusi driver baru, atau
menambahkan referensi ke yang sudah ada. Jika solusi Anda sudah berisi paket driver,
Anda dapat memodifikasinya untuk mereferensikan proyek driver tambahan dalam
solusi.
Di panel Penjelajah Solusi, buka proyek paket driver, pilih dan tahan (atau klik kanan)
Referensi, pilih Tambahkan Referensi... dan pilih proyek yang akan dirujuk.
Untuk menghapus referensi ke proyek yang sudah ada, pilih dan tahan (atau klik kanan)
proyek yang sudah ada yang tidak ingin Anda referensikan lagi dan pilih Hapus.
Lihat sampel "Toaster Sample Driver" untuk contoh satu solusi yang berisi beberapa
driver:
Topik terkait
Membuat Paket Metadata Perangkat
Anda dapat membuat Paket Metadata Perangkat untuk perangkat Anda secara langsung
di Visual Studio. Panduan Penulisan Metadata Perangkat, yang terletak di menu Driver,
memungkinkan Anda untuk menulis informasi spesifik yang muncul untuk pengguna
akhir di Windows, termasuk ikon dan nama untuk perangkat Anda. Ini juga
memungkinkan Anda untuk mengaitkan aplikasi perangkat UWP ke perangkat Anda,
yang diinstal secara otomatis ketika pengguna pertama kali menghubungkan perangkat.
Untuk informasi selengkapnya tentang cara menggunakan Panduan Penulisan Metadata

Perangkat, silakan lihat Panduan Penulisan Metadata Perangkat.
Semua driver yang berjalan pada versi 64-bit Windows harus ditandatangani sebelum
Windows akan memuatnya. Namun, penandatanganan driver tidak diperlukan pada
versi Windows 32-bit.
Untuk menandatangani driver, sertifikat diperlukan. Anda dapat membuat sertifikat

Anda sendiri untuk menandatangani driver Anda selama pengembangan dan pengujian.
Namun, untuk rilis publik Anda harus menandatangani driver Anda dengan sertifikat
yang dikeluarkan oleh otoritas root tepercaya.
NotaProyek paket driver dapat mengemas output dari proyek lain. Jika Anda
membangun proyek paket driver, Microsoft Visual Studio akan membangun proyek lain
yang memiliki dependensi. Proyek paket driver memiliki properti penandatanganan
driver sendiri yang terpisah dari proyek dependen lainnya, dan properti
penandatanganan driver hanya berlaku untuk katalog (jika ada) yang dihasilkan oleh
proyek paket driver. Artinya, proyek paket driver tidak akan secara otomatis
menambahkan tanda tangan tertanam ke binari driver yang dihasilkan oleh proyek lain,
karena sertifikat yang berbeda dapat digunakan untuk menandatangani proyek driver
lainnya, misalnya, sertifikat uji, dan hasilnya dalam kasus seperti itu adalah paket driver
di mana binari secara tidak sengaja ditandatangani dengan satu sertifikat, sedangkan
katalog paket ditandatangani dengan sertifikat yang berbeda. Hal ini dapat
mengakibatkan penurunan kinerja. Misalnya, jika tanda tangan tertanam biner driver
mulai boot tidak valid, Windows tidak dapat menggunakan sertifikat yang
ditandatangani untuk memvalidasi biner. Sebaliknya, Windows harus memvalidasi biner
terhadap tanda tangan katalog, yang akan meningkatkan waktu boot.
Bagian ini menjelaskan cara menggunakan Visual Studio untuk menandatangani paket
driver.
Menandatangani Driver Selama Pengembangan dan Pengujian

Menandatangani Driver untuk Rilis Publik
Menandatangani Driver Selama
Pengembangan dan Pengujian
Sebelum menginstal driver pada komputer yang menjalankan versi 64-bit Windows,
Anda harus menandatangani paket driver. Untuk tujuan pengujian, Anda dapat menguji
tanda tangan paket driver, yang merupakan bentuk penandatanganan yang lebih santai
daripada menandatangani untuk rilis publik.
Di Microsoft Visual Studio, penandatanganan pengujian diaktifkan secara default.

Misalkan Anda telah membuat solusi driver KMDF seperti yang dijelaskan dalam Menulis
driver KMDF berdasarkan templat. Saat Anda membangun solusi, Anda dapat melihat di
jendela Output bahwa paket driver telah ditandatangani pengujian.
Mengaktifkan penandatanganan pengujian

secara manual
Untuk mengaktifkan penandatanganan pengujian secara manual, ikuti langkah-langkah
ini.
1. Di Visual Studio, buka solusi yang memiliki proyek paket driver. Pilih dan tahan
(atau klik kanan) proyek paket driver, dan pilih Properti.
2. Di halaman properti untuk paket, navigasikan ke Properti > Konfigurasi

Penandatanganan > Driver Umum. Di daftar drop-down Mode Masuk , pilih
Tanda Uji.
3. Di halaman properti untuk paket, navigasikan ke Properti > Konfigurasi Umum

Inf2Cat>. Di daftar drop-down Jalankan Inf2Cat , pilih Ya.
Menampilkan paket driver yang ditandatangani

Setelah Anda membangun solusi, navigasikan di File Explorer ke folder yang berisi paket
driver Anda. Salah satu file dalam paket adalah file katalog. File katalog berisi tanda
tangan digital untuk paket. Untuk contoh menampilkan file dalam paket yang
ditandatangani, lihat Menulis driver KMDF berdasarkan templat.
Berbagi sertifikat penandatanganan

Saat Anda menguji menandatangani paket driver, Visual Studio membuat sertifikat
penandatanganan (file PFX) dan mengimpornya ke penyimpanan sertifikat di komputer
host Anda. Saat Anda menyebarkan paket driver yang ditandatangani pengujian ke
komputer uji, Visual Studio menyalin sertifikat verifikasi (file CER) ke komputer
pengujian. Jika Anda ingin berbagi sertifikat dengan pengembang yang membangun
driver di komputer host lain, Anda harus berbagi sertifikat penandatanganan, bukan
sertifikat verifikasi.
Untuk berbagi sertifikat penandatanganan, ikuti langkah-langkah ini.
Di Visual Studio, di jendela Penjelajah Solusi, pilih dan tahan (atau klik kanan)
proyek paket driver Anda, dan pilih Properti.
Di halaman properti untuk paket, navigasikan ke Properti > Konfigurasi

Penandatanganan > Driver Umum. Di bidang Uji Sertifikat , pilih Pilih Dari
Penyimpanan.
Dalam kotak dialog Pilih Sertifikat, temukan sertifikat penandatanganan pengujian

Anda. Nama sertifikat akan mirip dengan WDKTestCert yourName. Pilih sertifikat
penandatanganan pengujian Anda, dan pilih Properti. Di tab Detail , pilih Salin ke
File.
Ikuti instruksi dalam Wizard Ekspor Sertifikat untuk mengekspor file PFX. Saat Anda
ditanya apakah Anda ingin mengekspor kunci privat, pilih Ya, ekspor kunci privat.
Bagikan file PFX yang diekspor dengan pengembang lain.
Topik terkait
Menulis driver pertama Anda
Membangun Driver
Mengembangkan, Menguji, dan Menyebarkan Driver
Menandatangani Driver untuk Rilis
Publik
Sebelum Anda merilis paket driver ke publik, kami sarankan Anda mengirimkan paket
untuk sertifikasi. Untuk informasi selengkapnya, lihat Windows Sertifikasi Perangkat
Keras dan Layanan Dasbor Perangkat Keras. Untuk mengirimkan paket driver untuk
sertifikasi, Anda harus menandatangani paket dengan sertifikat yang Anda peroleh dari
otoritas sertifikasi tepercaya seperti VeriSign. Untuk informasi selengkapnya, lihat
Mendapatkan Sertifikat VeriSign. Anda juga akan memerlukan sertifikat silang, yang
disediakan oleh Microsoft.
Misalkan Anda telah memperoleh sepasang file dari Verisign: file kunci pribadi (PVK) dan
sertifikat penerbitan perangkat lunak (SPC). Misalkan Juga Anda memiliki solusi
Microsoft Visual Studio yang berisi proyek driver bernama MyDriver dan proyek paket
driver bernama Paket MyDriver. Untuk menandatangani paket driver Anda, ikuti
langkah-langkah berikut.
1. Gunakan alat Pvk2Pfx untuk membuat sertifikat Exchange Informasi Pribadi (PFX).
Alat Pvk2Pfx mengambil file PVK dan SPC Anda sebagai input dan membuat satu
file PFX. Untuk latihan ini, asumsikan bahwa file PFX Anda bernama MyCert.pfx.
Nota Setelah Anda membuat file PFX Anda, Anda dapat menggunakannya kembali
untuk proyek driver lain dan di komputer pengembangan driver lainnya.
2. Untuk menentukan sertifikat silang mana yang Anda butuhkan, lihat Sertifikat
Silang untuk Penandatanganan Kode Mode Kernel. Verifikasi bahwa sertifikat silang
yang diperlukan ada di $(BASEDIR)\CrossCertificates, di mana $(BASEDIR) adalah
direktori dasar kit Windows (misalnya c:\Program Files (x86)\Windows
Kits\8.0\CrossCertificates). Jika sertifikat silang yang diperlukan tidak ada, unduh
sertifikat silang dari Microsoft, dan salin ke $(BASEDIR)\CrossCertificates.
3. Di Visual Studio, buka solusi yang berisi proyek Paket MyDriver dan MyDriver. Jika
jendela Penjelajah Solusi belum terbuka, pilih Penjelajah Solusi dari menu
Tampilan. Di jendela Penjelajah Solusi, pilih dan tahan (atau klik kanan) proyek
paket, Paket MyDriver, dan pilih Properti.
4. Di halaman properti untuk paket, navigasikan ke Configuration Properties >

Driver Signing > General. Dalam daftar turun bawah Mode Tanda Tangan, pilih
Tanda Produksi. Untuk Sertifikat Produksi, lakukan salah satu hal berikut:
Masukkan jalur ke sertifikat penandatanganan Anda (misalnya
c:\Certs\MyCert.pfx).
Pilih Pilih Dari File, dan telusuri ke sertifikat penandatanganan Anda.
Pilih Pilih Dari Toko dan pilih sertifikat yang sebelumnya Anda impor ke toko
sertifikat.
Nota Untuk mengimpor sertifikat ke toko, pilih dan tahan (atau klik kanan)
file sertifikat (file PFX), dan pilih Instal PFX. Ikuti petunjuk di Panduan Impor
Sertifikat.
Nota Jika Anda memutuskan untuk menggunakan sertifikat yang berbeda di

lain waktu, pastikan sertifikat baru Anda diimpor ke toko sertifikat. Jika Anda
memilih Pilih Dari File dan telusuri ke sertifikat baru Anda, sertifikat baru
akan diimpor secara otomatis ke toko sertifikat. Namun, jika Anda secara
manual memasukkan jalur ke sertifikat baru Anda, itu tidak akan secara
otomatis diimpor ke toko sertifikat. Dalam hal ini, Anda harus memilih dan
menahan (atau mengklik kanan) file sertifikat baru Anda dan memilih Instal
PFX.
5. Pada halaman properti Umum Penandatanganan > Driver , untuk

TimeStampServer, pilih salah satu server stempel waktu di daftar turun bawah.
Nota Menggunakan salah satu server stempel waktu dalam daftar drop-down
mengharuskan Anda terhubung ke Internet saat Anda membangun paket driver
Anda. Jika Anda perlu terputus dari Internet saat membuat paket driver, kosongkan
bidang TimeStampServer .
6. Di halaman properti untuk paket, navigasikan ke Properti > Konfigurasi Inf2Cat >
General. Di daftar turun bawah Jalankan Inf2Cat , pilih Ya.
7. Tutup halaman properti untuk paket.
8. Pilih dan tahan (atau klik kanan) proyek driver, MyDriver, dan pilih Properti
9. Di halaman properti untuk driver, navigasikan ke Umum Penandatanganan >

Driver Properti > Konfigurasi. Atur TimeStampServer ke nilai yang sama dengan
yang Anda gunakan di properti paket driver. Atur Mode Tanda ke Tanda Produksi,
dan atur Sertifikat Produksi ke nilai yang sama dengan yang Anda gunakan di
properti paket driver.
10. Ketika Anda siap untuk membangun paket driver Anda, tekan F5. Visual Studio
akan secara otomatis menandatangani paket dan file driver Anda. Jika Anda telah
mengonfigurasi penyebaran, Visual Studio juga akan menyebarkan paket driver
yang Anda tandatangani ke komputer uji. Untuk informasi selengkapnya, lihat
Menyediakan komputer untuk penyebaran dan pengujian driver (WDK 8.1).
Melihat file paket driver

Setelah Anda membangun solusi Anda, navigasikan File Explorer ke folder yang berisi
paket driver Anda. Salah satu file dalam paket adalah file katalog. File katalog berisi
tanda tangan digital untuk paket. Untuk contoh melihat file dalam paket yang
ditandatangani, lihat Menulis driver KMDF berdasarkan templat.
Mendapatkan tanda tangan rilis WHQL

Ketika paket driver Anda lulus tes sertifikasi, paket tersebut dapat ditandatangani oleh
Windows Hardware Quality Labs (WHQL). Jika paket driver Anda ditandatangani oleh
WHQL, paket tersebut dapat didistribusikan melalui program Windows Update atau
mekanisme distribusi lain yang didukung Microsoft.
Untuk menginstal pada Windows 10, 8.1, 8, dan 7, paket driver Anda dapat memiliki satu
tanda tangan SHA1.
Mulai Windows 10, Anda juga perlu mengirimkan driver mode kernel Windows 10 baru
untuk penandatanganan digital di portal Dashboard Pusat Pengembang Perangkat
Keras Windows . Pengiriman driver kernel dan mode pengguna harus memiliki
Sertifikat Penandatanganan Kode Extended Validation ("EV") yang valid.
** Catatan ** Penghentian SHA1 tidak berlaku untuk driver. Untuk info tentang
berakhirnya dukungan SHA1 di Windows, lihat Windows Enforcement of Authenticode
Code Signing dan Timestamping .
Menandatangani paket dibandingkan dengan

menandatangani file driver individual
Paket driver berisi beberapa file. Biasanya paket driver memiliki satu atau lebih file
driver, file informasi (file INF), dan file katalog. File katalog berisi informasi tentang file
lain dalam paket. Saat Anda menandatangani file katalog, tanda tangan dalam file
katalog berfungsi sebagai tanda tangan untuk seluruh paket driver. Dengan kata lain,
menandatangani file katalog sama dengan menandatangani paket driver.
Dalam kebanyakan kasus, cukup untuk menandatangani paket driver, dan tidak perlu
menandatangani file driver individual. Namun, terkadang Anda perlu menandatangani
paket dan file driver individual. Misalnya, file driver boot-start harus ditandatangani
secara individual. Menandatangani file driver individu disebut sebagai menyematkan
tanda tangan dalam file driver.
Misalkan Anda memiliki solusi Visual Studio yang berisi proyek driver bernama MyDriver
dan proyek paket driver bernama Paket MyDriver. Visual Studio menyediakan dua set
halaman properti: satu untuk Driver Saya dan satu untuk Paket Driver Saya. Untuk
menandatangani paket driver, atur properti Penandatanganan Driver paket Driver Saya.
Untuk menyematkan tanda tangan di file driver individual, atur properti
Penandatanganan Driver Pengandar Saya.
Saat Anda mengatur properti paket driver untuk penandatanganan produksi, ingatlah
untuk menyesuaikan properti penandatanganan file driver individual yang sesuai.
Matikan penandatanganan untuk masing-masing file driver, atau atur file driver
individual untuk menggunakan sertifikat yang sama dengan yang Anda tentukan untuk
paket.
Nota Untuk melihat hash (juga disebut sidik jari) sertifikat, buka jendela Command
Prompt dan navigasikan ke direktori yang berisi sertifikat Anda. Masukkan perintah
certutil -dumpCertName.pfx, di mana CertName.pfx adalah nama sertifikat Anda.
Topik terkait
Perubahan Penandatanganan Driver di Windows 10
Ketersediaan Dukungan Penandatanganan Kode SHA-2 untuk Windows 7 dan
Windows Server 2008 R2
Sertifikasi Perangkat Keras Windows
Layanan Dasbor Perangkat Keras
Persyaratan Penandatanganan Driver untuk Windows
Sertifikat Silang untuk Penandatanganan Kode Mode Kernel
Panduan Penandatanganan Kode Mode Kernel
Penandatanganan Driver
Memasang Driver Boot-Start
Alat untuk Menandatangani Driver
Properti Penandatanganan Driver
Saat proyek dipilih dalam Penjelajah Solusi, dialog Properti di bawah simpul
Penandatanganan Driver, menampilkan dua bagian properti:
Di bawah Umum:
Mode Tanda Tangan
Tanda Uji - Microsoft Visual Studio harus menandatangani driver dengan sertifikat
pengujian yang ditentukan dalam Sertifikat Uji (default). Jika tidak ada sertifikat
yang ditentukan dalam Sertifikat Uji maka Visual Studio akan membuatnya untuk
pengemudi. Catatan: Windows mengharuskan semua driver 64-bit untuk
ditandatangani.
Tanda Produksi - Visual Studio harus menandatangani driver dengan sertifikat
produksi yang ditentukan dalam Sertifikat Produksi.
Non-Visual Studio tidak boleh menandatangani driver dengan sertifikat apa pun.
Sertifikat Uji
Kosong - Tidak ada sertifikat uji yang dipilih (default).

<Edit...> - Memilih sertifikat yang akan digunakan saat Mode Tanda diatur ke
Tanda Uji.
Sertifikat Produksi
Kosong - Tidak ada sertifikat produksi yang dipilih (default).

<Edit...> - Memilih sertifikat yang akan digunakan saat Mode Tanda diatur ke
Tanda Produksi.
Server Stempel Waktu
Verisign - Gunakan Verisign untuk cap waktu driver (default).

GlobalSign - Gunakan Globalsign untuk stempel waktu driver.
Tidak ada - Jangan cap waktu pengemudi.
Nonaktifkan Peringatan
Tidak - Tampilkan peringatan saat menandatangani driver (default).

Ya - Jangan menampilkan peringatan saat menandatangani driver.
Aktifkan Verbositas Diagnostik

Tidak - Jangan menampilkan verbositas diagnostik saat menandatangani driver
(default).
Ya - Tampilkan verbositas diagnostik saat menandatangani driver.
Algoritma Intisari File
Kosong - Tidak ada algoritma intisari file yang dipilih (default).

<Edit...> - Pilih algoritma digest file yang akan digunakan saat menandatangani
driver.
Di bawah Baris Perintah:

Opsi Tambahan
Opsi tambahan untuk menentukan saat menandatangani driver.

Memanfaatkan lingkungan pengembangan Visual Studio, WDK menyediakan fitur

pengujian yang memungkinkan Anda membangun, menyebarkan, dan men-debug
driver di komputer uji. Untuk berhasil menyebarkan driver ke sistem pengujian
menggunakan WDK, Anda harus terlebih dahulu mengatur dan mengonfigurasi
komputer uji. Anda dapat mengatur dan mengonfigurasi beberapa komputer jika Anda
ingin menguji driver Anda di bawah skenario pengujian yang berbeda.
Menyiapkan komputer uji

Ikuti petunjuk untuk Penyediaan komputer untuk penyebaran dan pengujian driver
(WDK 10).
Nota Jika Anda mengalami kesulitan menyiapkan komputer uji, lihat Pemecahan
Masalah Konfigurasi Penyebaran Driver, Pengujian, dan Debugging.
Mengatur properti penyebaran untuk solusi

driver Anda
Dari halaman properti untuk proyek driver Anda, Anda memiliki kontrol tambahan atas
bagaimana Anda ingin driver Anda digunakan untuk pengujian. Anda dapat memilih
untuk menyebarkan driver secara otomatis setiap kali Anda membangun solusi driver di
setiap konfigurasi.
2. Di halaman properti untuk proyek pengandar, pilih Properti Konfigurasi, pilih

Penginstalan Pengandar, lalu pilih Penyebaran.
3. Pilih komputer uji yang telah Anda konfigurasikan, atau pilih nama komputer yang
ingin Anda konfigurasikan untuk pengujian. Lihat Menyediakan komputer untuk
penyebaran dan pengujian driver (WDK 10).
Saat Anda mengaktifkan penyebaran untuk proyek paket driver Anda, driver secara
otomatis disebarkan ke komputer uji yang telah Anda pilih saat membuat solusi.
Anda dapat menggunakan halaman Properti penyebaran untuk mengonfigurasi
opsi penginstalan dan penyebaran driver. Lihat Properti Penyebaran untuk Proyek
Paket Driver.
4. Saat Mengaktifkan penyebaran di komputer uji, Anda juga dapat secara otomatis
mengaktifkan dan mengonfigurasi Driver Verifier, KMDF Verifier, atau UMDF
Verifier di komputer uji untuk meningkatkan efektivitas pengujian. Untuk mengatur
opsi ini untuk proyek paket driver, pilih Properti Konfigurasi, pilih Penginstalan
Pengandar, lalu pilih halaman properti berikut.
Properti Verifikasi Driver untuk Proyek Paket Driver

Properti Verifikasi KMDF untuk Proyek Paket Driver
Properti Verifikasi UMDF untuk Proyek Paket Driver
Membangun driver dan menyebarkan driver

untuk menguji komputer
1. Sebelum anda menyebarkan driver anda, pastikan bahwa anda dapat membangun
solusi driver anda. Solusi driver harus menyertakan paket driver dan driver
sehingga driver dapat diinstal pada komputer uji. Untuk informasi selengkapnya,
lihat Membuat Paket Driver dan Membangun Driver.
2. Sebelum Anda menyebarkan driver ke komputer uji, Anda juga perlu
menandatangani paket driver. Lihat Menandatangani Driver Selama
Pengembangan dan Pengujian.
3. Pilih komputer uji yang telah Anda konfigurasikan.
4. Untuk menyebarkan driver, pilih Build Solution atau Deploy Solution dari menu
Build , atau tekan F5 untuk membangun, menyebarkan, dan memulai debugging.
5. Di komputer uji, Anda mungkin melihat kotak dialog yang meminta Anda untuk
mengonfirmasi bahwa perubahan harus dilakukan. Dalam hal ini, penyebaran
dijeda hingga Anda mengonfirmasi.
Saat Anda menyebarkan driver, berkas pengandar disalin ke folder

%Systemdrive%\drivertest\drivers di komputer uji. Jika terjadi kesalahan selama
penyebaran, Anda dapat memeriksa untuk melihat apakah file disalin ke komputer uji.
Verifikasi bahwa file .inf, .cat, test cert, dan .sys, dan file lain yang diperlukan, ada folder
%systemdrive%\drivertest\drivers.
Pemecahan masalah penyebaran driver

Berikut adalah beberapa tips untuk memecahkan masalah penyebaran driver ke
komputer uji saat Anda menggunakan Visual Studio dan WDK.
Penyebaran gagal karena kode kesalahan: 2
Tambahkan kunci registri berikut:
HKLM\Software\Microsoft\DriverTest\Service
Di bawah kunci ini, buat DebugSession nilai DWORD, dan atur ke 0.
Anda hanya perlu mengatur nilai ini sekali, dan itu bertahan untuk penyebaran di masa
mendatang.
Tidak dapat menemukan properti penyebaran untuk proyek driver
Properti penyebaran hanya tersedia jika Anda memiliki paket driver. Jika solusi driver
Anda tidak memiliki proyek paket driver, Anda perlu menambahkannya. Paket driver
berisi komponen, seperti file INF yang diperlukan untuk instalasi. Untuk informasi
selengkapnya, lihat Paket Driver dan Membuat Paket Driver.
Afer Anda telah menambahkan paket driver, Anda dapat memilih dan menahan (atau
memilih kanan) proyek paket driver di Penjelajah Solusi dan pilih Properti. Di halaman
properti untuk paket pengandar, pilih Properti Konfigurasi, pilih Penginstalan
Pengandar, lalu pilih Penyebaran.
Masalah memilih, mengonfigurasi, atau menemukan komputer target
Untuk petunjuk tentang cara mengatur komputer target, menggunakan Windows Driver
Kit (WDK) 8.1 dan Windows Driver Kit (WDK) 8, lihat Menyediakan komputer untuk
penyebaran dan pengujian driver (WDK 10). Jika Anda memiliki masalah dengan
penyediaan komputer target, lihat Pemecahan Masalah Konfigurasi Penyebaran Driver,
Pengujian, dan Debugging.
Jika komputer target menjalankan versi N atau KN dari Windows, Anda harus menginstal
Media Feature Pack untuk versi N dan KN dari Windows. Lihat Menyediakan komputer
untuk penyebaran dan pengujian driver (WDK 10) untuk informasi lebih lanjut.
Masalah saat menginstal driver pada versi Windows 64-bit
Dimulai dengan Windows Vista, semua versi 64-bit dari Windows memerlukan kode
driver untuk memiliki tanda tangan digital untuk driver untuk memuat. Lihat
Menandatangani Driver dan Menandatangani Driver Selama Pengembangan dan
Pengujian.
Masalah saat menginstal driver (umum)
WDK dapat menyebarkan dan menginstal paket driver di komputer uji, tetapi hanya jika
driver memiliki semua komponen yang diperlukan untuk instalasi, seperti file INF. Lihat
Paket Driver informasi selengkapnya. Pastikan Anda dapat menginstal driver di luar
Visual Studio dan WDK. Misalnya, gunakan utilitas Konsol Perangkat, Devcon untuk
menguji apakah Anda dapat menginstal driver. Pastikan perangkat (jika Anda
memilikinya) terhubung ke komputer target. Untuk informasi selengkapnya, lihat
Instalasi Perangkat dan Driver serta Membuat Paket Driver.
Properti Penyebaran untuk Proyek Paket
Driver
Anda dapat mengonfigurasi penyebaran otomatis paket driver di komputer uji jarak
jauh di setiap konfigurasi proyek Anda. Dari halaman properti proyek untuk driver Anda,
Anda memiliki kontrol tambahan atas bagaimana Anda ingin menyebarkan driver Anda
untuk pengujian. Anda dapat memilih untuk menyebarkan driver secara otomatis setiap
kali Anda membangun solusi driver di setiap konfigurasi. Untuk informasi selengkapnya
tentang penyebaran, lihat Menyediakan komputer untuk penyebaran dan pengujian
driver (WDK 8.1) dan Menyebarkan Driver ke Komputer Uji.
Mengatur properti penyebaran untuk proyek

paket driver
1. Buka halaman properti untuk paket driver Anda. Pilih dan tahan (atau klik kanan)
proyek paket driver di Penjelajah Solusi dan pilih Properti.
Nota Jika solusi driver Anda tidak memiliki proyek paket driver, Anda perlu
menambahkannya. Lihat Membuat Paket Driver. Properti penyebaran hanya
tersedia jika Anda memiliki paket driver.
2. Di halaman properti untuk paket pengandar, pilih Properti Konfigurasi, pilih

3. Pilih opsi Aktifkan penyebaran . Ketika opsi ini dipilih, Anda dapat memilih
komputer uji untuk digunakan, dan Anda dapat mengonfigurasi opsi untuk
instalasi dan penyebaran driver.
Konfigurasi dan Platform Project

Daftar konfigurasi dan daftar platform memungkinkan Anda menerapkan pengaturan
penyebaran yang berbeda untuk konfigurasi proyek dan kombinasi platform yang
berbeda. Misalnya, Anda dapat menyebarkan driver ke satu komputer uji menggunakan
satu set opsi penyebaran untuk build debug dan ke komputer uji dan opsi penyebaran
yang berbeda untuk build rilis.
Mengaktifkan penyebaran
Anda dapat memilih untuk menyebarkan paket driver anda di komputer uji dengan
memilih Aktifkan penyebaran. Dalam kombinasi dengan daftar konfigurasi, Anda dapat
memilih untuk menonaktifkan penyebaran untuk build debug dan mengaktifkannya
untuk build rilis.
Untuk memastikan bahwa Anda sedang menguji versi terbaru driver, pilih Hapus versi
driver sebelumnya sebelum penyebaran.
Nama komputer target

Anda dapat memilih komputer target yang akan digunakan untuk penyebaran dan
pengujian. Jika Anda telah mengonfigurasi komputer uji, Anda dapat memilih salah satu
dari daftar ini. Jika Belum mengonfigurasi komputer uji, Anda dapat mengonfigurasinya
menggunakan tombol Telusuri . Untuk informasi selengkapnya tentang mengonfigurasi
komputer uji, lihat Menyebarkan Driver ke Komputer Uji. Pastikan konfigurasi proyek
dan platform sesuai dengan arsitektur target sistem pengujian Anda. Kesalahan
penyebaran umum terjadi ketika Anda mencoba menginstal driver x86 (Win32) pada
sistem yang menjalankan versi x64 Windows.
Untuk informasi tentang bekerja dengan debugger, lihat Memulai dengan debugging
Windows.
Opsi penginstalan pengandar

Jangan menginstal - Ini adalah opsi default. Anda dapat memilih untuk tidak menginstal
jika Anda mengimpor paket driver ke Toko Driver atau jika Anda mengaktifkan dan
mengatur opsi verifikasi driver di komputer uji.
Pembaruan Driver ID Perangkat Keras - Untuk menyebarkan driver untuk perangkat

keras yang sebenarnya, gunakan Instal dan Verifikasi sebagai gantinya. Untuk
menyebarkan driver untuk driver yang disebutkan root, Anda dapat menggunakan
Pembaruan Atau Penginstalan dan Verifikasi Driver ID Perangkat Keras. Jika Anda
memilih untuk menggunakan Pembaruan Driver ID Perangkat Keras, Anda harus
memasukkan ID perangkat keras yang sama yang muncul di file INF Anda, dan ID
perangkat keras itu harus memiliki formulir Root\Xxx. Jika Anda memilih opsi ini, berkas
disalin ke folder %Systemdrive%\drivertest\drivers di komputer jarak jauh. Utilitas Konsol
Perangkat, Devcon, menginstal driver untuk ID perangkat keras dan file INF dari paket.
Misalnya, Anda dapat memilih Pembaruan Driver ID Perangkat Keras dan mengatur
HWID ke Root\yourprojectname. Pastikan untuk mengecualikan ruang apa pun dalam
nama proyek Anda.
Baris Perintah Kustom - Anda dapat memilih untuk menjalankan skrip perintah kustom
Anda sendiri setelah instalasi. Jika Anda ingin menjalankan skrip perintah kustom,
pastikan untuk menambahkan file yang diperlukan di bawah bagian File Tambahan .
Berkas tambahan disalin ke folder %Systemdrive%\drivertest\drivers di komputer jarak
jauh.
Instal dan Verifikasi - Anda dapat memilih untuk menguji instalasi Anda menggunakan
skrip pengujian otomatis. Saat Anda memilih opsi ini dan menentukan Tugas Instalasi
Paket Driver Default (kemungkinan reboot) atau Tugas Instalasi Paket Driver Printer
Default (kemungkinan reboot), pengujian membaca file INF driver dan menginstal
driver. Tes kemudian memverifikasi bahwa pengemudi sudah bangun dan berjalan.
Setelah selesai, tes memberikan informasi rinci tentang keberhasilan atau kegagalan
tugas instalasi.
Kueri Perangkat Opsional - Nilai default adalah %PathToInf%. Jalur ke file INF driver
diganti secara otomatis. Seharusnya tidak perlu mengubah nilai ini kecuali Anda
memiliki kebutuhan untuk menempatkan file INF di lokasi yang berbeda.
Berkas Tambahan
Anda dapat menggunakan kotak File Tambahan untuk menentukan skrip atau aplikasi
instalasi kustom yang ingin Anda salin ke komputer uji jarak jauh. Berkas yang Anda
tentukan di sini ditambahkan ke folder %Systemdrive%\drivertest\drivers di komputer
jarak jauh.
Topik terkait
Cara menguji driver saat runtime menggunakan Visual Studio
Memulai dengan debugging Windows
Properti Verifikasi Driver untuk Proyek
Paket Driver
Driver Verifier adalah alat verifikasi run-time yang meningkatkan efektivitas pengujian
driver Anda. Anda dapat mengaktifkan dan mengonfigurasi Driver Verifier untuk
berjalan di semua komputer uji saat Anda menyebarkan driver untuk pengujian.
Anda harus selalu mengatur koneksi debugging mode kernel dengan komputer uji saat
Anda mengaktifkan Driver Verifier di komputer uji jarak jauh. Untuk informasi tentang
mengonfigurasi komputer target dan menyiapkan kabel debug, lihat Memulai dengan
debugging Windows.
Mengatur properti Verifikasi Driver untuk

proyek paket driver
Penginstalan Pengandar, lalu pilih Verifikasi Pengandar.
3. Pilih opsi Aktifkan Verifikasi Driver . Ketika opsi ini dipilih, Anda dapat memilih
driver atau driver untuk memverifikasi di komputer uji dan Anda dapat memilih
opsi Verifikasi Driver untuk digunakan.
Konfigurasi dan Platform Project

Daftar konfigurasi dan daftar platform memungkinkan Anda menerapkan pengaturan
penyebaran yang berbeda untuk konfigurasi proyek dan kombinasi platform yang
berbeda. Misalnya, Anda dapat menyebarkan driver ke satu komputer uji menggunakan
satu set opsi penyebaran untuk build debug dan ke komputer uji yang berbeda
menggunakan opsi penyebaran untuk build rilis.
Aktifkan Verifikasi Driver

Anda dapat mengaktifkan Driver Verifier di komputer uji untuk semua driver di
komputer, hanya untuk proyek driver, atau untuk daftar driver tertentu. Misalnya, Anda
mungkin ingin mengaktifkan Driver Verifier untuk kumpulan driver di tumpukan untuk
perangkat tertentu.
Verifikasi Driver
Menentukan driver atau driver mana yang harus diverifikasi di komputer uji.
Semua Pengemudi
Menentukan bahwa Driver Verifier memverifikasi semua driver yang diinstal pada
komputer uji jarak jauh.
Output Project
Menentukan bahwa Driver Verifier memverifikasi proyek driver yang diinstal pada
komputer uji jarak jauh. Ini adalah opsi default.
Daftar Driver
Menentukan driver atau daftar driver yang diverifikasi Driver di komputer uji jarak jauh.
Misalnya, Anda dapat mencantumkan semua driver yang terkait dengan perangkat
tertentu. Tentukan driver dengan nama biner, misalnya, Driver.sys. Gunakan titik koma
untuk memisahkan daftar driver. Nilai wildcard, seperti n*.sys, tidak didukung.
Bendera Standar Verifier Pengemudi

Anda dapat mengonfigurasi opsi Verifikasi Driver berikut di komputer uji.
Pemeriksaan kepatuhan DDI (Windows 8)
Ketika opsi ini aktif, Driver Verifier menerapkan seperangkat aturan antarmuka
driver perangkat (DDI) yang memeriksa interaksi yang tepat antara driver dan
antarmuka kernel sistem operasi.
Deteksi kebuntuan
Saat opsi ini aktif, Driver Verifier memantau penggunaan kunci spin, mutex, dan
mutex cepat oleh pengemudi. Ini mendeteksi apakah kode pengemudi berpotensi
menyebabkan kebuntuan di beberapa titik.
Verifikasi DMA
Ketika opsi ini aktif, Driver Verifier memantau penggunaan rutinitas akses memori
langsung (DMA) oleh pengemudi. Ini mendeteksi penggunaan buffer DMA,
adaptor, dan register peta yang tidak tepat.
Pemeriksaan Paksa IRQL
Saat opsi ini aktif, Driver Verifier menempatkan tekanan memori ekstrem pada
driver dengan membatalkan kode yang dapat di halaman. Jika driver mencoba
mengakses memori halaman di IRQL yang salah atau sambil memegang kunci
putar, Driver Verifier mendeteksi perilaku ini.
Verifikasi I/O
Ketika opsi ini aktif, Driver Verifier mengalokasikan Paket Permintaan Interupsi
(IDP) pengemudi dari kumpulan khusus, dan memantau penanganan I /O
pengemudi. Ini mendeteksi penggunaan rutinitas I / O yang ilegal atau tidak
konsisten. Driver Verifier juga memantau panggilan dari beberapa rutinitas I / O
Manager dan melakukan pengujian stres irps Plug-and-Play (PnP), IRPs daya dan
IMI IRPs.
Pemeriksaan lain-lain
Ketika opsi ini aktif, Driver Verifier mencari penyebab umum kecelakaan
pengemudi, seperti kesalahan penanganan memori yang dibebaskan.
Pelacakan kumpulan
Ketika opsi ini aktif, Driver Verifier memeriksa untuk melihat apakah pengemudi
telah membebaskan semua alokasi memorinya saat diturunkan. Ini
mengungkapkan kebocoran memori.
Pemeriksaan keamanan
Ketika opsi ini aktif, Driver Verifier mencari kesalahan umum yang dapat
mengakibatkan kerentanan keamanan, seperti referensi ke alamat mode pengguna
berdasarkan rutinitas mode kernel.
Pemeriksaan kolam renang khusus
Saat opsi ini aktif, Driver Verifier mengalokasikan sebagian besar permintaan
memori pengemudi dari kumpulan khusus. Kumpulan khusus ini dipantau untuk
pembengkakan memori, tayangan memori, dan memori yang diakses setelah
dibebaskan.
Pengaturan Spesifik Skenario Verifikasi

Pengemudi
Simulasi sumber daya rendah
Saat opsi ini aktif, Driver Verifier secara acak gagal dalam permintaan alokasi
kumpulan dan permintaan sumber daya lainnya. Dengan menyuntikkan kesalahan
alokasi ini ke dalam sistem, Driver Verifier menguji kemampuan pengemudi untuk
mengatasi situasi sumber daya rendah.
Paksa permintaan I/O yang tertunda
Saat opsi ini aktif, Driver Verifier menguji respons pengemudi terhadap nilai
pengembalian STATUS_PENDING dengan mengembalikan STATUS_PENDING untuk
panggilan acak ke IoCallDriver.
Pencatatan IRP
Saat opsi ini aktif, Driver Verifier memantau penggunaan IRP oleh pengemudi dan
membuat log penggunaan IRP.
Invarian MDL Memeriksa Stack (Windows 8)
Opsi Invarian MDL Checking for Stack memantau bagaimana driver menangani
buffer MDL invarian di seluruh tumpukan driver. Driver Verifier dapat mendeteksi
modifikasi ilegal buffer MDL invarian. Untuk menggunakan opsi ini, Verifikasi I/O
harus diaktifkan pada setidaknya satu driver.
Pemeriksaan MDL Invarian untuk Driver (Windows 8)
Opsi Invarian MDL Checking for Driver memantau bagaimana driver menangani
buffer MDL invarian berdasarkan per-driver. Opsi ini mendeteksi modifikasi ilegal
buffer MDL invarian. Untuk menggunakan opsi ini, Anda harus mengaktifkan
Verifikasi I/O pada setidaknya satu driver.
Power Framework Delay Fuzzing (Windows 8)
Ketika opsi ini aktif, Driver Verifier mengacak jadwal utas untuk membantu
membuang kesalahan konkurensi pada pengemudi.
Injeksi Kegagalan Berbasis Tumpukan (Windows 8)
Opsi Injeksi Kegagalan Berbasis Tumpukan menyuntikkan kegagalan sumber daya

dalam driver mode kernel. Opsi ini menggunakan driver khusus, KmAutoFail.sys,
bersama dengan Driver Verifier untuk menembus jalur penanganan kesalahan
driver.
Nota Anda tidak dapat menggabungkan Injeksi Kegagalan Berbasis Tumpukan

dengan simulasi sumber daya rendah.
Opsi Verifikasi Driver yang memerlukan
Verifikasi I/O
Ada empat opsi yang mengharuskan Anda mengaktifkan Verifikasi I/O terlebih dahulu.
Jika Verifikasi I/O tidak diaktifkan, opsi ini tidak diaktifkan.
Paksa Permintaan I/O yang Tertunda

Pencatatan IRP
Invarian MDL Memeriksa Stack
Invarian MDL Memeriksa Driver
Topik terkait
Verifikator Pengemudi
Memulai dengan debugging Windows
Properti Pemverifikasi KMDF untuk
Proyek Paket Driver
Mengatur properti untuk Pemverifikasi KMDF (atau pemverifikasi kerangka kerja) pada
komputer jarak jauh. Anda dapat menggunakan pengaturan ini saat membuat dan
menyebarkan driver KMDF ke komputer uji. Untuk informasi tentang driver KMDF, lihat
Kerangka Kerja Driver Mode Kernel.
Untuk informasi selengkapnya tentang pemverifikasi kerangka kerja, lihat Menggunakan

Pemverifikasi Kerangka Kerja dan Aplikasi Kontrol Pemverifikasi WDF.
Mengatur properti Pemverifikasi KMDF untuk

proyek paket driver
2. Di halaman properti untuk paket driver, pilih Properti Konfigurasi, pilih
Penginstalan Driver, lalu pilih Pemverifikasi KMDF.
3. Pilih opsi Aktifkan Pemverifikasi KMDF dan pilih pemverifikasi KMDF selalu aktif.
Ketika opsi ini dipilih, Anda dapat mengonfigurasi opsi verifikasi kerangka kerja
untuk driver KMDF.
Opsi Deskripsi
Mengaktifkan Pemverifikasi KMDF Mengaktifkan pemverifikasi KMDF pada

komputer uji. Pilihannya adalah pemverifikasi
KMDF selalu aktif atau pemverifikasi KMDF
nonaktif. Jika pemverifikasi KMDF tidak
diaktifkan, verifikasi kerangka kerja dasar
diaktifkan sebagai bagian dari Pemverifikasi
Driver jika versi KMDF adalah 1.9 atau lebih
tinggi.
Nama Layanan KMDF Menentukan nama layanan driver KMDF untuk

dipantau.
Pemeriksaan IRQL Mengaktifkan pemeriksaan IRQL dan

pemeriksaan kebocoran memori penting.
Teruskan Pemeriksaan yang Kompatibel Mengaktifkan pemeriksaan yang dibuat setelah

versi pengandar saat ini.
Opsi Deskripsi
Teruskan Pengujian Handler Kemajuan Menentukan opsi untuk menguji penanganan

kemajuan maju driver Anda.
Tidak Ada Kegagalan Alokasi Tidak ada

kesalahan yang akan disimulasikan untuk
menguji penanganan kemajuan ke depan driver
Anda.
Gagalkan Semua Alokasi Semua permintaan

I/O yang ditujukan untuk antrean kemajuan
maju akan tampak gagal, mengandalkan
penanganan kemajuan driver Anda ke depan.
Alokasi Gagal Acak Permintaan I/O yang gagal

secara acak yang ditujukan untuk antrean
kemajuan maju.
Lacak Handel Objek KMDF Menentukan daftar tipe handel objek untuk
dilacak.
Aktifkan Pesan Loader KMDF Mengaktifkan pesan pemuat KMDF melalui

debugger. Reboot komputer target diperlukan
untuk mengaktifkan ini.
Dimulai dengan Windows Vista, sistem operasi

menekan output DbgPrint secara default, yang
membuat pesan diagnostik WDF Loader tidak
dapat digunakan sampai penindasan ditimpa.
Pemverifikasi KMDF dapat mengelola ini untuk
Anda sehingga diagnostik loader KMDF
tersedia di debugger kernel untuk sistem ini.
Pengelogan verbose Mengaktifkan pengelogan verbose.
Halaman Memori untuk Log Menentukan jumlah halaman kumpulan non-

halaman (1-10) untuk dialokasikan untuk log
jejak peristiwa kernel. Opsinya adalah Pilihan
Runtime atau [1-10]. Jika Pilihan Runtime,
jumlah halaman bergantung pada runtime
KMDF. Dimulai dengan KMDF 1.9, runtime
menggunakan lebih banyak halaman saat
verifikasi diaktifkan dengan pengelogan
verbose.
Alokasi Memori Gagal Menentukan jumlah alokasi memori berhasil

yang diizinkan sebelum pemverifikasi KMDF
mulai gagal semua alokasi memori.
Topik terkait
Kerangka Kerja Driver Mode Kernel
Pemverifikasi Driver
Properti Verifikasi UMDF untuk Proyek
Paket Driver
Mengatur properti untuk Verifier UMDF di komputer uji. Anda dapat menggunakan
pengaturan ini saat membuat dan menyebarkan driver ke komputer uji.
Untuk informasi tentang penyebaran, lihat Menyediakan komputer untuk penyebaran

dan pengujian driver (WDK 8.1) dan Menyebarkan Driver ke Komputer Uji
Untuk informasi tentang debugging driver UMDF, lihat Cara Mengaktifkan Debugging
Driver UMDF dan Aplikasi Kontrol Verifikator WDF.
Menetapkan properti Umdf Verifier untuk

proyek driver
2. Di halaman properti untuk paket driver, pilih Properti Konfigurasi, pilih
Penginstalan Driver, lalu pilih Verifikasi UMDF.
3. Pilih opsi Sebarkan Verifikasi UMDF . Saat opsi ini diaktifkan (Ya), Anda dapat
memilih opsi Verifikasi UMDF untuk digunakan di komputer uji untuk
memverifikasi driver UMDF.
Opsi Deskripsi
Menyebarkan Verifier UMDF Mengaktifkan pengaturan verifikator UMDF di

komputer uji.
Nama Layanan UMDF Menentukan nama layanan driver UMDF untuk

dipantau.
Aktifkan Pelacakan Objek Melacak semua objek UMDF yang dibuat.
Aktifkan Pelacakan Jumlah Referensi Melacak semua referensi objek UMDF.
Upaya Restart Maksimum Jumlah maksimum kali UMDF akan memulai

ulang proses host yang gagal.
Opsi Deskripsi
Tingkat Penebangan UMDF Menentukan jumlah informasi yang dicatat oleh

verifikator UMDF untuk driver yang
dihostingnya.
Hanya Kesalahan Kritis dan Fatal - Hanya

mencatat kesalahan kritis dan fatal.
Semua Kesalahan - Mencatat semua kesalahan.
Peringatan dan semua Kesalahan - Mencatat

peringatan dan semua kesalahan.
Peristiwa informasi, Peringatan, dan semua

Kesalahan - Mencatat peristiwa informasi,
peringatan, dan semua kesalahan.
Output Verbose (Semua Peristiwa dalam

Bentuk Apa Pun) - Mencatat semua peristiwa.
Masuk ke Debugger Kernel Log verifier output ke debugger kernel.
Masuk ke Kernel Debugger Masuk ke debugger kernel saat proses host

UMDF gagal.
Lampirkan ke Debugger Kernel Lampirkan ke debugger kernel jika tidak ada

debugger mode pengguna yang terpasang.
Batas waktu pada Beban Driver (detik) Menentukan waktu untuk menunggu (dalam
hitungan detik) sebelum melampirkan
debugger setelah driver dimuat.
Batas waktu pada Driver Start (detik) Menentukan waktu untuk menunggu (dalam
hitungan detik) sebelum melampirkan
debugger setelah driver dimulai.
Verifikasi pada Level Saat Ini Memverifikasi driver yang dibuat menggunakan
versi kerangka kerja yang lebih lama terhadap
aturan versi kerangka kerja saat ini.
Topik terkait
Kerangka Kerja Driver Mode Pengguna
Properti Inf2Cat untuk Proyek Paket
Driver
Mengatur properti untuk alat Inf2Cat . Alat Inf2Cat dapat digunakan untuk membuat
file katalog untuk paket driver apa pun yang memiliki file INF.
Mengatur properti Inf2Cat untuk proyek paket

driver
2. Di halaman properti untuk paket driver, pilih Properti Konfigurasi lalu pilih
Inf2Cat.
3. Pilih opsi Jalankan Inf2Cat . Opsi ini menjalankan alat Inf2Cat pada file INF apa
pun dalam proyek (misalnya, file .inf, .inx, atau .inv).
Jika paket driver diinstal dengan menggunakan file INF, gunakan alat Inf2Cat untuk
membuat file katalog. Inf2Cat memvalidasi bahwa file yang direferensikan dalam file INF
ada dalam paket. Untuk menambahkan file ke paket, gunakan halaman properti untuk
proyek paket dan proyek driver. Lihat Membuat Paket Driver untuk informasi lebih
lanjut.
Opsi Deskripsi
Jalankan Inf2Cat Menjalankan alat Inf2Cat pada file INF apa pun
dalam proyek (misalnya, file .inf, .inx, atau .inv).
Daftar Versi Windows Menentukan daftar versi Windows yang

didukung oleh file .inf. Pisahkan setiap versi
Windows dengan koma. Pengaturan default
adalah $(Inf2CatWindowsVersionList), makro
yang membangun driver untuk platform dan
konfigurasi aktif.

Inf2Cat/os:WindowsVersionList.
Sertakan Hash Halaman Sertakan hash halaman dengan file. Secara

opsional diikuti oleh daftar file.

Inf2Cat/pageHashes[:file1][,file2]...].
Opsi Deskripsi
Tambahkan Atribut PE Menambahkan atribut katalog PE ke file. Secara

opsional diikuti oleh daftar file.

Inf2Cat/pe[:file1[,file2]...].
Tambahkan Drm Menambahkan atribut katalog tingkat DRM ke

file. Secara opsional diikuti oleh daftar file.

Inf2Cat/drm[:file1[,file2]...].
Penyedehanaan kata Menampilkan informasi terperinci tentang

output alat di jendela Output Visual Studio.

Inf2Cat/verbose.
Tidak Ada Katalog Mencegah pembuatan file katalog apa pun.

Inf2Cat/nocat.
Gunakan Waktu Lokal Gunakan zona waktu lokal saat memverifikasi

direktif Inf DriverVer Directive . Secara default
UTC, digunakan.

Inf2Cat/uselocaltime.
Untuk informasi selengkapnya tentang alat Inf2Cat, lihat Menggunakan Inf2Cat untuk
Membuat File Katalog.
Untuk informasi tentang halaman dan proyek properti, lihat lingkungan WDK dan Visual
Studio build.
Topik terkait
Membuat File Katalog untuk Paket Driver PnP
Inf2Cat
Menggunakan Inf2Cat untuk Membuat File Katalog
WDK dan Visual Studio membangun lingkungan
Cara membuat skrip penginstalan driver
kustom
Jika skenario penyebaran Anda membutuhkan lebih dari sekadar menginstal paket
driver di komputer uji, Anda dapat memilih untuk menjalankan skrip perintah kustom
Anda sendiri saat instalasi.
Prasyarat
Paket driver yang diuji ditandatangani dan siap dipasang. Anda harus terlebih
dahulu membuat dan membangun driver Anda dan kemudian membuat paket
driver untuk instalasi. Untuk informasi selengkapnya, lihat Membuat Driver dan
Membuat Paket Driver.
Uji komputer yang dikonfigurasi dan disediakan untuk penyebaran. Lihat Cara
menguji driver saat runtime menggunakan Visual Studio.
Instruksi
Langkah 1: Untuk menjalankan skrip perintah kustom

Anda sendiri saat instalasi
Dari halaman properti proyek untuk paket driver Anda, Anda dapat mengonfigurasi
apakah Anda ingin menyebarkan paket driver secara otomatis di komputer uji. Anda
juga dapat menjalankan skrip instalasi khusus dari halaman-halaman ini. Anda dapat
memilih untuk menyebarkan driver secara otomatis setiap kali Anda membangun solusi
driver di setiap konfigurasi. Untuk informasi selengkapnya tentang penyebaran, lihat
Menyebarkan Driver ke Komputer Uji dan Properti Penyebaran untuk Proyek Driver.
1. Buka halaman properti untuk proyek paket driver Anda. Pilih dan tahan (atau klik
kanan) proyek driver di Penjelajah Solusi dan pilih Properti.

Pengaturan Driver, lalu pilih Penyebaran.
3. Pilih Aktifkan penyebaran lalu pilih komputer uji yang akan digunakan.
4. Pilih Baris Perintah Kustom. Di dalam kotak, ketik skrip perintah kustom yang ingin
Anda jalankan saat instalasi.
5. Dalam kotak teks File Tambahan , tambahkan skrip perintah dan file instalasi
lainnya untuk disalin ke komputer uji. Saat driver disebarkan, berkas tambahan
disalin ke folder %Systemdrive%\drivertest\drivers di komputer jarak jauh.
Topik terkait
Properti Penyebaran untuk Proyek Driver
Membangun Driver
Menginstal driver pada Windows 10
Mobile
Untuk menginstal driver pada Windows 10 Mobile, gunakan file .spkg. .spkg ("file paket")
adalah modul mandiri yang berisi paket driver Anda.
WDK 10 mencakup PkgGen, alat yang menghasilkan file paket. Anda menjalankan
PkgGen di Visual Studio saat membuat driver, menggunakan prosedur berikut.
Menggunakan PkgGen untuk menghasilkan file paket
1. Pilih dan tahan (atau klik kanan) proyek driver dan pilih Tambahkan> Item Baru.
Selanjutnya, di bawah Visual C++->Windows Driver, pilih Manifes Paket. Pilih
Tambahkan.
2. Visual Studio menambahkan file yang disebut Package.pkg.xml ke proyek driver
Anda. Anda dapat memilih dan menahan (atau mengklik kanan) file dan memilih
properti untuk memverifikasi bahwa jenis item adalah PkgGen. (Pada halaman
properti yang sama ini, Anda dapat mengatur Dikecualikan dari Build ke Ya jika
Anda memutuskan nanti bahwa Anda ingin membangun proyek driver ini dan
tidak menghasilkan file paket.) Pilih OK.
3. Pilih dan tahan (atau klik kanan) proyek driver dan pilih Properti. Di bawah Properti
Konfigurasi, buka node PackageGen dan ubah Versi ke nilai apa pun yang Anda
suka.
4. Simpan pekerjaan Anda dan mulai ulang Visual Studio sebagai administrator.
5. Bangun driver Anda. Visual Studio menautkan ke pustaka yang diperlukan dan
menghasilkan file .cat, file .inf, biner driver, dan file .spkg.
Untuk melihat isi file paket, tambahkan akhiran .cab ke nama file lalu buka file kabin di
Windows Explorer.
Untuk mempelajari tentang menjalankan PkgGen di luar Visual Studio, lihat Membuat
paket seluler.
Untuk menginstal paket driver seluler (file.spkg), Anda memiliki dua opsi.
Jika Anda memperbarui paket yang ada pada sistem target atau menambahkan
paket baru ke target, gunakan IUTool.exe untuk menginstal paket driver .spkg.
Jika Anda menggabungkan paket ke dalam gambar OS seluler, gunakan ImgGen
untuk menambahkan paket driver .spkg ke gambar pembaruan flash penuh (FFU)
yang kemudian dapat di-flash ke perangkat seluler.
Menggunakan IUTool untuk menambahkan paket driver seluler (.spkg) ke perangkat
yang sedang berjalan
1. IUTool.exe berada di subdirektori \tools\bin\<architecture> WDK 10.
Pasang perangkat seluler Anda ke PC. Kemudian, dari prompt perintah yang
ditingkatkan, keluarkan perintah berikut:
C++
IUTool -p MyKmdfDriver.spkg
2. Untuk informasi selengkapnya, lihat Menambahkan driver ke gambar pengujian.
Menggunakan ImgGen untuk menambahkan paket driver (.spkg) ke gambar OS

seluler (.ffu)
1. Setelah Anda menginstal Visual Studio, pada layar Mulai, pilih folder Visual Studio
2015. Pilih dan tahan (atau klik kanan) Perintah Pengembang untuk VS2015, dan
pilih Jalankan sebagai Administrator.
Mem-flash gambar OS seluler (.ffu)

Untuk mem-flash gambar ke perangkat, gunakan FFUTool yang disediakan Microsoft,
atau kembangkan alat berkedip OEM kustom.
Debugging a Driver
Debugging driver kernel-mode membutuhkan dua komputer. Debugger berjalan pada

komputer host, dan kode yang di-debug berjalan pada komputer target. Komputer target
juga disebut komputer uji. Anda dapat men-debug driver mode pengguna di komputer
host atau di komputer target terpisah. Sebelum Anda dapat men-debug driver yang
berjalan di komputer target, Anda harus mengonfigurasi komputer target untuk
debugging.
Untuk informasi umum tentang driver debugging, lihat Memulai dengan debugging
Windows.
Untuk informasi tentang mengonfigurasi komputer target dan menyiapkan kabel debug
menggunakan koneksi jaringan, lihat Menyiapkan Debugging Kernel Jaringan KDNET
Secara Otomatis.
Lihat juga
Windows Debugging.
Menguji Driver
WDK menambahkan antarmuka pengujian driver ke Visual Studio yang memungkinkan

Anda membangun, menyebarkan, menginstal, dan menguji driver pada komputer uji
jarak jauh di jaringan Anda. WDK juga menyediakan koleksi tes driver perangkat yang
dapat Anda gunakan untuk menguji fitur dan fungsi driver Anda. Anda juga dapat
menulis menyesuaikan atau menulis tes driver Anda sendiri menggunakan Template Tes
Driver di Visual Studio.
Demonstrasi Video
Video ini menunjukkan cara menjalankan tes terkait driver dalam grup pengujian.
https://www.microsoft.com/id-id/videoplayer/embed/e12e5ce5-b41f-4b91-ab5f-
69598ccdcb57?autoplay=false&postJsllMsg=true&autoCaptions=id-id
Bagian ini menjelaskan beberapa strategi untuk menguji driver, dan informasi tentang
cara Anda memilih dan mengonfigurasi komputer jarak jauh untuk digunakan untuk
pengujian.
Untuk menyiapkan driver untuk distribusi publik, Anda harus menjalankan Windows
Hardware Certification Kit (HCK). Untuk informasi tentang program Sertifikasi Windows
dan cara mendapatkan HCK, lihat Program Sertifikasi Perangkat Keras Windows.
WDK menyediakan binari uji dan alat yang memudahkan untuk menjalankan tes Device
Fundamentals dari baris perintah.
Untuk informasi selengkapnya, lihat Menjalankan Tes
DevFund melalui baris perintah.
Topik Deskripsi
Topik Deskripsi
Tips untuk menguji driver selama Kapan Anda harus mulai menguji? Segera
pengembangan setelah Anda memiliki persyaratan untuk
pengemudi Anda, Anda dapat mulai
merancang kasus uji untuk menguji bahwa
persyaratan kritis telah diterapkan. Studi
menunjukkan bahwa menemukan dan
memperbaiki cacat dalam kode menjadi lebih
mahal semakin lama cacat tetap dalam kode.
Menemukan dan memperbaiki cacat di awal
siklus pengembangan lebih murah dan
mengganggu daripada menemukan cacat
setelah kode dirilis dan didistribusikan.
Membuat kasus uji anda lebih awal juga dapat
membantu anda menemukan masalah dalam
desain anda.
Cara menguji driver saat runtime menggunakan Ekstensi WDK untuk Visual Studio menyediakan
Visual Studio antarmuka pengujian perangkat yang
memungkinkan Anda untuk dengan mudah
membangun, menyebarkan, menginstal, dan
menguji driver pada komputer uji di jaringan
Anda. WDK menyediakan kumpulan tes driver
perangkat yang dapat Anda gunakan untuk
menguji fitur dan fungsi driver Anda.
Cara menulis tes driver menggunakan templat Anda dapat menggunakan Windows Driver Kit
Uji Driver (WDK) untuk Windows 8 membuat tes driver
Anda sendiri atau untuk menyesuaikan
beberapa tes yang disediakan. Anda dapat
menyebarkan tes yang Anda buat ke komputer
uji jarak jauh menggunakan kerangka
pengujian driver yang disediakan WDK untuk
Microsoft Visual Studio Ultimate 2012.
Lihat juga
Alat untuk Memverifikasi Driver
Tips untuk menguji driver selama
pengembangan
Kapan Anda harus mulai menguji? Segera setelah Anda memiliki persyaratan untuk
pengemudi Anda, Anda dapat mulai merancang kasus uji untuk menguji bahwa
persyaratan kritis telah diterapkan. Studi menunjukkan bahwa menemukan dan
memperbaiki cacat dalam kode menjadi lebih mahal semakin lama cacat tetap dalam
kode. Menemukan dan memperbaiki cacat di awal siklus pengembangan lebih murah
dan mengganggu daripada menemukan cacat setelah kode dirilis dan didistribusikan.
Membuat kasus uji anda lebih awal juga dapat membantu anda menemukan masalah
dalam desain anda.
Saran untuk pengujian selama pengembangan

Gunakan saran berikut untuk menguji kode driver dan paket driver Anda.
Untuk membantu Anda menemukan bug pada waktu kompilasi:
Deklarasikan fungsi callback yang disediakan driver dan rutinitas pengiriman

Menggunakan jenis peran fungsi. Ini membantu meningkatkan akurasi analisis
kode dan alat verifikasi dan efektivitas waktu pengujian Anda. Untuk informasi
selengkapnya tentang cara mendeklarasikan fungsi yang disediakan driver, lihat
Menggunakan Deklarasi Tipe Peran Fungsi.
Kompilasi kode Anda menggunakan opsi Peringatan Level4 (/W4 ). Memperbaiki

peringatan yang terdeteksi oleh kompiler akan meningkatkan kualitas kode driver
dan membantu menghilangkan cacat tambahan di awal siklus pengembangan.
Anotasi kode Anda menggunakan bahasa anotasi kode sumber Microsoft (SAL)
2.0. Anotasi menggambarkan bagaimana suatu fungsi menggunakan
parameternya — asumsi yang dibuatnya tentang mereka, dan jaminan yang
dibuatnya ketika selesai. Anotasi juga meningkatkan akurasi alat analisis kode.
Untuk informasi selengkapnya tentang anotasi khusus pengemudi, lihat Anotasi
SAL 2.0 untuk Driver.
Gunakan alat untuk memverifikasi driver saat Anda mengembangkan driver Anda.
Untuk panduan tentang kapan harus menggunakan alat verifikasi tertentu, lihat
Menganalisis Driver menggunakan Alat Analisis dan Verifikasi Kode.
Untuk menguji paket driver Anda:

Buat file INF dan paket driver Anda di awal proses pengembangan dan gunakan
selama pengujian.
Gunakan alat InfVerif untuk memverifikasi struktur dan sintaks file INF, dan untuk
membantu Anda mendiagnosis file INF dan masalah terkait instalasi lainnya.
Gunakan alat Inf2Cat (dengan opsi /nocat ) untuk melakukan verifikasi file INF
tambahan. Inf2Cat dapat memverifikasi bahwa file yang dirujuk oleh INF ada dan
ditempatkan di direktori paket seperti yang diharapkan INF.
Tandatangani driver untuk memfasilitasi pemasangan dan pengujian driver, seperti

yang dijelaskan dalam Menandatangani Driver selama Pengembangan dan
Pengujian.
Jalankan tes DriverInstall yang disertakan sebagai bagian dari tes Dasar Perangkat
yang disediakan di WDK. Lihat Cara menguji driver saat runtime menggunakan
Visual Studio dan Cara memilih dan mengonfigurasi Pengujian Dasar Perangkat.
Tes DriverInstall dapat dijalankan setelah driver disebarkan ke komputer uji. Anda
dapat menambahkan tes DriverInstall ke Grup Uji Driver. Tes DriverInstall muncul
di Kategori Uji Driver di bawah Semua Tes\Basic\Device
Fundamentals\DriverInstall.
Memecahkan masalah penginstalan perangkat dengan menggunakan Device

Manager untuk melihat informasi sistem tentang driver dan perangkat dan dengan
berkonsultasi dengan log SetupAPI. Log SetupAPI berisi informasi tentang urutan
operasi yang terjadi selama pemasangan perangkat atau driver.
Menggunakan Visual Studio dan WDK, Anda dapat menguji dan memecahkan
masalah instalasi paket driver saat anda menyebarkan driver ke komputer uji, lihat
Menyebarkan Driver ke Komputer Uji. Pilih opsi Instal dan Verifikasi dari Properti
Penyebaran untuk Proyek Paket Driver. Saat Anda memilih opsi ini dan
menentukan Tugas Instalasi Paket Driver Default (kemungkinan reboot) atau
Tugas Instalasi Paket Driver Printer Default (kemungkinan reboot), pengujian
membaca file INF driver dan menginstal driver. Tes kemudian memverifikasi bahwa
pengemudi sudah bangun dan berjalan. Setelah selesai, tes memberikan informasi
rinci tentang keberhasilan atau kegagalan tugas instalasi. Hasil menunjukkan di
Driver Test Group Explorer, di bawah Instalasi Driver Test Groups > Driver. Nama
tugasnya adalah Tugas Instalasi Paket Driver Default.
Untuk menguji driver Anda pada waktu berjalan:
Jalankan tes Device Fundamental yang disertakan dalam WDK. Lihat Cara menguji
driver saat runtime menggunakan Visual Studio dan Cara memilih dan
mengonfigurasi Pengujian Dasar Perangkat.
Siapkan debugger sehingga Anda dapat memecahkan masalah dan men-debug

hasil tes. Untuk informasi selengkapnya, lihat Memulai dengan debugging
Windows.
Aktifkan Verifikasi Pengemudi di komputer uji yang Anda gunakan untuk

penyebaran, lihat Properti Verifikasi Driver untuk Proyek Driver. Pilih opsi
pemeriksaan Kepatuhan DDI . Jika driver Anda gagal memeriksa Kepatuhan DDI,
jalankan Verifikasi Driver Statis dan tentukan aturan atau aturan yang
menyebabkan kegagalan. Verifikasi Driver Statis dapat membantu Anda
menemukan penyebab bug di file sumber Anda.
Uji driver dan perangkat Anda pada konfigurasi perangkat keras yang berbeda
sebanyak mungkin. Memvariasikan perangkat keras dapat membantu Anda
menemukan konflik antara perangkat dan kesalahan lain dalam interaksi
perangkat. Misalnya, Anda harus menguji driver dan perangkat Anda di komputer
yang memiliki arsitektur prosesor yang berbeda dan pada komputer yang
menjalankan versi Windows 32-bit dan 64-bit.
Uji driver dan perangkat Anda pada sistem multiprosesor. Kondisi ras dan masalah
waktu lainnya muncul pada sistem multiprosesor yang tidak akan ditemukan. Lihat
Cara memilih dan mengonfigurasi Parameter Pengujian dasar dan Boot Perangkat
untuk Menguji Driver untuk Beberapa Dukungan Grup Prosesor.
Uji driver dan perangkat Anda untuk kondisi sistem dan perangkat keras tertentu,
terutama kondisi tepi. Misalnya, kondisi ini mungkin termasuk "D3 panas" dan "D3
dingin." Pastikan driver dan perangkat Anda dapat kembali dengan benar dari
status daya perangkat "D3 panas" (tanpa kehilangan daya) dan "D3 dingin" (saat
daya dihapus dari perangkat). Untuk informasi selengkapnya, lihat Cara memilih
dan mengonfigurasi Pengujian Dasar Perangkat.
Cara menguji driver saat runtime
menggunakan Visual Studio
Ekstensi WDK untuk Visual Studio menyediakan antarmuka pengujian perangkat yang
memungkinkan Anda membangun, menyebarkan, menginstal, dan menguji driver
dengan mudah di komputer uji di jaringan Anda. WDK menyediakan kumpulan
pengujian driver perangkat yang dapat Anda gunakan untuk menguji fitur dan fungsi
driver Anda.
Prasyarat
Paket Driver yang siap diinstal. Anda harus terlebih dahulu membuat dan
membangun driver Anda. Mulai Windows 10 versi WDK, Paket Driver secara
otomatis dibuat untuk penginstalan. Untuk informasi selengkapnya, lihat
Membangun Driver.
Driver harus ditandatangani pengujian. Untuk informasi selengkapnya, lihat
Menandatangani Driver.
Komputer uji (atau komputer). Komputer uji harus berada di jaringan yang sama
dengan komputer yang Anda gunakan untuk pengembangan. Kedua komputer
harus tersambung ke domain yang sama, atau keduanya tersambung ke jaringan
di bawah grup kerja yang sama. Komputer pengujian harus menjalankan versi
Windows yang ingin Anda targetkan untuk pengujian.
Perangkat yang akan diuji.
(Disarankan) Siapkan koneksi debugging mode kernel ke komputer uji. Untuk
menggunakan koneksi jaringan untuk penelusuran kesalahan mode kernel,
komputer target harus berjalan Windows 8. Pada komputer yang menjalankan
Windows 7 atau Windows Vista, Anda dapat mengatur USB, 1394, atau koneksi
serial untuk penelusuran kesalahan mode kernel. Untuk informasi selengkapnya,
lihat Menyediakan komputer untuk penyebaran dan pengujian driver (WDK 8.1).
Instruksi
Langkah 1: Mengonfigurasi komputer untuk pengujian

Dari Visual Studio, Anda dapat mengonfigurasi dan memprovisikan komputer untuk
pengujian. Saat Anda mengonfigurasi komputer pengujian, kerangka kerja pengujian
driver WDK secara otomatis mengaktifkan komputer pengujian untuk penelusuran
kesalahan jarak jauh dan mentransfer biner pengujian dan file dukungan yang
diperlukan.
1. Jika Anda belum melakukannya, ikuti instruksi untuk Menyediakan komputer untuk
penyebaran dan pengujian driver (WDK 8.1).
2. Koneksi perangkat yang ingin Anda uji ke komputer pengujian atau komputer.
Setelah mengonfigurasi dan memprovisikan komputer uji, Anda dapat menggunakan

Visual Studio untuk menyebarkan driver, menjadwalkan pengujian, dan men-debug
driver di komputer uji. Untuk informasi tentang penyebaran dan tentang bagaimana
Anda dapat menyebarkan driver secara otomatis pada waktu build, lihat Menyebarkan
Driver ke Komputer Uji.
Anda juga dapat mengaktifkan dan mengatur opsi untuk Driver Verifier, alat verifikasi
runtime untuk driver. Driver Verifier memantau driver Saat Anda menjalankan pengujian
pada komputer uji. Untuk informasi tentang mengatur opsi Pemverifikasi Driver untuk
penyebaran, lihat Properti Pemverifikasi Driver untuk Proyek Driver.
Anda juga dapat menjalankan pengujian di luar Visual Studio, untuk informasi
selengkapnya lihat Cara menguji driver saat runtime dari Prompt Perintah. Mulai dari
WDK 8.1, Anda dapat menyalin dan menjalankan HCK Test Suites di komputer uji
menggunakan skrip perintah. Lihat Cara menjalankan HCK Test Suites di WDK 8.1.
Langkah 2: Pilih HCK Test Suite untuk dijalankan di

komputer uji (menggunakan WDK 8.1)
Dimulai dengan WDK 8.1, Anda dapat memilih HCK Test Suites untuk dijalankan pada
komputer uji. Rangkaian Pengujian HCK mencakup Pengujian Dasar-Dasar Perangkat,
dan pengujian Dasar Windows Hardware Certification kit (HCK) untuk grafis, pencitraan,
LAN nirkabel, broadband seluler (CDMA dan GSM), dan perangkat WiFi Direct.
Lihat Cara menjalankan HCK Test Suites di WDK 8.1.
Langkah 3: Pilih pengujian yang akan dijalankan pada

komputer uji (WDK 8 dan WDK 8.1)
Untuk membuat pengujian driver pada target pengujian yang berbeda lebih mudah,
pengujian dijadwalkan untuk dijalankan terhadap sistem pengujian dalam unit yang
disebut grup pengujian. Grup uji driver adalah kumpulan pengujian yang Anda pilih
untuk dijalankan pada komputer pengujian. Grup pengujian driver membantu Anda
mengatur pengujian dan hasil pengujian dari setiap lulus pengujian. Anda dapat
menyimpan hasil pengujian ke folder terpisah. Anda dapat membuat dan mengelola
grup pengujian, mengubah parameter yang diteruskan ke pengujian di grup pengujian,
dan menjadwalkannya untuk dijalankan terhadap sistem pengujian Anda.
1. Dari menu Driver , pilih Uji lalu pilih Uji Penjelajah Grup.
2. Di jendela Penjelajah Grup Uji Driver , pilih tombol Buat grup pengujian baru .
Atau, pilih Grup Pengujian Baru dari menu Driver .
3. Di jendela Grup Uji Driver untuk grup yang Anda buat, ketik nama di kotak teks
Nama Grup Uji untuk mengidentifikasi grup. Nama defaultnya adalah Driver Test
Group_nnnnn, di mana nnnnn mewakili jumlah grup pengujian
4. Pilih Tambahkan/Hapus Pengujian.
5. Dalam kotak dialog Tambahkan atau Hapus Pengujian Driver , Anda dapat
menentukan kategori dan arsitektur pengujian driver (Semua, x86, x64, Arm).
Secara default semua pengujian ditampilkan. Untuk melihat kategori pengujian,
pilih folder di daftar drop-down Kategori Pengujian Driver.
Misalnya, di WDK 8, untuk memilih semua pengujian Dasar-Dasar Perangkat yang

digunakan dalam Kit Sertifikasi Perangkat Keras (HCK) Windows, pilih Semua
Pengujian, Sertifikasi, dan Dasar-Dasar Perangkat. Untuk informasi tentang
pengujian, lihat Cara memilih dan mengonfigurasi Pengujian Dasar-Dasar
Perangkat.
Di WDK 8.1, pengujian Dasar-Dasar Perangkat berada di bawah folder Semua

Pengujian, Pengujian HCK, Sertifikasi, dan Dasar-Dasar Perangkat . Dalam WDK
8.1 Kategori Uji Driver termasuk Tes HCK (Dasar). Lihat Cara menjalankan HCK Test
Suites di WDK 8.1 untuk informasi selengkapnya.
6. Pastikan Anda memilih pengujian yang cocok dengan arsitektur komputer

pengujian yang dimaksudkan (x86, x64, Arm). Gunakan Filter Arsitektur untuk
hanya menampilkan pengujian yang akan berjalan di komputer pengujian Anda.
7. Pilih >> untuk menambahkan pengujian yang dipilih.
Langkah 4: Mengonfigurasi parameter pengujian

Setelah memilih pengujian untuk grup pengujian, Anda dapat mengonfigurasi salah satu
parameter runtime yang diteruskan ke pengujian driver. Misalnya, banyak Pengujian
Dasar-Dasar Perangkat memiliki parameter DQ, yang merupakan singkatan dari Device
Query. Ini adalah kueri Simple Data Evaluation Language (SDEL). Kerangka Kerja
Pengujian Driver Windows menyediakan SDEL sebagai bahasa kueri untuk
menyederhanakan tugas pengumpulan target berdasarkan atribut atau hubungan.
Misalnya, untuk menjalankan pengujian hanya untuk perangkat USB, gunakan kueri
perangkat: class='usb'. Anda dapat mengubah nilai setiap parameter pengujian dalam
grup pengujian.
1. Anda dapat melihat dan mengedit semua parameter pengujian runtime untuk
pengujian dengan memilih nama pengujian di jendela Grup Uji Driver . Jendela
Grup Uji Driver menyediakan deskripsi pengujian yang dipilih dan juga
memberikan deskripsi parameter pengujian yang Anda pilih. Untuk informasi
tentang mengatur parameter pengujian, lihat Cara memilih dan mengonfigurasi
Pengujian Dasar-Dasar Perangkat
2. Setelah Anda memilih pengujian, atur parameter, dan beri nama grup, pilih
Simpan.
Saat Anda menyimpan grup pengujian, grup pengujian akan menjadi grup
pengujian yang saat ini dipilih, dan nama grup pengujian akan muncul di toolbar
Uji Driver. Anda sekarang dapat menjalankan pengujian terhadap komputer uji
jarak jauh yang saat ini dipilih (juga ditampilkan di toolbar Uji Driver).
Langkah 5: Membangun dan menyebarkan driver

Dari menu Build , pilih Sebarkan Solusi.
Untuk informasi tentang menyebarkan driver secara otomatis pada waktu build, lihat
Menyebarkan Driver ke Komputer Uji. Untuk informasi tentang menyetel opsi
Pemverifikasi Driver secara otomatis pada komputer uji, lihat Properti Pemverifikasi
Driver untuk Proyek Driver. Anda harus selalu memfungsikan Pemverifikasi Driver pada
komputer uji Anda.
Langkah 6: Jalankan pengujian pada komputer pengujian

Dari menu Driver , pilih Uji Coba > Uji Coba. Secara default, perintah Jalankan
pengujian menjalankan semua pengujian dalam grup pengujian yang saat ini
dipilih.
Keterangan
Untuk informasi tentang pengujian driver dan kategori pengujian, lihat Cara memilih
dan mengonfigurasi Pengujian Dasar-Dasar Perangkat. Untuk informasi tentang
kerangka kerja pengujian, lihat Test Authoring and Execution Framework (TAEF) dan
Windows Driver Test Framework (WDTF).
Anda dapat menulis pengujian driver Anda sendiri dan menyebarkan pengujian tersebut
pada komputer pengujian. Untuk informasi selengkapnya, lihat Cara menulis pengujian
driver.
Menjalankan pengujian Dasar-Dasar Perangkat di Visual Studio di awal siklus

pengembangan akan membantu Anda ketika akhirnya siap untuk menguji driver Anda
menggunakan Kit Sertifikasi Perangkat Keras Windows (HCK).
Topik terkait
Cara menjalankan HCK Test Suites di WDK 8.1
Cara memilih dan mengonfigurasi Pengujian Dasar-Dasar Perangkat
Mulai menggunakan Windows Debugging
Program Sertifikasi Perangkat Keras
Kit Sertifikasi Perangkat Keras Windows (HCK)
Cara menguji driver saat runtime dari Prompt Perintah
Cara menjalankan HCK Test Suites di
WDK 8.1
Untuk mempermudah pengujian Windows driver di WDK, dimulai dengan WDK 8.1,
Anda sekarang dapat memilih rangkaian pengujian HCK untuk dijalankan pada
komputer uji. Rangkaian pengujian HCK mencakup pengujian dasar-dasar perangkat,
dan pengujian untuk grafis, pencitraan, LAN nirkabel, broadband seluler (CDMA dan
GSM), dan perangkat WiFi Direct. Ini adalah pengujian yang sama yang digunakan
dalam kit Sertifikasi Perangkat Keras Windows (Windows HCK). Lihat Program Sertifikasi
Windows untuk Perangkat Keras untuk informasi tentang HCK Windows.
Anda dapat menjalankan pengujian HCK dari jendela Prompt Perintah atau dari Visual
Studio. Selain itu, Anda dapat menyalin pengujian ini ke lokasi baru—yang mungkin
merupakan komputer lain atau drive kunci USB—dan menjalankan pengujian dari lokasi
tersebut. Meluncurkan pengujian secara otomatis mengatur konfigurasi lokal apa pun
yang diperlukan untuk menjalankan pengujian.
Menjalankan HCK Test Suites di komputer uji menggunakan Visual Studio

Menjalankan HCK Test Suites dari jendela Command Prompt
Menjalankan HCK Test Suites di komputer uji

menggunakan Visual Studio
Jika Anda belum melakukannya, ikuti instruksi di Menyediakan komputer untuk
penyebaran dan pengujian driver (WDK 8.1). Setelah Anda mengonfigurasi komputer uji,
nama komputer uji muncul di toolbar. Pastikan Anda telah memilih komputer uji yang
telah Dikonfigurasi untuk perangkat yang anda uji dengan HCK Test Suite.
Siapkan komputer uji sesuai kebutuhan, dengan menginstal perangkat dan driver dan
persyaratan tambahan untuk topologi pengujian (lihat prasyarat pengujian HCK untuk
perangkat yang Anda uji). Sebagai pengganti pengontrol HCK Studio dan HCK, Anda
menjalankan pengujian menggunakan Visual Studio dan WDK 8.1.
Untuk memilih HCK Test Suite untuk dijalankan di komputer uji
1. Dari menu Driver , pilih Uji lalu pilih Uji Penjelajah Grup.
2. Di jendela Driver Test Group Explorer , pilih salah satu HCK Test Suites.
Saat Anda memilih Test Suite, Test Suite muncul di jendela Grup Uji Driver .
3. Pastikan Anda telah memilih komputer uji yang telah Dikonfigurasi untuk
perangkat yang sedang Anda uji dengan HCK Test Suite.
4. Untuk menggunakan rangkaian pengujian HCK, Anda juga harus mengikuti

persyaratan konfigurasi untuk perangkat yang Anda uji.
5. Anda dapat menggunakan kotak centang untuk memilih pengujian yang cocok
dengan arsitektur komputer uji yang dimaksudkan (x86, x64, Arm).
6. Dari menu Driver , pilih Uji Coba > Uji Coba. Secara default, perintah Jalankan
pengujian menjalankan semua pengujian dalam grup pengujian yang saat ini
dipilih.
Anda juga dapat menyalin salah satu HCK Test Suites yang disediakan dan
mengekspornya, bersama dengan file dukungan pengujian yang diperlukan sehingga
Anda dapat menjalankan rangkaian pengujian dari jendela Prompt Perintah.
Untuk mengekspor Test Suite
1. Di Test Group Explorer, pilih dan tahan (atau klik kanan) HCK Test Suite yang ingin
Anda salin dan pilih Ekspor Test Suite... dari menu short-cut. (Perintah
menjalankan skrip CopyMe.cmd ).
2. Pilih folder tujuan untuk rangkaian pengujian. Anda dapat mengekspor rangkaian
pengujian ke berbagi jaringan atau ke flash drive USB.
3. Untuk menjalankan HCK Test Suite, buka jendela Prompt Perintah di komputer
pengujian dengan izin yang ditingkatkan. Navigasikan ke direktori tujuan dan
jalankan skrip RunMe.cmd . Untuk informasi selengkapnya, lihat Untuk
menjalankan HCK Test Suite dari jendela Command Prompt.
Menjalankan HCK Test Suites dari jendela

Command Prompt
Salin Rangkaian Pengujian HCK
1. Buka jendela Prompt Perintah Visual Studio. Navigasi ke direktori

%WindowsSdkDir%\Testing\Tests\HCK Tests\Basic. Misalnya, C:\Program Files
(x86)\Windows Kits\8.1\Testing\Tests\HCK Tests\Basic
2. Jalankan skrip CopyMe.cmd dan tentukan nama rangkaian pengujian dan direktori
tujuan. Skrip memiliki sintaks berikut:
C++
CopyMe.cmd testSuite destinationPath
testSuite adalah salah satu dari berikut ini:
Dasar-Dasar Device.Device
Device.Graphics
Device.Imaging
Device.Network.MobileBroadband.CDMA
Device.Network.MobileBroadband.GSM
Device.Network.WLAN
DestinationPath dapat berupa jalur yang valid, termasuk jalur UNC. Misalnya, Anda
dapat menyalin HCK Test Suite ke flash drive USB, atau ke berbagi di server.
C++
C:\Program Files (x86)\Windows Kits\8.1\Testing\Tests\HCK

Tests\Basic>CopyMe "De
vice.Device Fundamentals" d:\temp\devfund
Copying test target setup installers
Copying TAEF and WDTF infrastructure
Copying debuggers infrastructure
Copying x86 tools
Copying x64 tools
Copying arm tools
Copying test suite
Copy complete!
Run on any computer using an administrator command prompt in the same

folder as
the RunMe.cmd script.
"RunMe.cmd <infFileName>"
Catatan Jika komputer pengujian berjalan Windows 7, Anda perlu mengunduh dan
menginstal Microsoft .NET Framework 4.5 sebelum dapat menjalankan HCK Test Suite.
Untuk menjalankan HCK Test Suite dari jendela Prompt Perintah
1. Pada komputer pengujian yang telah Anda konfigurasi untuk pengujian, buka
jendela Prompt Perintah dengan hak istimewa yang ditinggikan (Jalankan sebagai
administrator) dan navigasikan ke direktori tempat Anda menyalin HCK Test Suite.
2. Jalankan skrip RunMe.cmd dan tentukan jalur dan nama file INF. Skrip memiliki
sintaks berikut:
C++
RunMe.cmd infFileName
Contohnya:
C++
RunMe.cmd myDriver.inf
Catatan Rangkaian pengujian Device.Graphics tidak menggunakan file INF, namun,

skrip RunMe.cmd memerlukan file INF. Anda dapat memberikan nama file INF
pengganti jika perlu.
HCT Test Suites

HCK Tests.Basic.Device.Device Fundamentals Test Suite
HCK Tests.Basic.Device.Graphics Test Suite
HCK Tests.Basic.Device.Imaging Test Suite
HCK Tests.Basic.Device.Network.MobileBroadband.CDMA Test Suite
HCK Tests.Basic.Device.Network.MobileBroadband.GSM Test Suite
HCK Tests.Basic.Device.Network.WLAN Test Suite
Untuk informasi tentang menentukan parameter pengujian, lihat Parameter Pengujian

Dasar-Dasar Perangkat. Jika perangkat di bawah pengujian atau salah satu perangkat
anaknya adalah adaptor WiFi atau perangkat jaringan, Anda mungkin perlu mengatur
parameter Wpa2PskAesSsid, Wpa2PskPassword, atau WDTFREMOTESYSTEM .
HCK Tests.Basic.Device.Device Fundamentals Test Suite

Gunakan rangkaian pengujian ini untuk pengujian keandalan umum dari semua jenis
perangkat. Anda harus mengikuti persyaratan perangkat keras, perangkat lunak, dan
pengujian untuk pengujian HCK seperti yang dijelaskan dalam Prasyarat Pengujian
Keandalan Device.Fundamentals. Sebagai pengganti pengontrol HCK Studio dan HCK,
Anda menjalankan pengujian dasar menggunakan Visual Studio dan WDK 8.1.
HCK Tests.Basic.Device.Device Fundamentals

Test Suite
HCK Tests.Basic.Device.Device Fundamentals
Test Suite
Persyaratan perangkat keras, perangkat lunak, Prasyarat Pengujian Keandalan

dan pengujian Device.Fundamentals
Deskripsi pengujian DF - PNP (nonaktifkan dan aktifkan) dengan IO

Sebelum dan Sesudah (Dasar)
DF - Tidur dengan IO Sebelum dan Sesudah

(Dasar)

Gunakan rangkaian pengujian ini untuk menguji adaptor grafis atau chipset. Anda harus
mengikuti persyaratan perangkat keras, perangkat lunak, dan pengujian untuk
pengujian HCK seperti yang dijelaskan dalam Prasyarat Adaptor Grafis atau Pengujian
Chipset. Sebagai pengganti pengontrol HCK Studio dan HCK, Anda menjalankan
pengujian dasar menggunakan Visual Studio dan WDK 8.1.
Persyaratan perangkat keras, perangkat lunak, Prasyarat Pengujian Adaptor Grafis atau
dan pengujian Chipset
Deskripsi pengujian Uji Adaptor Grafis atau Chipset

Gunakan rangkaian pengujian ini untuk menguji printer. Rangkaian pengujian
menggunakan pengujian yang merupakan bagian dari Pengujian Device.Imaging HCK.
Sebagai pengganti pengontrol HCK Studio dan HCK, Anda menjalankan pengujian dasar
menggunakan Visual Studio dan WDK 8.1.
Persyaratan perangkat keras, perangkat lunak, Prasyarat Pengujian Printer

dan pengujian
Deskripsi pengujian Pengujian Printer
HCK Tests.Basic.Device.Network.MobileBroadband.CDMA
Test Suite
Gunakan rangkaian pengujian ini untuk menguji perangkat CDMA Mobile Broadband.
Ikuti panduan untuk menyiapkan dan mengonfigurasi perangkat Anda seperti yang
dijelaskan dalam Prasyarat Pengujian Broadband Seluler. Sebagai pengganti pengontrol
HCK Studio dan HCK, Anda menjalankan pengujian dasar menggunakan Visual Studio
dan WDK 8.1.
HCK
Tests.Basic.Device.Network.MobileBroadband.CDMA
Test Suite
Persyaratan perangkat keras, perangkat lunak, dan Prasyarat Pengujian Broadband Seluler
pengujian
Deskripsi pengujian Tes CDMA
HCK Tests.Basic.Device.Network.MobileBroadband.GSM
Test Suite
Gunakan rangkaian pengujian ini untuk menguji perangkat Mobile Broadband GSM.
Ikuti panduan untuk menyiapkan dan mengonfigurasi perangkat Anda seperti yang
dijelaskan dalam Prasyarat Pengujian Broadband Seluler. Sebagai pengganti pengontrol
HCK Studio dan HCK, Anda menjalankan pengujian dasar menggunakan Visual Studio
dan WDK 8.1.
HCK
Tests.Basic.Device.Network.MobileBroadband.GSM
Test Suite
Persyaratan perangkat keras, perangkat lunak, dan Prasyarat Pengujian Broadband Seluler
pengujian
Deskripsi pengujian Pengujian GSM
HCK Tests.Basic.Device.Network.WLAN Test Suite

Gunakan rangkaian pengujian ini untuk menguji perangkat LAN Nirkabel (802.11). Ikuti
panduan untuk menyiapkan dan mengonfigurasi perangkat Anda seperti yang
dijelaskan dalam Prasyarat Pengujian LAN Nirkabel (802.11) untuk HCK. Sebagai
pengganti pengontrol HCK Studio dan HCK, Anda menjalankan pengujian dasar
menggunakan Visual Studio dan WDK 8.1.
HCK Tests.Basic.Device.Network.WLAN Test

Suite
HCK Tests.Basic.Device.Network.WLAN Test
Suite
Persyaratan perangkat keras, perangkat lunak, Prasyarat Pengujian LAN Nirkabel (802.11)
dan pengujian
Deskripsi pengujian Tes WLAN L1
Topik terkait
Cara menguji driver runtime menggunakan Visual Studio
Cara memilih dan mengonfigurasi Pengujian Dasar-Dasar Perangkat
Mulai menggunakan Windows Debugging
Kit Sertifikasi Perangkat Keras Windows (HCK)
Cara menguji driver saat runtime dari Prompt Perintah
Cara memilih dan mengonfigurasi
pengujian Dasar Perangkat
WDK untuk Windows 8 menyediakan kerangka pengujian driver yang mencakup

serangkaian tes yang disebut tes Device Fundamentals. Tes Device Fundamentals adalah
kumpulan tes yang digunakan baik secara internal di Microsoft untuk menguji driver
dan sampel driver yang dikirimkan dengan Windows dan WDK, dan secara eksternal
sebagai bagian dari Program Sertifikasi Windows untuk Perangkat Keras. Anda dapat
menjalankan tes dari lingkungan pengembangan Anda. Saat Anda menjalankan
pengujian, Anda dapat menggunakan parameter yang sama yang digunakan untuk
pengujian Sertifikasi Windows, atau Anda dapat mengonfigurasi dan menyesuaikan
parameter run-time sesuai dengan kebutuhan pengujian dan debugging Anda.
Mendapatkan hasil maksimal dari tes Device

Fundamentals
Untuk mendapatkan manfaat maksimal dari pengujian Dasar-Dasar Perangkat,
perangkat Anda harus didukung oleh plug-in I/O default. Untuk melihat apakah jenis
perangkat Anda didukung dan untuk menentukan apakah ada persyaratan khusus untuk
pengujian, lihat plug-in WDTF Simple I/O Yang Disediakan. Tes Dasar Perangkat juga
menyertakan utilitas yang dapat Anda gunakan untuk menguji perangkat Anda untuk
melihat apakah itu didukung. Jika perangkat Anda tidak didukung, Anda dapat
membuat plug-in WDTF Simple I/O. di Visual Studio. Untuk informasi selengkapnya,
lihat Cara menyesuaikan I/O untuk perangkat Anda menggunakan WDTF Simple I/O
Action Plug-in.
Tentang Pengujian Dasar Perangkat

WDK menyediakan tes Dasar Perangkat dalam dua konfigurasi, Dasar dan Sertifikasi. Di
kedua konfigurasi, Anda dapat mengedit parameter pengujian untuk memvariasikan
panjang pengujian, jumlah siklus pengujian yang harus dilakukan, dan parameter
pengujian lainnya, tergantung pada bagaimana Anda ingin menguji perangkat atau
driver yang ditargetkan. Konfigurasi Dasar ditujukan untuk pengandar umum dan
pengujian dan debugging perangkat. Gunakan konfigurasi Dasar sejak dini dan
sepanjang siklus pengembangan. Pengujian dalam konfigurasi Dasar memiliki
pengaturan yang sama yang digunakan dalam pengujian Sertifikasi Windows, dengan
pengecualian memiliki waktu berjalan yang lebih pendek. Dalam konfigurasi Sertifikasi,
pengujian memiliki pengaturan yang sama yang digunakan dalam pengujian Sertifikasi
Windows. Gunakan konfigurasi Sertifikasi untuk memverifikasi kesiapan pengujian
perangkat atau driver Anda untuk Program Sertifikasi Windows untuk Perangkat Keras.
Tes Dasar Perangkat mencakup pengujian dalam kategori berikut.
Tes CHAOS (Dasar Perangkat)

Tes Cakupan (Dasar Perangkat)
Tes CPUStress (Dasar Perangkat)
Tes Penginstalan Driver (Dasar Perangkat)
Tes I/O (Dasar Perangkat)
Tes Penetrasi (Dasar Perangkat)
Tes PNP (Dasar Perangkat)
Tes Reboot (Dasar Perangkat)
Tes Tidur (Dasar Perangkat)
Utilitas
Mengatur parameter uji run-time

Anda dapat mengedit parameter run-time untuk banyak pengujian Dasar Perangkat. Di
jendela Grup Uji Pengemudi, panah (») di samping nama pengujian menunjukkan bahwa
pengujian memiliki parameter yang dapat Anda ubah. Pilih panah (») untuk
menampilkan parameter run-time.
Salah satu parameter yang paling berguna adalah DQ, yang menentukan perangkat
target untuk diuji. Nilai default (IsDevice) menguji semua perangkat pada komputer
target. Parameter DQ mengambil kueri WDTFSDEL yang mengidentifikasi perangkat
target. Anda dapat menentukan perangkat tertentu untuk pengujian, misalnya:
DeviceID='USB\ROOT_HUB\41CD5D0220&&' hanya memilih perangkat untuk

pengujian dengan DeviceID yang ditentukan.
Untuk informasi selengkapnya tentang DQ dan parameter run-time lainnya, lihat

Parameter pengujian Fundamental Perangkat.
Parameter Pengujian Fundamental Perangkat

Parameter Deskripsi
DQ Mengidentifikasi perangkat atau perangkat

yang harus digunakan untuk pengujian.
Parameter DQ mengambil kueri WDTFSDEL
Parameter Deskripsi
yang mengidentifikasi perangkat target. Kueri

ini bisa sangat fleksibel dan dapat digunakan
untuk mengekspresikan sejumlah perangkat,
dari satu perangkat ke semua perangkat dalam
sistem.
Contoh umum:
Untuk menguji semua perangkat yang diinstal

dengan File INF tertentu:
INF::FileName=INF_File_Name
Misalnya,
INF::OriginalInfFileName='KMDFTest.inf'
Inf::OriginalInFileName dapat digunakan

dengan INF apa pun.
Untuk menguji perangkat dengan Id Perangkat
tertentu:
DeviceId='DeviceId'
Misalnya,
DeviceID='USB\ROOT_HUB\4&1CD5D022&0'
Untuk menguji perangkat dengan antarmuka
tertentu:
Antarmuka::InterfaceGUID
Untuk menguji perangkat dengan huruf driver
tertentu:
Volume::D riverLetter='DriveLetter'
Misalnya, Volume::D riverLetter='c:\'

Untuk menguji perangkat dengan driver
tertentu:
DriverBinaryNames=mydriver.sys
Dimana KMDFTest.inf adalah inf yang

digunakan untuk menginstal driver. Anda juga
dapat menggunakan folloiwng target
perangkat (s) yang menggunakan
driverKMDFTest.sys .
(DriverBinaryNames='KMDFTest.sys')
berfungsi.
Setelah mengatur SDEL dengan benar, Anda

akan melihat output berikut di konsol saat
Anda menjalankan pengujian.
WDTF_TARGETS : INFO : - Query("IsDevice AND

((Inf::OriginalInfFileName='KMDFTest.inf'))")
WDTF_TARGETS : INFO : Target: KMDFTest
Parameter Deskripsi
Device ROOT\SAMPLE\0000 WDTF_TEST : INFO

: WARNING: Pengujian tidak memberlakukan
bahwa Driver Verifier diaktifkan. WDTF_TEST :
INFO : DV diaktifkan dengan Flag:=0x209bb
WDTF_TEST : INFO : DV berhasil diaktifkan
untuk semua driver devnode
ini(UniqueTargetName):=KMDFTest Device
ROOT\SAMPLE\0000 WDTF_TARGET : INFO : -
GetInterface("Support") WDTF_TARGET : INFO :
TARGET: DESKTOP-2OVFH3G WDTF_TARGETS :
INFO : - Query("IsDevice") WDTF_TARGETS :
INFO : Target: KMDFTest Device
ROOT\SAMPLE\0000 WDTF_TARGETS : INFO : -
GetRelations("below-or-self/", "IsDevice")
WDTF_TARGETS : INFO : Target: KMDFTest
Device ROOT\SAMPLE\0000 WDTF_TARGETS :
INFO : -
GetInterfacesIfExist("SimpleIOStressProc")
WDTF_SIMPLE_IO : INFO : - Untuk
Target:KMDFTest Device
ROOT\SAMPLE\SAMPLE\0000 no Simple IO
Interface ditemukan. WDTF_SIMPLE_IO : INFO :
- Untuk Target:KMDFTest Device
ROOT\SAMPLE\0000 WDTF akan menggunakan
ANY Simple IO Interface.
Lihat file terlampir konfigurasi dan file log

untuk detail lebih lanjut.
WDTF_TARGETS : INFO
: Target: KMDFTest Device ROOT\SAMPLE\0000
WDTF_TEST : INFO : Lakukan 1 siklus uji
terminasi I/O WDTF_TEST : INFO : I/O
termination cycle #1
WDTF_SIMPLEIO_STRESS_PROC : INFO : -
StartAsync(KMDFTest Device
ROOT\SAMPLE\0000 )
WaitAsyncCompletion(KMDFTest Device
ROOT\SAMPLE\0000 ) WDTF_SIMPLE_IO : INFO
: - For Target: KMDFTest Device
ROOT\SAMPLE\0000 tidak ditemukan
Antarmuka IO Sederhana. WDTF_SIMPLE_IO :
INFO : - Untuk Target:KMDFTest Device
ROOT\SAMPLE\0000 WDTF akan menggunakan
ANY Simple IO Interface. WDTF_SIMPLE_IO :
INFO : - Buka(KMDFTest Device
ROOT\SAMPLE\0000 ) Coba hitung 1
WDTF_SUPPORT : INFO : - WaitForMinutes : 1
WDTF_SIMPLE_IO : INFO : -
Parameter Deskripsi
PerformIO(KMDFTest Device
ROOT\SAMPLE\0000 ) Hitung 1
Terminate(KMDFTest Device
ROOT\SAMPLE\0000) proses
Untuk menguji semua perangkat kelas
perangkat tertentu:
Misalnya, Class=CDROM akan menguji semua
perangkat CDROM kelas.
Misalnya, ClassGUID= {36fc9e60-c465-11cf-

8056-444553540000} akan menguji semua
perangkat yang kelasNYA GUID cocok dengan
GUID yang ditentukan. Dalam hal ini, GUID
adalah untuk kelas USB.
DoPoolCheck Benar atau Salah. Memantau penggunaan

driver dari kumpulan memori sistem paged dan
nonpaged dengan menggunakan tag
kumpulan dan daftar lookaside. Opsi ini juga
memantau perubahan jumlah pengecualian
yang ditangani yang mungkin mengindikasikan
kesalahan dalam penanganan pengecualian.
ChangeBufferProtectionFlags Benar atau Salah. Mengubah bendera

perlindungan memori buffer yang diteruskan
ke perangkat yang diuji. Bendera perlindungan
memori bergantian antara tidak ada akses,
baca-saja, dan baca-saja dengan penjaga
halaman.
DoSimpleIO Benar atau Salah. Menjalankan SimpleI/O (jika

ditemukan) pada perangkat pengujian sebelum
dan sesudah melakukan operasi PNP.
DoConcurrentIO Benar atau Salah. Menggunakan antarmuka I/O

bersamaan WDTF untuk mengirim permintaan
I/O untuk menargetkan tumpukan perangkat
saat melakukan operasi PnP.
FillZeroPageWithNull Benar atau Salah. Peta halaman nol dan

mengisinya dengan nilai NULL. Tes ini
mengidentifikasi driver yang tidak
memverifikasi referensi penunjuk sebelum
menonaktifkan penunjuk.
FuzzTestPeriod Periode tes fuzz dalam hitungan menit.

Parameter Deskripsi
HPU Menentukan persentase pemanfaatan prosesor

yang tinggi.
Meniru Benar atau Salah. Menjalankan pengujian

sebagai pengguna tanpa hak istimewa
administrator.
IOPeriod Menentukan periode I/O dalam hitungan

menit.
IOType Menentukan jenis uji stres I/O:

SimpleIOStressEx atau SimpleIOStressProc (I/O
dalam proses terpisah).
LPU Menentukan persentase pemanfaatan prosesor

yang rendah
MaxInBuffer Menentukan ukuran maksimum, dalam byte,

dari buffer input yang diteruskan pengujian ke
driver di FSCTLs (atau IOCTLs untuk pengujian
IOCTL).
MinInBuffer Menentukan ukuran minimum, dalam byte, dari

buffer input yang diteruskan pengujian ke
IOCTL).
MaxOutBuffer Menentukan ukuran maksimum, dalam byte,

dari buffer output yang diteruskan pengujian
ke driver di FSCTLs (atau IOCTLs untuk
pengujian IOCTL).
MinOutBuffer Menentukan ukuran minimum, dalam byte, dari

buffer output yang diteruskan pengujian ke
IOCTL).
MaxRandomCalls Menentukan jumlah maksimum panggilan yang

dipermasalahkan pengujian.
Panggilan MaxTailored Menentukan jumlah maksimum panggilan yang

masalah pengujian selama tes acak yang
disesuaikan.
MaxDeviceType Menentukan nilai maksimum bidang

DeviceType di FSCTLs (atau IOCTLs untuk
pengujian IOCTL). Nilai maksimum yang
mungkin adalah 65535.
Parameter Deskripsi
MinDeviceType Menentukan nilai minimum bidang DeviceType

di FSCTLs (atau IOCTLs untuk pengujian IOCTL).
Nilai minimum yang mungkin adalah 0.
MaxFunctionCode Menentukan nilai maksimum bidang

FunctionCode di FSCTLs (atau IOCTLs untuk
pengujian IOCTL). Nilai maksimum yang
mungkin adalah 4095.
MinFunctionCode Menentukan nilai minimum bidang

FunctionCode di FSCTLs (atau IOCTLs untuk
pengujian IOCTL). Nilai minimum yang
mungkin adalah 0.
PU Menentukan persentase pemanfaatan prosesor
PingPongPeriod Menentukan periode ping pong dalam

hitungan menit; waktu prosesor bergantian
antara tingkat pemanfaatan prosesor tinggi
(HPU) dan rendah (LPU).
ResumeDelay Waktu tunda (dalam hitungan detik) setelah

mesin dilanjutkan dari mode tidur dan sebelum
siklus I /O berikutnya dimulai. Waktu
penundaan diperlukan untuk memungkinkan
perangkat memulihkan status kerja mereka
(memperbarui alamat IP untuk kartu jaringan
dan sebagainya).
TestCycles Menentukan jumlah siklus pengujian (iterasi)

untuk dilakukan.
WDTFREMOTESYSTEM Parameter ini hanya diperlukan jika perangkat

yang sedang diuji, atau salah satu perangkat
turunannya, adalah adaptor jaringan kabel yang
tidak memiliki alamat gateway IPv6. Jika
parameter ini diperlukan di jaringan Anda,
Anda harus memberikan alamat IPv6 yang
dapat di-ping adaptor jaringan uji untuk
menguji jaringan.
Contoh: fe80::78b6:810:9c12:46cd
Parameter Deskripsi
Wpa2PskAesSsid Parameter ini hanya diperlukan jika perangkat

yang sedang diuji atau salah satu perangkat
turunannya adalah adaptor WiFi. Berikan SSID
jaringan WiFi AES WPA2 yang dapat digunakan
pengujian untuk menguji adaptor WiFi.
Nilai default: kitstestssid
Wpa2PskPassword Parameter ini hanya diperlukan jika perangkat

yang sedang diuji atau salah satu perangkat
turunannya adalah adaptor WiFi. Berikan kata
sandi jaringan WiFi AES WPA2 yang ditentukan
dengan menggunakan parameter
Wpa2PskAesSsid.
Nilai default: kata sandi
Tes utilitas
Uji Deskripsi
Menampilkan perangkat yang memiliki plug-in Parameter: Tidak

WDTF Simple I/O
Menampilkan perangkat yang mengaktifkan Parameter: Tidak

Driver Verifier
Menampilkan perangkat Parameter: Tidak
Uji Deskripsi
Nonaktifkan Verifikasi Pengemudi Menonaktifkan Driver Verifier di komputer uji.
Parameter: Tidak
Aktifkan Verifikasi Driver Anda dapat menggunakan tes ini untuk

mengaktifkan Driver Verifier untuk semua driver
perangkat (atau perangkat) di komputer uji.
Parameter: - Lihat Opsi Verifikasi Pengemudi.
Topik terkait
Tes Fundamental Perangkat
Disediakan plug-in I/O Sederhana WDTF
Cara menyesuaikan I/O untuk perangkat Anda menggunakan WDTF Simple I/O
Action Plug-in
Cara menguji paket driver
Anda dapat menggunakan Visual Studio untuk menyebarkan dan menginstal paket
driver di komputer uji, lalu memverifikasi bahwa driver diinstal dan berjalan.
Prasyarat
Paket driver yang siap dipasang. Anda harus terlebih dahulu membuat dan
membangun driver Anda dan kemudian membuat paket driver untuk instalasi.
Untuk informasi selengkapnya, lihat Membuat Driver dan Membuat Paket Driver.
Jika Anda belum melakukannya, ikuti petunjuk untuk Menyediakan komputer
untuk penyebaran dan pengujian driver (WDK 8.1).
Setelah Mengonfigurasi dan menyediakan komputer uji, Anda dapat
menggunakan Visual Studio untuk menyebarkan driver, menjadwalkan pengujian,
dan men-debug driver di komputer uji. Untuk informasi tentang penyebaran dan
tentang bagaimana Anda dapat menyebarkan driver secara otomatis pada waktu
pembuatan, lihat Menyebarkan Driver ke Komputer Uji.
Instruksi
Langkah 1: Untuk menguji instalasi driver pada komputer

uji
Setelah Anda mengonfigurasi dan menyediakan komputer uji, Anda dapat
mengonfigurasi proyek paket driver sehingga secara otomatis disebarkan dan diinstal
pada komputer uji.
1. Buka halaman properti untuk proyek driver Anda. pilih dan tahan (atau klik kanan)
2. Di halaman properti untuk pengandar, pilih Properti Konfigurasi, pilih
3. Pilih opsi Aktifkan penyebaran . Untuk informasi selengkapnya, lihat Properti
Penyebaran untuk Proyek Driver.
4. Pilih komputer uji yang telah Anda konfigurasikan sebagai Komputer Jarak Jauh.
5. Di bawah Opsi Penginstalan Pengandar, pilih Instal dan Verifikasi, lalu pilih Tugas
Penginstalan Pengandar Default.
Topik terkait
Menyediakan komputer untuk penyebaran dan pengujian driver (WDK 8.1)
Menguji Driver
Cara membaca log hasil pengujian
driver
Dari Driver Test Group Explorer, Anda dapat menampilkan hasil dari pengujian driver,
menyimpan hasil pengujian ke folder, atau memuat hasil dari folder.
Buka hasil pengujian

1. Di jendela Driver Test Group Explorer , pilih Grup Uji Driver yang Anda minati.
2. Pilih hasil dari uji coba tertentu.
Hasil untuk grup pengujian ditampilkan sebagai folder berjudul Hasil

(computerdate-:time)
3. Hasil untuk pengujian dalam uji coba tersebut tercantum. Pilih nama pengujian
untuk melihat log hasil.
Log hasil menyediakan ringkasan pengujian yang dijalankan, bersama dengan detail
yang dihasilkan oleh kasus pengujian. Informasi yang direkam mencakup waktu dan
tanggal setiap pengujian dijalankan, nama komputer uji jarak jauh yang menjalankan
pengujian, dan hasil pengujian (jumlah pengujian yang dijalankan, lulus, gagal).
Menyimpan hasil pengujian ke folder
1. Di jendela Driver Test Group Explorer , pilih dan tahan (atau klik kanan) hasil dari
uji coba yang Anda minati.
2. Pilih Simpan untuk membuka kotak dialog untuk menyimpan hasilnya ke folder.
Cara menguji driver saat runtime dari
Command Prompt
WDK menyediakan komponen pengujian perangkat yang memungkinkan Anda menguji

driver pada komputer uji di jaringan Anda. Anda dapat menggunakan komponen ini di
luar Visual Studio dengan menyalin dan menginstal file yang diperlukan. Anda dapat
menggunakan komponen ini untuk menjalankan koleksi tes driver perangkat yang sama
yang tersedia di Visual Studio untuk menguji fitur dan fungsi driver Anda.
Mulai WDK 8.1, Anda dapat menyalin dan menjalankan HCK Test Suites di komputer uji
menggunakan skrip perintah. Lihat Cara menjalankan HCK Test Suites di WDK 8.1.
Prasyarat
Instal Visual Studio dan WDK di komputer yang Anda gunakan untuk
pengembangan.
Dari Visual Studio, Anda dapat mengonfigurasi dan menyediakan komputer untuk
pengujian. Saat Anda mengonfigurasi komputer uji, kerangka uji driver WDK
secara otomatis memungkinkan komputer uji untuk debugging jarak jauh dan
mentransfer binari uji dan file pendukung yang diperlukan. Jika Anda belum
melakukannya, ikuti petunjuk di Penyediaan komputer untuk penyebaran dan
pengujian driver (WDK 8.1)
Meskipun tidak disarankan, Anda juga dapat menginstal komponen pengujian
yang diperlukan secara manual. Ikuti petunjuk untuk menginstal Test Authoring
and Execution Framework (TAEF) dan WDTF di komputer uji. Lihat Menginstal dan
menghapus TAEF secara manual di komputer uji dan WDTF Quick Start.
Instruksi
Langkah 1: Salin tes ke komputer uji

Salin Tes Dasar Perangkat dari komputer yang Anda gunakan untuk
pengembangan. Salin folder %ProgramFiles%\Windows
Kits\8.0\Testing\Tests\Device Fundamentals ke komputer uji.
Langkah 2: Jalankan tes

Perintah TAEF untuk menjalankan tes menggunakan sintaks berikut:
C++
Te.exe [/name:<Test Method>] [<Test Name>.dll | <Test Name.wsc> ]

[/rebootStateFile=<file> ] [/enablewttlogging] [/P:"DQ= <>" ]
Keterangan
Anda harus menentukan file biner uji (.dll) atau skrip (.wsc). Metode pengujian (/name:
<test method>) bersifat opsional. Untuk nama pengujian dan metode pengujian, lihat
Tes Dasar Perangkat. Untuk informasi tentang menentukan parameter pengujian, lihat
Parameter Uji Fundamental Perangkat dan Opsi PerintahTe.exe .
Misalnya, untuk menjalankan semua tes PnP di Devfund_PnPDTest.dll pada perangkat

dengan ID perangkat tertentu.
C++
Te.exe Devfund_PnPDTest.dll /P:"DQ=DeviceID='USB\ROOT_HUB\4&1CD5D022&0'"
Misalnya, untuk menjalankan uji PnP Surprise Remove pada perangkat dengan ID
perangkat tertentu.
C++
Te.exe /name:"*PNPSurpriseRemoveAndRestartDevice" Devfund_PnPDTest.dll

/P:"DQ=DeviceID='USB\ROOT_HUB\4&1CD5D022&0'"
Topik terkait
Tes Fundamental Perangkat
Parameter Pengujian Fundamental Perangkat
Cara menjalankan HCK Test Suites di WDK 8.1
Kerangka Kerja Authoring dan Eksekusi Uji (TAEF)
Opsi PerintahTe.exe
Cara menulis tes driver menggunakan
templat Uji Driver
７ Catatan
Topik ini menjelaskan fungsionalitas yang hanya tersedia di Visual Studio 2013.
Untuk info tentang edisi WDK dan Visual Studio sebelumnya, lihat Unduhan WDK
lainnya.
Anda dapat menggunakan Windows Driver Kit (WDK) untuk Windows 8 membuat tes
driver Anda sendiri atau untuk menyesuaikan beberapa tes yang disediakan. Anda dapat
menyebarkan tes yang Anda buat ke komputer uji jarak jauh menggunakan kerangka
pengujian driver yang disediakan WDK untuk Microsoft Visual Studio Ultimate 2012.
WDK menyediakan templat yang membuat kode awal untuk proyek pengujian Driver
Windows dalam C++, C#, dan Script (Jscript). Anda dapat memilih kasus pengujian yang
ingin Anda sertakan, atau Anda dapat memulai dengan proyek kosong. Anda dapat
menyesuaikan kode untuk menambahkan kasus pengujian baru untuk driver Anda.
Anda dapat menyebarkan tes dari Visual Studio menggunakan kerangka kerja pengujian
driver.
Untuk menyesuaikan tes driver menggunakan

templat Uji Driver untuk C++
1. Dari menu File, pilih Project Baru>.
2. Dari daftar templat yang diinstal dalam kotak dialog Project Baru, pilih Tes Driver
> Windows Visual C+ > +.
3. Pilih Windows Driver Test di C++.
4. Berikan nama untuk proyek pengujian driver dan lokasi (atau gunakan default).
5. Dari kotak dialog Uji Driver Windows, pilih kasus pengujian yang ingin Anda
sertakan atau pilih tes driver kosong (kosong). Untuk informasi selengkapnya
tentang kasus pengujian, lihat Windows Kasus pengujian Driver.
6. Tambahkan metadata pengujian yang diperlukan. Untuk informasi selengkapnya,
lihat Cara menambahkan metadata pengujian.
7. Bangun tes driver Anda.
templat Uji Driver untuk C #
2. Dari daftar templat yang diinstal dalam kotak dialog Project Baru, pilih Visual C# >
Windows Driver .
3. Pilih Windows Driver Test di C#.
sertakan atau pilih tes driver kosong (kosong). Untuk informasi tentang kasus
pengujian, lihat Windows Kasus uji Pengemudi.

templat Uji Driver untuk Skrip
2. Dari daftar templat yang diinstal dalam kotak dialog Project Baru, pilih Skrip >
Windows Driver .
3. Pilih skrip Uji Driver Windows.
sertakan atau pilih tes driver kosong (kosong). Untuk informasi tentang kasus
pengujian, lihat Windows Kasus uji Pengemudi.
Membuat tes driver yang Anda buat tersedia

untuk penyebaran di komputer uji
Saat Anda membuat tes driver, tes baru akan tersedia untuk penyebaran ke komputer
uji. Secara default, tes yang Anda buat akan muncul di kategori tes Kategori Tes Saya.
Nama-nama tes didasarkan pada kasus uji yang Anda pilih, dan mereka akan memiliki
nama seperti My Plug and Play Surprise Remove Test. Selama setiap build tes, tes akan
ditimpa. Build terbaru dari tes akan tersedia untuk disebarkan dan dijalankan di
komputer uji.
Windows Kasus uji Pengemudi

WDK menyediakan kode awal untuk proyek uji Driver Windows di C ++, C #, dan Script.
Anda dapat memilih kasus pengujian yang ingin Anda sertakan, atau Anda dapat
memulai dengan proyek kosong. Tidak semua kasus tes tersedia dalam setiap bahasa.
Kasus Uji Plug and Play Kasus uji yang memaksa pengemudi untuk
menangani sebagian besar IRPs terkait Plug
and Play (PnP)
Nonaktifkan/Aktifkan Menyediakan kode untuk kasus pengujian yang

menonaktifkan dan mengaktifkan perangkat
PnP.
Hapus Menyediakan kode untuk kasus pengujian yang

menghapus perangkat PnP.
Hapus Kejutan Menyediakan kode untuk kasus pengujian yang

melakukan penghapusan perangkat PnP secara
mengejutkan.
Kasus Uji Manajemen Daya Menyediakan kasus uji yang memaksa

pengemudi untuk menangani keadaan tidur
sistem.
Keadaan Tidur Sistem Menyediakan kode untuk kasus uji yang

melakukan I /O perangkat saat sistem berputar
melalui keadaan tidur dan daya.
Kasus Uji Stres dan Fungsionalitas Menyediakan kasus pengujian yang melakukan
tegangan I /O dan pengujian fungsi antarmuka
IOCTL dan WMI.
Stres I/O Menyediakan kasus uji yang melakukan stres I

/O perangkat.
Antarmuka IOCTL Fungsional Menyediakan template untuk membuat kasus

uji fungsional untuk antarmuka IOCTL. (hanya
tersedia untuk C ++).
Antarmuka WMI Fungsional Menyediakan template untuk membuat kasus

uji fungsional untuk Windows Management
Interface (WMI). (hanya tersedia dalam Skrip)
Kasus Uji Kosong

Kasus Uji Plug and Play Kasus uji yang memaksa pengemudi untuk
menangani sebagian besar IRPs terkait Plug
and Play (PnP)
Menyediakan templat kosong untuk membuat

proyek pengujian Driver Windows.
Topik terkait
Kerangka Kerja Pengujian dan Eksekusi
Cara menambahkan metadata pengujian
Cara menambahkan metadata
pengujian
Untuk Windows 8, Windows Driver Kit (WDK) menggunakan Test Authoring and
Execution Framework (TAEF) untuk membuat konten pengujian. Tes TAEF adalah objek
yang diimplementasikan sebagai pustaka tautan dinamis (DLL) yang berisi beberapa
metode, di mana setiap metode memetakan ke skenario pengujian tertentu. Objek TAEF
menggabungkan metode terkait ke dalam sekelompok tes. Untuk setiap pengujian, ada
satu set metadata yang menjelaskan pengujian. Untuk meningkatkan portabilitas dan
enkapsulasi pengujian, TAEF menyimpan metadata uji dalam objek uji itu sendiri. Saat
Anda membuat tes driver Anda sendiri menggunakan templat Uji Driver, Anda perlu
menambahkan metadata ini sehingga pengujian driver Anda tersedia dan dapat
digunakan menggunakan Visual Studio.
Prasyarat
Kode sumber untuk tes driver ditulis dengan menggunakan salah satu templat Uji
Driver. Untuk informasi, lihat Cara menulis tes driver menggunakan templat Uji
Driver.
Untuk menambahkan atribut metadata uji

1. Tambahkan metadata properti uji yang diperlukan ke file sumber untuk pengujian
Anda.
2. Misalnya, jika Anda menggunakan templat Uji Driver untuk membuat versi tes
SurpriseRemove, metadata berikut akan ditambahkan. Edit deskripsi pengujian,
nama tampilan, kategori, dan atribut file hasil.
C++
C++
// Declare the test class method DoSurpriseRemove - the main test

method within this class
BEGIN_TEST_METHOD(DoSurpriseRemove)
// Required properties for driver tests
TEST_METHOD_PROPERTY(L"Kits.Drivers", L"TRUE")
TEST_METHOD_PROPERTY(L"Kits.Parameter", L"DQ")
TEST_METHOD_PROPERTY(L"Kits.Parameter.DQ.Description", L"A WDTF

SDEL query that is used to identify the target device(s) -
https://go.microsoft.com/fwlink/p/?linkid=232678")
TEST_METHOD_PROPERTY(L"Kits.Parameter.DQ.Default",
L"INF::OriginalInfFileName='%InfFileName%'")
TEST_METHOD_PROPERTY(L"RebootPossible", L"true")
// TODO: Required properties to be customized to match your test

requirements
TEST_METHOD_PROPERTY(L"Description", L"Plug and Play Surprise

Remove Generated Template")
TEST_METHOD_PROPERTY(L"Kits.DisplayName", L"My Plug and Play

Surprise Remove Test")
TEST_METHOD_PROPERTY(L"Kits.Category", L"My Test Category")
// Optional properties for driver tests
TEST_METHOD_PROPERTY(L"Kits.Drivers.ResultFile",
L"TestTextLog.log")
// TODO: (see Windows Driver Kit documentation for additional

optional properties)
END_TEST_METHOD()
C#
C#
//
// DoSurpriseRemove is a test method as identified by the

[TestMethod] tag.
// More methods can be added by following this basic pattern.
// The name of the function defines the name of the test.
//
[TestMethod]
// Required properties (see Windows Driver Kit documentation for

more information):
[TestProperty("Kits.Drivers", "TRUE")]
[TestProperty("Kits.Parameter", "DQ")]
[TestProperty("Kits.Parameter.DQ.Description", "A WDTF SDEL query

that is used to identify the target device(s) -
https://go.microsoft.com/fwlink/p/?linkid=232678")]
[TestProperty("Kits.Parameter.DQ.Default",
"INF::OriginalInfFileName='%InfFileName%'")]
// TODO: Required properties to be customized to match your test

requirements.
[TestProperty("Description", "Plug and Play Surprise Remove

Generated Template")]
[TestProperty("Kits.DisplayName", "My Plug and Play Surprise

Remove Test")]
[TestProperty("Kits.Category", "My Test Category")]
[TestProperty("RebootPossible", "true")]
// Optional properties (see Windows Driver Kit documentation for

additional optional properties):
[TestProperty("Kits.Drivers.ResultFile", "TestTextLog.log")]
Komponen Skrip Windows (.wsc)

<method name="PlugAndPlaySurpriseRemoveTest">

<TestMethodProperty name="Kits.Drivers" value="TRUE"/>
<TestMethodProperty name="Kits.Parameter" value="DQ"/>
<TestMethodProperty name="Kits.Parameter.DQ.Description" value="A

WDTF SDEL query that is used to identify the target device(s) -
https://go.microsoft.com/fwlink/p/?linkid=232678"/>
<TestMethodProperty name="Kits.Parameter.DQ.Default"
value="INF::OriginalInfFileName='%InfFileName%'"/>
<TestMethodProperty name="RebootPossible" value="true" />

<TestMethodProperty name="Description" value="Plug and Play

Surprise Remove Generated Template"/>
<TestMethodProperty name="Kits.DisplayName" value="My Plug and

Play Surprise Remove Test"/>
<TestMethodProperty name="Kits.Category" value="My Test

Category"/>

<TestMethodProperty name="Kits.Drivers.ResultFile"
value="TestTextLog.log"/>

</method>
3. Tabel berikut menjelaskan atribut properti uji. Gunakan contoh untuk panduan saat
Anda mengedit atau menambahkan metadata untuk pengujian Anda.
Deskripsi
Deskripsi singkat tentang apa yang dilakukan tes.
[Script]
< TestProperty name="Description" value= "This test cycles the

system through various sleep states and performs IO on devices before
and after each sleep state cycle"/>
C++
[C++]
TEST_METHOD_PROPERTY(L"Description", L"Plug and Play Surprise Remove Generated

Template")
Nama Tampilan
Nama tes seperti yang ditunjukkan dalam Driver Test.
[Naskah]
< TestProperty name="Kits.DisplayName" value="Sleep with IO Before and After"/>
C++
C++
[C++]
TEST_METHOD_PROPERTY(L"Kits.DisplayName", L"My Plug and Play Surprise Remove

Test")
Kits.Parameter
Parameter standar untuk panggilan metode. Tes dapat memiliki beberapa

parameter.
[Naskah]
<ModuleProperty name="Kits.Parameter" value="TM"/>
C++
[C++]
TEST_METHOD_PROPERTY(L"Kits.Parameter", L"DQ")
Kits.Parameter.<ParameterName>. Deskripsi
Deskripsi untuk parameter.
[Naskah]
< TestProperty name="Kits.Parameter.TM.Description" value="Test mode parameter:

Logo or Simple"/>
C++
[C++]
TEST_METHOD_PROPERTY(L"Kits.Parameter.DQ.Description", L"A WDTF SDEL query that

is used to identify the target device(s)")
Kits.Parameter.<ParameterName>. Default
Nilai default untuk parameter.
[Naskah]
< TestProperty name="Kits.Parameter.TM.Default" value="Logo"/>
C++
[C++]
TEST_METHOD_PROPERTY(L"Kits.Parameter.DQ.Default",
L"INF::OriginalInfFileName='%InfFileName%'")
Kit.Driver
Atribut ini menandai pengujian untuk dimasukkan dalam WDK.
[Naskah]
< TestProperty name="Kits.Drivers" value=""/>
C++
[C++]
TEST_METHOD_PROPERTY(L"Kits.Drivers", L"TRUE")
Kit.Kategori
Menjelaskan kategori tes.
[Naskah]
< TestProperty name="Kits.Category" value="Logo\Device Fundamentals"/>
C++
C++
[C++]
TEST_METHOD_PROPERTY(L"Kits.Category", L"My Test Category")
Deploymentitem
Mengidentifikasi file dan/atau folder sebagai dependensi pengujian. Ini mungkin

berisi sumber daya apa pun yang diperlukan untuk menjalankan pengujian. Untuk
informasi selengkapnya tentang menggunakan metadata ini, lihat Metadata
DeploymentItem.
Topik terkait
Cara menulis tes driver menggunakan templat Uji Driver
Masalah Umum Pemverifikasi Driver
Statis - Windows 10 Versi 1809
Halaman ini menjelaskan masalah umum yang mungkin Anda temui saat menggunakan
alat Static Driver Verifier (SDV) di Windows Driver Kit (WDK). Informasi di bawah ini
berkaitan secara khusus dengan versi alat yang dikirim dengan Pembaruan Windows 10
Oktober 2018 (Versi 1809).
Silakan lihat Masalah Yang Diketahui WDK untuk masalah SDV yang diketahui dengan
WDK resmi terbaru.
Kegagalan InterceptedBuild
Gejala utama: SDV gagal dengan FATAL ERROR: Unrecoverable error in
InterceptedBuild stage .
Saat memeriksa file DVL, Anda akan melihat AssessmentScore nilai dengan ScoreName="
[driverName].[architecture].SDV.NA.Reason" dan ScoreUnit="Unrecoverable error in
InterceptedBuild stage."
Untuk kegagalan InterceptedBuild, lakukan langkah-langkah berikut untuk

mendiagnosis masalah.
1. Jalankan ulang SDV dari Baris Perintah Alat Asli Visual Studio 2017 dengan bendera
/debug. Untuk detail tentang opsi perintah, lihat Perintah Pemverifikasi Driver
Statis.
a. Pertama, jalankan fungsi pustaka SDV pada proyek pustaka dependen apa pun.
Contoh: msbuild /p:Configuration=Release /p:Platform=x64 /t:sdv
/p:inputs="/lib /debug" .
b. Kemudian jalankan SDV pada proyek driver itu sendiri. Misalnya: msbuild
/p:Configuration=Release /p:Platform=x64 /t:sdv /p:inputs="/check /debug"
2. Konfirmasikan bahwa kegagalan kembali terjadi pada tahap InterceptedBuild.
3. Navigasi ke sdv folder yang dihasilkan di folder driver saat Anda menjalankan SDV.
4. Buka smvcl.log dan cari frasa "kesalahan kompilator internal".

a. Jika pesan kesalahan yang berisi kesalahan kompilator internal dan frasa yang
mirip dengan kesalahan fatal C1001: Kesalahan internal telah terjadi di
kompilator. (file kompilator 'msc1.cpp', baris 1511) ada, ini adalah masalah yang
diketahui yang membutuhkan errata (ID errata 40705). Jika Anda memerlukan
bantuan lebih lanjut, silakan email stlogohelp@microsoft.com.
b. Jika pesan kesalahan yang berisi kesalahan kompilator internal ada tetapi tidak
terlihat seperti di atas, ini kemungkinan akan memerlukan errata tetapi mungkin
bukan masalah yang diketahui yang ada. Email stlogohelp@microsoft.com.
c. Jika Anda tidak melihat baris yang berisi kesalahan kompilator internal, cari
baris apa pun yang dimulai dengan kesalahan. Ini mungkin atau mungkin bukan
masalah yang memerlukan errata. Email stlogohelp@microsoft.com.
5. Buka smvlink1.log dan cari kesalahan kompilator internal frasa.
a. Jika pesan kesalahan yang berisi kesalahan kompilator internal dan slamcl:
kesalahan: pada fase 2: kehabisan memori ada, ini adalah masalah umum yang
memerlukan errata.
b. Jika Anda tidak melihat baris yang berisi kesalahan kompilator internal, cari
baris apa pun yang dimulai dengan kesalahan. Ini mungkin atau mungkin bukan
masalah yang memerlukan errata. Email stlogohelp@microsoft.com.
c. Jika Anda tidak melihat salah satu hal di atas, hubungi MSFT untuk mendapatkan
dukungan.
Untuk menghubungi MSFT untuk mendapatkan dukungan, pastikan kode sumber tidak
dibagikan dengan menjalankan hal berikut:
1. Jalankan SDV dengan bendera /debug diaktifkan, dan pipa output ke file teks.
2. Navigasi ke sdv folder di direktori driver dan jalankan perintah berikut untuk
menghapus hasil build yang mungkin mengekspos sumber:
cmd
del /s *.obj
del /s *.rawcfg*
del /s *.li
del /s *.pdb
del /s *.sys
3. Kirim file berikut ke stlogohelp@microsoft.com:
a. File teks dengan output menjalankan SDV

b. File smexecute-NormalBuild.log
c. File smvexecute-InterceptedBuild.log
d. Subfolder "sdv"
Visual Studio runtime C++ 2013 tidak ada

Gejala utama: Saat menjalankan SDV pada sistem yang tidak memiliki runtime Visual
Studio C++ 2012 dan 2013, pengguna mungkin melihat kesalahan dalam kotak pop-up
seperti Eksekusi kode tidak dapat dilanjutkan karena [MSVCR110.dll atau VCOMP110.dll]
tidak ditemukan. Menginstal ulang program dapat memperbaiki masalah ini.
Dalam hal ini, solusinya adalah menginstal Visual C++ Redistributable x86 dan x64
untuk Visual Studio 2012 dan 2013.
Praktik terbaik: gunakan Visual Studio 2017

Versi 15.8
Secara default, analisis kode tidak secara otomatis membangun driver di Visual Studio
15.7. Jika driver bergantung pada biner yang dihasilkan, ini dapat menyebabkan
kegagalan di panel Output . Sebagai gantinya, sebaiknya gunakan versi 15.8 sebagai
gantinya.
Kegagalan pembuatan DVL setelah menghapus

konfigurasi dari proyek
Gejala utama: Setelah menghapus konfigurasi dari proyek melalui jendela Configuration
Manager, pengguna melihat pesan berikut saat memilih Buat Log Verifikasi
Driver: Please select a driver project. Driver Verification Log cannot be created
for the selected platform tool set: 'v100'"
Solusi sementara:
1. Cadangkan file proyek Anda, lalu buka file proyek di editor teks.
2. Di bawah bagian , \<PropertyGroup Label="Globals"\> temukan dua tag XML: satu

dengan format \<Configuration\>\[Configuration type\]\</Configuration\> dan
satu dengan format \<Platform Condition="'$(Platform)' == ''"\>\
[Architecture\]\</Platform\> , di mana \[Configuration type\] dan \
[Architecture\] merupakan konfigurasi dan rilis default untuk jenis proyek ini.
3. Perbarui \[Configuration type\] dan \[Architecture\] ke nilai yang sesuai untuk

proyek Anda. Misalnya, jika Anda menghapus platform Win32, Anda dapat
memperbarui \[Architecture\] ke x64 sebagai gantinya.
Solusi alternatif:
1. Buka Perintah Alat Asli Visual Studio 2017.
2. Navigasi ke folder driver.
3. Jalankan msbuild [Your Project] /p:Configuration=[Configuration type]

/p:Platform=[Architecture] /t:dvl , di mana \[Your Project\] adalah file vcxproj,
\[Configuration type\] adalah konfigurasi yang valid seperti Rilis, dan \
[Architecture\] merupakan arsitektur yang valid seperti x64.
Pembuatan DVL tidak berfungsi di ServerCore,

gunakan GUI Server
Pengujian Logo Static Tools gagal saat dijalankan. Meninjau log pengujian menunjukkan
kegagalan yang mirip dengan Failed to load
'C:\hlk\JobsWorkingDir\Tasks\WTTJobRun4749E809-0166-E811-8368-
F4521454FFE1\Devfund_DvlTest.dll'. (Could not load managed test module because

RoMetadata.dll could not be found)
Pastikan paket TAEF disebarkan atau RoMetadata.dll disebarkan ke lokasi dalam variabel
lingkungan PATH Anda.
Gejala utama adalah kegagalan memuat RoMetadata.dll.
Jika Anda memiliki penginstalan GUI Server dengan arsitektur dan versi Windows yang
sama dengan penginstalan ServerCore Anda, salin file RoMetadata.dll dari GUI Server ke
ServerCore. DLL dapat ditemukan di folder System32 (misalnya, C:\Windows\System32 )
dan harus ditempatkan di folder yang sama pada komputer ServerCore. Ini harus
mengaktifkan pengujian untuk berjalan di ServerCore. Jika Anda masih mengalami
masalah, silakan lihat solusi berikutnya.
Solusi kedua adalah menjalankan pada GUI Server dan kemudian menggabungkan
paket dengan paket yang berisi hasil dari Server Core. Untuk informasi tentang
menggabungkan paket, lihat Menggabungkan paket.
Pemverifikasi Driver Statis gagal dengan keluar
dari lib.exe/iwrap.exe dengan kesalahan
0xc0000142
File smvbuild.log berisi pesan yang mirip dengan kesalahan ini:
c:\Program Files\Microsoft Visual

Studio\2017\BuildTools\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(
1144,5): error MSB6006: "Lib.exe" exited with code -1073741502.
Done executing task "LIB" -- FAILED.
Ini adalah masalah yang sudah diketahui. Jika masalah ini memblokir sertifikasi WHCP
Anda, silakan gunakan errata 41600.
Membuat Log Verifikasi Driver
Program tertentu dari Program Sertifikasi Perangkat Keras Windows memerlukan Log
Verifikasi Driver (DVL) untuk semua pengiriman driver. DVL berisi ringkasan hasil dari file
log Code Analysis (CA), Static Driver Verifier (SDV), dan CodeQL . DVL tidak berisi
informasi sumber apa pun. Anda harus menjalankan alat Analisis Kode dan Pemverifikasi
Driver Statis sebelum membuat DVL untuk driver Anda.
Untuk membuat log verifikasi driver
1. Sebelum menjalankan alat Analisis Kode, pastikan Anda dapat membangun dan
menautkan driver Anda menggunakan Windows Driver Kit (WDK) terbaru.
2. Untuk Solusi Driver, pastikan Anda telah memilih konfigurasi Rilis sebagai
Konfigurasi Solusi dan x64 sebagai Platform Solusi.
3. Jalankan Pemverifikasi Driver Statis. Untuk informasi tentang membuat file log,
lihat Membuat file log untuk Pemverifikasi Driver Statis dan Menggunakan
Pemverifikasi Driver Statis untuk menemukan cacat pada driver.
4. Jalankan alat Analisis Kode untuk driver. Atasi dan perbaiki cacat yang ditemukan.
Lihat Membuat file log untuk alat analisis kode dan Cara menjalankan Analisis
Kode untuk Driver. Untuk informasi selengkapnya tentang analisis kode, lihat
Menganalisis Kualitas Kode C/C++ dengan Menggunakan Analisis Kode.
5. Jalankan CodeQL. Alamat dan perbaiki cacat yang ditemukan. Sertifikasi akan gagal
jika cacat yang dianggap "Harus Diperbaiki" tidak diperbaiki. Untuk informasi
selengkapnya tentang CodeQL dan Static Tools Logo Test, lihat CodeQL dan Static
Tools Logo Test.
6. Buat Log Verifikasi Driver. Dari menu Driver , pilih Buat Log Verifikasi Driver... .
7. Verifikasi bahwa file Log Analisis Kode, Log Pemverifikasi Driver Statis, dan Log
CodeQL terdeteksi. Pilih Buat.
Log verifikasi driver memiliki ekstensi nama file .DVL.XML. Log dibuat di folder proyek,
misalnya, \myDriverProject\myDriverName.DVL.XML.
Catatan SDV melakukan pembangunan kembali driver yang bersih, yang menghapus
log Analisis Kode. Dengan demikian, pastikan untuk menjalankan SDV sebelum
menjalankan CA.
Catatan Ketika Anda siap untuk menguji driver Anda menggunakan Windows Hardware
Lab Kit, Anda perlu menyalin log verifikasi driver ke direktori %systemdrive%\DVL pada
komputer uji. Pastikan untuk menghapus isi direktori pada komputer uji sebelum Anda
menyalin log verifikasi driver baru.
Komentar
Untuk informasi terbaru tentang alat Analisis Kode, Pemverifikasi Driver Statis, dan Log
Verifikasi Driver, lihat Catatan Rilis WDK. Catatan Rilis tersedia di halaman unduhan
Windows Driver Kit (WDK).
Penting Batas waktu, spasi, dan hasil lain yang tidak berhasil dalam file DVL dapat
diterima untuk pengiriman sertifikasi. Ini tidak akan menyebabkan pengujian Alat Statis
di HLK gagal.
Anda juga dapat membuat log verifikasi driver dari jendela Prompt Perintah Visual
Studio, baik oleh Prompt Perintah Alat Asli Visual Studio yang diinstal dengan Visual
Studio atau melalui Enterprise Windows Driver Kit (EWDK):
C++
msbuild.exe <vcxprojectfile> /target:dvl /p:Configuration="Release"

/P:Platform=x64
Membuat Log Verifikasi Driver Di Luar msbuild

atau Visual Studio
Microsoft mengirimkan sebagai bagian dari Windows Driver Kit (WDK) dan Enterprise
WDK (eWDK) komponen yang disebut dvl.exe yang dapat digunakan untuk
menghasilkan Log Verifikasi Driver (DLL) melalui baris perintah. Mulai dari pratinjau
WDK/eWDK versi 21342 ke atas, dimungkinkan untuk menghasilkan DVL dari baris
perintah di luar konteks msbuild atau Visual Studio. Ikuti langkah-langkah di bawah ini
untuk membuat DVL melalui baris perintah:
1. Tempatkan hasil yang harus dikonsumsi untuk membuat DVL dalam satu direktori,
bersama dengan file vcxproj apa pun. Biasanya untuk driver yang dimaksudkan
untuk disertifikasi untuk Klien Windows, ini adalah file CodeQL SARIF. Untuk
sertifikasi Windows Server, ini mungkin juga mencakup file hasil Analisis Kode dan
Pengverifikasi Driver Statis (SDV). Periksa dokumen persyaratan WHCP untuk detail
spesifik tentang alat mana yang harus dijalankan untuk sertifikasi driver perangkat.
2. File CodeQL SARIF dan file XML Analisis Kode harus ditempatkan di tingkat atas
direktori. File DVL.xml SDV harus ditempatkan dalam subfolder "sdv".
3. Dari baris perintah, navigasikan ke direktori tingkat atas yang berisi file CodeQL
SARIF.
4. Temukan dvl.exe dari WDK atau eWDK yang dipasang.
5. Panggil dvl.exe dengan meneruskan bendera /manualCreate, nama driver, dan
arsitektur yang diinginkan. Contohnya:
cmd
"C:\Program Files (x86)\Windows Kits\10\Tools\dvl\dvl.exe" /manualCreate

driverName driverArchitecture
Salah satu string berikut harus digunakan untuk string driverArchitecture Anda:
X86
X64
Lengan
Arm64
Jangan sertakan ".sys" sebagai bagian dari string driverName Anda
6. Periksa DVL yang dihasilkan untuk memastikan bahwa DVL dihasilkan dengan
benar
Penggunaan ini terutama ditujukan untuk menghasilkan DLL dengan hasil CodeQL,
tetapi juga dapat digunakan untuk hasil SDV dan CA.
Topik terkait
Membuat file log untuk Pemverifikasi Driver Statis
Membuat file log untuk alat analisis kode
Menganalisis Kualitas Driver dengan Menggunakan Alat Analisis Kode
Menggunakan Pemverifikasi Driver Statis untuk menemukan cacat pada driver
CodeQL dan Uji Logo Alat Statis
Membuat file log untuk alat analisis
kode
Program Sertifikasi Perangkat Keras Windows Server 2012 memerlukan Log Verifikasi
Driver (DVL) untuk semua pengiriman driver yang berlaku. Anda harus menjalankan alat
Analisis Kode sebelum membuat DVL untuk driver Anda. DVL berisi ringkasan hasil dari
Analisis Kode dan file log Verifier Driver Statis. File log tidak berisi informasi kode
sumber.
Untuk menjalankan analisis kode pada driver
1. Di Microsoft Visual Studio Ultimate 2012, pilih file proyek driver lalu pilih dan tahan
(atau klik kanan) untuk membuka properti proyek. Pilih Windows 8 Rilis sebagai
Konfigurasi dan x64 sebagai Platform.
2. Dari menu Analisis atau Bangun , pilih Jalankan Analisis Kode pada Solusi.
3. Jika ditemukan kesalahan atau peringatan, gunakan jendela Laporan Analisis Kode
untuk menyelidiki penyebab kesalahan. Gunakan pesan peringatan untuk
memperbaiki masalah tersebut. Untuk informasi selengkapnya tentang alat Analisis
Kode, lihat Cara menjalankan Analisis Kode untuk driver dan Menganalisis Kualitas
Kode C/C++ dengan Menggunakan Analisis Kode.
Alat Analisis Kode untuk driver menulis hasil ke file vc.nativecodeanalysis.all.xml dalam
konfigurasi build dan sub-direktori platform proyek Anda, misalnya, \Windows
8Release\x64.
Komentar
Analisis Kode untuk Driver adalah alat verifikasi statis waktu kompilasi yang mendeteksi
kesalahan pengkodean dasar dalam program C dan C ++ dan mencakup modul khusus
yang dirancang untuk mendeteksi kesalahan dalam (terutama) kode driver mode kernel.
Dalam versi WDK sebelumnya, modul khusus driver untuk analisis kode adalah bagian
dari alat yang berdiri sendiri yang disebut PREfast for Drivers (PFD).
Anda juga dapat menjalankan alat Analisis Kode dari jendela Command Prompt Visual
Studio. Siapkan lingkungan dengan menjalankan salah satu file batch berikut.
C++
"C:\Program Files\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x64
-Atau-
C++
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x64
Jalankan alat Analisis Kode.
C++
msbuild.exe <vcxprojectfile> /p:Configuration="Win8 Release" /P:Platform=x64

/target:clean
msbuild.exe <vcxprojectfile> /p:Configuration="Win8 Release" /P:Platform=x64

/P:RunCodeAnalysisOnce=True
Untuk informasi terbaru tentang persyaratan untuk Log Verifikasi Driver, lihat Catatan
Rilis WDK.
Topik terkait
Membuat log verifikasi driver
Membuat file log untuk Static Driver Verifier
Analisis Kode untuk Driver
Menganalisis Kualitas Kode C/C++ dengan Menggunakan Analisis Kode
Membuat file log untuk Static Driver
Verifier
Program Sertifikasi Perangkat Keras Windows Server 2012 memerlukan Log Verifikasi
Driver (DVL) untuk semua pengiriman driver yang berlaku. Anda harus menjalankan
Static Driver Verifier (SDV) sebelum membuat DVL untuk driver Anda. DVL berisi
ringkasan hasil dari Analisis Kode dan file log Verifier Driver Statis. File log tidak berisi
informasi kode sumber.
Untuk hasil terbaik, jalankan alat Analisis Kode sebelum Anda menjalankan Static Driver
Verifier.
Membuat file log

1. Di Microsoft Visual Studio Ultimate 2012, pilih file proyek driver lalu pilih dan tahan
(atau klik kanan) untuk membuka properti proyek. Pilih Windows 8 Rilis sebagai
Konfigurasi dan x64 sebagai Platform.
2. Jika Anda telah menjalankan alat Analisis Kode, ikuti petunjuk ini untuk
menjalankan Static Driver Verifier. Untuk informasi selengkapnya tentang
menggunakan SDV, lihat Menggunakan Static Driver Verifier untuk Menemukan
Cacat pada Driver
3. Jika SDV menemukan cacat pada driver Anda, pilih cacat di panel Hasil untuk
melihat jejak jalur kode yang menyebabkan pelanggaran aturan. Perbaiki cacat
yang ditemukan di pengemudi dan jalankan SDV lagi.
Static Driver Verifier menulis hasilnya ke file SDV.DVL.xml di sub-direktori SDV proyek
Anda, misalnya, \myDriverProject\SDV.
Keterangan
Untuk informasi terbaru tentang Static Driver Verifier dan Log Verifikasi Driver, lihat
Catatan Rilis WDK. Catatan Rilis tersedia di halaman unduhan Windows Driver Kit
(WDK ).
） Penting
Batas waktu, spaceout, dan hasil tidak berhasil lainnya dalam file DVL dapat
diterima untuk pengajuan sertifikasi. Ini tidak akan menyebabkan pengujian Alat
Statis di HCK gagal. Untuk HCK 2.0, Static Tools Test hanya memerlukan kehadiran
file DVL untuk menunjukkan Analisis Kode dan SDV telah dijalankan, dan tidak
memerlukan semua aturan untuk lulus.
Anda juga dapat menjalankan Static Driver Verifier dari jendela Command Prompt Visual
Studio. Siapkan lingkungan dengan menjalankan salah satu file batch berikut.
C++
"C:\Program Files\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x64
-Atau-
C++
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x64
Jalankan Verifikasi Driver Statis.
C++
msbuild.exe <vcxprojectfile> /p:Configuration="Win8 Release" /p:Platform=x64

/target:sdv /p:inputs="/clean"
msbuild.exe <vcxprojectfile> /p:Configuration="Win8 Release" /p:Platform=x64

/target:sdv /p:inputs="/check:default.sdv"
Topik terkait
Membuat log verifikasi driver
Verifikator Driver Statis
Menggunakan Verifier Driver Statis untuk Menemukan Cacat pada Driver
Mendistribusikan paket driver
Topik ini menjelaskan cara mendistribusikan paket driver Anda dengan aman. Informasi
ini mencakup cara mendistribusikan paket driver melalui program Microsoft Windows
Update. Topik ini juga menjelaskan bagaimana Windows melindungi file sistem.
Windows Update
Paket driver yang lulus pengujian Windows Hardware Certification Kit (HCK) dapat
ditandatangani secara digital oleh WHQL. Jika paket driver Anda ditandatangani
secara digital oleh WHQL, paket tersebut dapat didistribusikan melalui program
Windows Update atau mekanisme distribusi lain yang didukung Microsoft.
Mendapatkan tanda tangan rilis WHQL adalah bagian dari Windows Hardware
Certification Kit (HCK). Tanda tangan rilis WHQL terdiri dari file katalog yang
ditandatangani secara digital. Tanda tangan digital tidak mengubah file biner driver atau
file INF yang Anda kirimkan untuk pengujian.
Anda dapat mendistribusikan paket driver melalui program Windows Update jika paket
driver:
Lulus program pengujian WHQL dan menerima tanda tangan rilis WHQL.
Memenuhi syarat untuk Program Sertifikasi Windows.
Memenuhi persyaratan tambahan yang memastikan bahwa Windows Update

dapat menentukan paket driver yang benar untuk perangkat pengguna, dapat
mendistribusikannya secara legal, dan dapat mengunduhnya secara otomatis.
Karena persyaratan program Windows Update sering diperbarui, Anda harus secara
teratur memeriksa situs web penerbitan driver Windows Update.
Perlindungan untuk File Sistem

Windows File Protection (WFP) melindungi file sistem operasi Windows diganti dengan
versi yang tidak diketahui atau tidak kompatibel.
WFP mencegah program mengganti file sistem Windows kritis. Program tidak boleh
menimpa file-file ini karena mereka digunakan oleh sistem operasi dan oleh program
lain. Melindungi file-file ini mencegah masalah dengan program dan sistem operasi.
Jenis file sistem yang dilindungi WFP termasuk file .sys, .exe, .ocx, dan .dll yang
dikirimkan "di dalam kotak" dengan sistem operasi.
Selama pengujian WHQL, program Signability memeriksa file INF pengemudi untuk
memastikan bahwa itu tidak mencoba untuk mengganti file sistem. Paket driver yang
mencoba mengganti file sistem tidak dapat menerima tanda tangan digital. Paket driver
dapat, bagaimanapun, berisi versi terbaru dari file yang vendor disediakan ke Microsoft
untuk kapal dengan Windows tahun 2000 atau lebih baru dari sistem operasi.
Untuk informasi tambahan tentang Windows Perlindungan File, lihat dokumentasi SDK
Windows.

Windows Hardware Drivers Develop

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Windows Hardware Drivers Develop

Diunggah oleh

Hak Cipta:

Format Tersedia

Beri tahu kami tentang pengalaman mengunduh PDF.

Mengembangkan, Menguji, dan

Lingkungan pengembangan driver Windows dan debugger Windows diintegrasikan ke

Untuk mengatur lingkungan pengembangan terintegrasi, pertama instal Visual Studio

WDK menggunakan MSBuild.exe, yang tersedia baik di antarmuka pengguna Visual

Lingkungan Visual Studio menyediakan templat untuk:

Di lingkungan Visual Studio, Anda dapat mengonfigurasi proses pembuatan sehingga

Menggunakan Windows Performance Toolkit (WPT) dengan WDF

Persyaratan tambahan berikut berlaku untuk Driver Windows:

Mematuhi Prinsip Desain DCH.

Tabel berikut ini meringkas perbedaan antara dua klasifikasi:

Fitur Driver Driver Desktop

Berjalan di Windows Desktop Ya Ya

Berjalan pada varian non-Desktop Windows Ya Tidak

Harus disertifikasi dengan WHCP Ya Tidak

WDK & HLK adalah kendaraan utama untuk mengembangkan Ya Ya

Mematuhi persyaratan keandalan dan layanan yang lebih ketat Ya Tidak

Prinsip Desain DCH

Aplikasi Dukungan Perangkat Keras (H): Setiap komponen antarmuka pengguna

Driver yang sesuai dengan DCH terdiri dari bagian-bagian berikut:

Buat file INF untuk driver Anda:

1. Buka properti proyek driver.

Di bagian INF DestinationDirs, atur direktori tujuan ke dirid 13 untuk membuat

Driver yang tidak terisolasi Driver terisolasi

Berinteraksi dengan tumpukan/driver Berinteraksi dengan tumpukan/driver perangkat

Jalankan dari penyimpanan driver

Status membaca dan menulis

Jika komponen Anda menggunakan properti antarmuka perangkat atau perangkat

Bagian ini berisi subbagian berikut:

Status registri perangkat PnP

Status registri antarmuka perangkat

Status registri layanan

Status registri perangkat PnP

WdfDeviceOpenRegistryKey, WdfFdoInitOpenRegistryKey (WDF)

CM_Open_DevNode_Key (kode mode pengguna)

Status registri antarmuka perangkat

CM_Open_Device_Interface_Key (kode mode pengguna)

Status registri layanan

Status registri layanan yang tidak dapat diubah

Status registri layanan internal

Status registri layanan yang tidak dapat diubah

Addservice = ExampleService, 0x2, Example_Service_Inst

HKR, Parameters, ExampleValue, 0x00010001, 1

IoOpenDriverRegistryKey (WDM) dengan DRIVER_REGKEY_TYPE

GetServiceRegistryStateKey (Layanan Win32) dengan

Status registri layanan internal

IoOpenDriverRegistryKey (WDM) dengan DRIVER_REGKEY_TYPE

GetServiceRegistryStateKey (Layanan Win32) dengan

Status registri layanan bersama

IoOpenDriverRegistryKey (WDM) dengan DRIVER_REGKEY_TYPE

GetSharedServiceRegistryStateKey (Win32 Services) dengan

Status file perangkat

Status file layanan

IoGetDeviceDirectory (WDM) dengan parameter DirectoryType diatur ke

Status file layanan

Status file layanan yang tidak dapat diubah

Status file layanan internal

Status file layanan bersama

Status file layanan yang tidak dapat diubah

Status file layanan internal

IoGetDriverDirectory (WDM, KMDF) dengan parameter DirectoryType diatur ke

GetServiceDirectory (Win32 Services) dengan parameter eDirectoryType diatur ke

Status file layanan bersama

IoGetDriverDirectory (WDM, KMDF) dengan parameter DirectoryType diatur ke