Debug di errori di timeout NDIS/WiFi - DRIVER_VERIFIER_DETECTED_VIOLATION (C4)
Quando si dispone dell'opzione di verifica NDIS/WIFI selezionata e Il verificatore driver rileva che il driver viola una delle regole di timeout NDIS/WiFi, Driver Verifier genera controllo bug 0xC4 : DRIVER_VERIFIER_DETECTED_VIOLATION (con parametro 1 uguale all'identificatore della regola di timeout NDIS/WiFi specifica).
Quando Driver Verifier sta testando una regola di timeout NDIS/WIFI, ad esempio NdisTimedOidComplete, il meccanismo di polling di Driver Verifier prevede una risposta dal driver miniport entro un numero di cicli. Ogni regola timed ha definito il proprio ciclo massimo consentito. Quando il valore massimo viene superato, Il verificatore driver genera un controllo di bug. Questa sezione descrive alcune strategie di esempio per il debug di queste violazioni.
Debug di errori di timeout NDIS/WIFI
- Usare !analizza per visualizzare informazioni sul controllo dei bug
- Usare il comando di estensione !ruleinfo
- Fare clic sul collegamento LAST_CALL_STACK per identificare la posizione della violazione
- Correzione della causa della violazione del timeout NDIS/WIFI
Usare !analizza per visualizzare informazioni sul controllo dei bug
Come per qualsiasi verifica di bug che si verifica, una volta ottenuto il controllo del debugger, il primo passaggio migliore consiste nell'eseguire il comando !analyze -v .
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 00092003, ID of the 'NdisTimedOidComplete' rule that was violated.
Arg2: 8521dd34, A pointer to the string describing the violated rule condition.
Arg3: 9c17b860, Address of internal rule state (second argument to !ruleinfo).
Arg4: 9c1f3480, Address of supplemental states (third argument to !ruleinfo).
Nella sezione seguente dell'output !analyze -v , il motivo per cui la regola è stata violata in viene visualizzata sotto il campo DV_VIOLATED_CONDITION. La sezione DV_MSDN_LINK è utile anche eseguire il pull di un collegamento alla documentazione su questa regola.
Dettagli debug:
*** ERROR: Module load completed but symbols could not be loaded for NdisTimedOidComplete.sys
DV_VIOLATED_CONDITION: Timeout on completing an NDIS OID request.
DV_MSDN_LINK: https://learn.microsoft.com/windows-hardware/drivers/devtest/ndis-ndistimedoidcomplete
DRIVER_OBJECT: 98a87980
IMAGE_NAME: NdisTimedOidComplete.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 5229c857
MODULE_NAME: NdisTimedOidComplete
FAULTING_MODULE: 9fee1000 NdisTimedOidComplete
Più avanti in questo output di analisi, è possibile fare clic sul collegamento nella sezione DV_RULE_INFO per altre descrizioni delle regole. Per il tipo di regole di timeout, lo stack corrente potrebbe non contenere informazioni pertinenti.
DV_RULE_INFO: 0x92003
BUGCHECK_STR: 0xc4_NdisTimedOidComplete_XDV
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 2
ANALYSIS_VERSION: 6.13.0016.1929 (debuggers(dbg).130725-1857) amd64fre
LAST_CONTROL_TRANSFER: from 80f87fd3 to 80f0ed14
STACK_TEXT:
8912380c 80f87fd3 00000003 e6c3476e 00000065 nt!RtlpBreakWithStatusInstruction
89123860 80f87aed 825a6138 89123c5c 89123cac nt!KiBugCheckDebugBreak+0x1f
89123c30 80f0d8d6 000000c4 00092003 8521dd34 nt!KeBugCheck2+0x676
89123c54 80f0d80d 000000c4 00092003 8521dd34 nt!KiBugCheck2+0xc6
89123c74 85211584 000000c4 00092003 8521dd34 nt!KeBugCheckEx+0x19
89123cac 85216d54 9c17b860 9c1f3480 9c17b8dc VerifierExt!SLIC_StatefulAbort+0x1a4
89123cd0 85216ffe 85220000 85215f5b 00000000 VerifierExt!Ndis_OnTimerExpire+0x234
89123cd8 85215f5b 00000000 80ecd56a 843d0c38 VerifierExt!CheckOnTimerExpire+0x26
89123ce0 80ecd56a 843d0c38 00000000 80ecd502 VerifierExt!XdvPassiveTimerRoutine+0x1d
89123d24 80eec133 882befd0 00000000 887debc0 nt!IopProcessWorkItem+0x68
89123d70 80ec1162 00000000 e6c342be 00000000 nt!ExpWorkerThread+0x14f
89123db0 80f23201 80eebfe4 00000000 00000000 nt!PspSystemThreadStartup+0x58
89123dbc 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x15
Usare il comando di estensione !ruleinfo
Il DV_RULE_INFO: campo dell'output !analyze mostra un collegamento al comando che è possibile usare per trovare altre informazioni su questa violazione della regola. Per questo esempio, se si fa clic sul collegamento, viene eseguito il comando !ruleinfo con il RULE_ID (0x92003) i valori di controllo dei bug Arg3 e Arg 4.
kd> !ruleinfo 0x92003 0xffffffff9c17b860 0xffffffff9c1f3480
RULE_ID: 0x92003
RULE_NAME: NdisTimedOidComplete
RULE_DESCRIPTION:
This rule verifies if an NDIS miniport driver completes an OID in time.
The OID is tracked (a.k.a., TRACKED_OBJECT). Use !ndiskd.oid .
MSDN_LINK: https://learn.microsoft.com/windows-hardware/drivers/devtest/ndis-ndistimedoidcomplete
CONTEXT: Miniport 0x86BD10E8
CURRENT_TIME (Timed Rules): 168 seconds
TRACKED_OBJECT: 0x86633804
LAST_CALL_STACK: 0x9C1F3480 + 0x10
RULE_STATE: 0x9C1F3480
Identificare la posizione della violazione
Nell'esempio che si usa qui, il driver miniport, NdisTimedOidComplete.sys, ha un ciclo di sospensione inserito nella funzione MPOidRequest . È possibile controllare facendo clic sul collegamento LAST_CALL_STACK nell'output !ruleinfo . Questo è l'ultimo stack di chiamate visto da Driver Verifier, dove si noterà che NDIS denominato ndisMInvokeOidRequest prima del timeout.
kd> dps 0x9C1F3480 + 0x10
9c1f3490 850e1e37 ndis!ndisMInvokeOidRequest+0x16641
9c1f3494 850765c8 ndis!ndisMDoOidRequest+0x24a
9c1f3498 8507552a ndis!ndisQueueOidRequest+0x2fa
9c1f349c 8507372b ndis!ndisQuerySetMiniportEx+0xd9
9c1f34a0 85073646 ndis!ndisQuerySetMiniport+0x18
9c1f34a4 850dd9c8 ndis!ndisMDoMiniportOp+0x8c
9c1f34a8 850dd916 ndis!ndisMNotifyMachineName+0xe4
9c1f34ac 85104005 ndis!ndisMInitializeAdapter+0xad7
Correzione della causa della violazione del timeout WIFI NDIS
Quando il dump dell'arresto anomalo è stato generato per una regola timed, è possibile che la causa radice possa essere trovata al momento del dump dell'arresto anomalo. Per eseguire il debug, è consigliabile iniziare con i comandi dell'estensione del debugger NdisKd, vedere Estensioni NDIS (Ndiskd.dll) e Introduzione a NDISKD. Potrebbe anche essere necessario esaminare i log di Traccia eventi per Windows (ETW), se il driver ha implementato ETW. Se questa regola non è stata abilitata, questo errore si manifesterà come l'applicazione utente si blocca al meglio o un controllo bug 0x9F: DRIVER_POWER_STATE_FAILURE al peggio.