!verifier
!verifier 扩展显示驱动程序验证程序的状态及其操作。
驱动程序验证程序包含在 Windows 中。 它既适用于校验过的版本，也适用于免费内部版本。 有关驱动程序验证程序的信息，请参阅驱动程序验证程序。
语法
!verifier [Flags [Image]]
!verifier 4 [Quantity]
!verifier 8 [Quantity]
!verifier 0x40 [Quantity]
!verifier 0x80 [Quantity]
!verifier 0x80 Address
!verifier 0x100 [Quantity]
!verifier 0x100 Address
!verifier 0x200 [Address]
!verifier 0x400 [Address]
!verifier -disable
!verifier ?
参数
标记
指定在此命令的输出中显示哪些信息。 如果 Flags 的值等于 4、8、0x20、0x40、0x80 或 0x100，则 !verifier 的其余参数将根据与这些值相关的特定参数进行解释。 如果 Flags 等于任何其他值，即使设置了其中一个或多个位，也只允许使用 Flags 和 Image 参数。 Flags 可以是以下任意位的总和；默认值为 0：
位 0（0x1）
显示正在验证的所有驱动程序的名称。 还将显示当前从非分页池和分页池分配给每个驱动程序的字节数。
位 1（0x2）
显示有关池（池大小、标头和池标记）以及已卸载驱动程序留下的未完成内存分配的信息。 除非还设置了位 0 (0x1)，否则此标志不起作用。
位 2（0x4）
显示故障注入信息。 将显示请求每个分配的代码的返回地址、符号名称和位移。 如果 Flags 恰好为 0x4，并且包含 Quantity 参数，则可以选择显示这些记录的数量。 否则，将显示四条记录。
位 3（0x8）
显示正在验证的驱动程序所做的最新 IRQL 更改。 将显示旧的 IRQL、新的 IRQL、处理器和时间戳。 如果 Flags 恰好为 0x8，并且包含 Quantity 参数，则可以选择显示这些记录的数量。 否则，将显示四条记录。
警告 在 64 位版本的 Windows 中，某些提高或降低 IRQL 的内核函数是以内联代码而不是导出函数的形式实现的。 驱动程序验证程序不会报告内联代码所做的 IRQL 更改，因此驱动程序验证程序生成的 IRQL 转换日志可能不完整。 有关缺少 IRQL 转换条目的示例，请参阅“备注”。
位 6 (0x40)
（Windows Vista 及更高版本）显示驱动程序验证程序“强制挂起 I/O 请求”选项中的信息，包括来自强制挂起 IRP 日志的跟踪。
Quantity 参数指定要显示的跟踪数。 默认情况下，将显示整个日志。
位 7 (0x80)
（Windows Vista 及更高版本）显示内核池“分配/空闲”日志中的信息。
Quantity 参数指定要显示的跟踪数。 默认情况下，将显示整个日志。
如果指定了 Address，则只显示内核池“分配/空闲”日志中与指定地址相关的跟踪。
位 8 (0x100)
（Windows Vista 及更高版本）显示 IoAllocateIrp、IoCompleteRequest 和 IoCancelIrp 调用日志中的信息。
Quantity 参数指定要显示的跟踪数。 默认情况下，将显示整个日志。
如果指定了 Address，则只显示与指定 IRP 地址相关的跟踪。
位 9 (0x200)
（Windows Vista 及更高版本）显示“关键区域”日志中的条目。
如果指定了 Address，则只显示与指定线程地址相关的条目。
位 10 (0x400)
（Windows Vista 及更高版本）显示驱动程序验证程序当前正在监视的已取消 IRP。
如果指定了 Address，则仅显示指定地址的 IRP。
位 11 (0x800)
（Windows 8.1 及更高版本）显示在选择“系统低资源模拟”选项时创建的故障注入日志中的条目。
图像
如果使用 Flags 且不等于 4、8 或 0x10，则 Image 将指定驱动程序的名称。 Image 用于筛选 Flags 值为 0x1 和 0x2 时显示的信息：只考虑指定的驱动程序。 此驱动程序当前必须通过验证。
数量
如果 Flags 恰好等于 0x4，则 Quantity 将指定要显示的故障注入记录数。 如果 Flags 恰好等于 0x8，则 Quantity 将指定要显示的 IRQL 日志条目数。 如果 Flags 恰好等于 0x40，则 Quantity 将指定从强制挂起 IRP 日志中显示的跟踪数。 如果 Flags 恰好等于 0x80，则 Quantity 指定从内核池“分配/空闲”日志中显示的跟踪数。 如果 Flags 恰好等于 0x100，则 Quantity 将指定从 IoAllocateIrp、IoCompleteRequest 和 IoCancelIrp 调用日志中显示的跟踪数。
-disable
清除调试目标上当前的驱动程序验证程序设置。 这些设置的清除不会持续到重启。 如果需要禁用驱动程序验证程序设置才能成功启动，请在 nt!VerifierInitSystem 处设置断点，并在该点使用 !verifier -disable 命令。
?
在“调试器命令”窗口中显示此扩展的一些简短帮助文本。
DLL
Kdexts.dll
其他信息
有关详细信息，请参阅驱动程序验证程序。
注解
下面的示例说明，在 64 位版本的 Windows 中，IRQL 转换日志并不总是完整的。 显示的两个条目是处理器 2 日志中的连续条目。 第一个条目显示 IRQL 从 2 转换为 0。 第二个条目显示 IRQL 从 2 转换为 2。 缺少有关 IRQL 如何从 0 升至 2 的信息。
Thread: fffffa80068c9400
Old irql: 0000000000000002
New irql: 0000000000000000
Processor: 0000000000000002
Time stamp: 0000000000000857
fffff8800140f12a ndis!ndisNsiGetInterfaceInformation+0x20a
fffff88001509478 NETIO!NsiGetParameterEx+0x178
fffff88005f062f2 nsiproxy!NsippGetParameter+0x24a
fffff88005f086db nsiproxy!NsippDispatchDeviceControl+0xa3
fffff88005f087a0 nsiproxy!NsippDispatch+0x48
Thread: fffffa80068c9400
Old irql: 0000000000000002
New irql: 0000000000000002
Processor: 0000000000000002
Time stamp: 0000000000000857
fffff8800140d48d ndis!ndisReferenceTopMiniportByNameForNsi+0x1ce
fffff8800140f072 ndis!ndisNsiGetInterfaceInformation+0x152
fffff88001509478 NETIO!NsiGetParameterEx+0x178
fffff88005f062f2 nsiproxy!NsippGetParameter+0x24a
fffff88005f086db nsiproxy!NsippDispatchDeviceControl+0xa3
4、8 和 0x20、0x40、0x80 和 0x100 是 Flags 的特殊值。 如果使用了这些值，就可以使用 Parameters 部分列出的特殊参数，而且显示内容将只包括与该标志值相关的信息。
如果使用 Flags 的任何其他值，即使设置了其中一个或多个位，也只允许使用 Flags 和 Image 参数。 在这种情况下，除了显示所有其他信息外，!verifier 还会显示处于活动状态的驱动程序验证程序选项，以及池分配、IRQL 提升、自旋锁和裁剪等统计信息。
如果 Flags 等于 0x20，驱动程序验证器的驱动程序挂起验证选项将使用为 CompletionTime、CancelTime 和 ForceCancellation 指定的值。 这些新值将立即生效，并持续到下一次启动。 重新启动后，它们将恢复为默认值。
此外，如果 Flags 等于0x20（无论有无其他参数），则会打印驱动程序挂起验证日志。 有关解释日志的信息，请参阅 Windows 驱动程序工具包 (WDK) 文档中驱动程序验证程序文档的驱动程序挂起验证部分。
下面是 Windows 7 计算机上 !verifier 扩展的示例。
2: kd> !verifier 0xf
Verify Level 9bb ... enabled options are:
Special pool
Special irql
All pool allocations checked on unload
Io subsystem checking enabled
Deadlock detection enabled
DMA checking enabled
Security checks enabled
Miscellaneous checks enabled
Summary of All Verifier Statistics
RaiseIrqls 0x0
AcquireSpinLocks 0x362
Synch Executions 0x0
Trims 0xa34a
Pool Allocations Attempted 0x7b058
Pool Allocations Succeeded 0x7b058
Pool Allocations Succeeded SpecialPool 0x7b058
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0
Current paged pool allocations 0x1a for 00000950 bytes
Peak paged pool allocations 0x1b for 00000AC4 bytes
Current nonpaged pool allocations 0xe3 for 00046110 bytes
Peak nonpaged pool allocations 0x10f for 00048E40 bytes
Driver Verification List
Entry State NonPagedPool PagedPool Module
fffffa8003b6f670 Loaded 000000a0 00000854 videoprt.sys
Current Pool Allocations 00000002 00000013
Current Pool Bytes 000000a0 00000854
Peak Pool Allocations 00000006 00000014
Peak Pool Bytes 000008c0 000009c8
PoolAddress SizeInBytes Tag CallersAddress
fffff9800157efc0 0x0000003c Vprt fffff88002c62963
fffff9800146afc0 0x00000034 Vprt fffff88002c62963
fffff980015bafe0 0x00000018 Vprt fffff88002c628f7
...
fffffa8003b6f620 Loaded 00046070 000000fc usbport.sys
Current Pool Allocations 000000e1 00000007
Current Pool Bytes 00046070 000000fc
Peak Pool Allocations 0000010d 0000000a
Peak Pool Bytes 00048da0 00000254
PoolAddress SizeInBytes Tag CallersAddress
fffff98003a38fc0 0x00000038 usbp fffff88004215e34
fffff98003a2cfc0 0x00000038 usbp fffff88004215e34
fffff9800415efc0 0x00000038 usbp fffff88004215e34
...
-----------------------------------------------
Fault injection trace log
-----------------------------------------------
Driver Verifier didn't inject any faults.
-----------------------------------------------
Track irql trace log
-----------------------------------------------
Displaying most recent 0x0000000000000004 entries from the IRQL transition log.
There are up to 0x100 entries in the log.
Thread: fffff80002bf8c40
Old irql: 0000000000000002
New irql: 0000000000000002
Processor: 0000000000000000
Time stamp: 000000000000495e
fffff8800420f2ca USBPORT!USBPORT_DM_IoTimerDpc+0x9a
fffff80002a5b5bf nt!IopTimerDispatch+0x132
fffff80002a7c29e nt!KiProcessTimerDpcTable+0x66
fffff80002a7bdd6 nt!KiProcessExpiredTimerList+0xc6
fffff80002a7c4be nt!KiTimerExpiration+0x1be
Thread: fffff80002bf8c40
Old irql: 0000000000000002
New irql: 0000000000000002
Processor: 0000000000000000
Time stamp: 000000000000495e
fffff88004205f3a USBPORT!USBPORT_AcquireEpListLock+0x2e
fffff880042172df USBPORT!USBPORT_Core_TimeoutAllTransfers+0x1f
fffff8800420f2ca USBPORT!USBPORT_DM_IoTimerDpc+0x9a
fffff80002a5b5bf nt!IopTimerDispatch+0x132
fffff80002a7c29e nt!KiProcessTimerDpcTable+0x66
Thread: fffff80002bf8c40
Old irql: 0000000000000002
New irql: 0000000000000002
Processor: 0000000000000000
Time stamp: 000000000000495e
fffff88004201694 USBPORT!MPf_CheckController+0x4c
fffff8800420f26a USBPORT!USBPORT_DM_IoTimerDpc+0x3a
fffff80002a5b5bf nt!IopTimerDispatch+0x132
fffff80002a7c29e nt!KiProcessTimerDpcTable+0x66
fffff80002a7bdd6 nt!KiProcessExpiredTimerList+0xc6
Thread: fffff80002bf8c40
Old irql: 0000000000000002
New irql: 0000000000000002
Processor: 0000000000000000
Time stamp: 000000000000495e
fffff8800420167c USBPORT!MPf_CheckController+0x34
fffff8800420f26a USBPORT!USBPORT_DM_IoTimerDpc+0x3a
fffff80002a5b5bf nt!IopTimerDispatch+0x132
fffff80002a7c29e nt!KiProcessTimerDpcTable+0x66
fffff80002a7bdd6 nt!KiProcessExpiredTimerList+0xc6
下面是在 Windows Vista 计算机上使用 !verifier扩展的示例，该计算机已开启位 7 并指定了 Address。
0: kd> !verifier 80 a2b1cf20
# Parsing 00004000 array entries, searching for address a2b1cf20.
Pool block a2b1ce98, Size 00000168, Thread a2b1ce98
808f1be6 ndis!ndisFreeToNPagedPool+0x39
808f11c1 ndis!ndisPplFree+0x47
808f100f ndis!NdisFreeNetBufferList+0x3b
8088db41 NETIO!NetioFreeNetBufferAndNetBufferList+0xe
8c588d68 tcpip!UdpEndSendMessages+0xdf
8c588cb5 tcpip!UdpSendMessagesDatagramsComplete+0x22
8088d622 NETIO!NetioDereferenceNetBufferListChain+0xcf
8c5954ea tcpip!FlSendNetBufferListChainComplete+0x1c
809b2370 ndis!ndisMSendCompleteNetBufferListsInternal+0x67
808f1781 ndis!NdisFSendNetBufferListsComplete+0x1a
8c04c68e pacer!PcFilterSendNetBufferListsComplete+0xb2
809b230c ndis!NdisMSendNetBufferListsComplete+0x70
# 8ac4a8ba test1!HandleCompletedTxPacket+0xea
Pool block a2b1ce98, Size 00000164, Thread a2b1ce98
822af87f nt!VerifierExAllocatePoolWithTagPriority+0x5d
808f1c88 ndis!ndisAllocateFromNPagedPool+0x1d
808f11f3 ndis!ndisPplAllocate+0x60
808f1257 ndis!NdisAllocateNetBufferList+0x26
80890933 NETIO!NetioAllocateAndReferenceNetBufferListNetBufferMdlAndData+0x14
8c5889c2 tcpip!UdpSendMessages+0x503
8c05c565 afd!AfdTLSendMessages+0x27
8c07a087 afd!AfdTLFastDgramSend+0x7d
8c079f82 afd!AfdFastDatagramSend+0x5ae
8c06f3ea afd!AfdFastIoDeviceControl+0x3c1
8217474f nt!IopXxxControlFile+0x268
821797a1 nt!NtDeviceIoControlFile+0x2a
8204d16a nt!KiFastCallEntry+0x127
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈