Informazioni di riferimento sul codice di dump live del kernel
Questa sezione contiene descrizioni dei codici comuni di dump live del kernel che possono verificarsi. I dump in tempo reale non reimpostano il sistema operativo, ma consentono l'acquisizione di informazioni sulla memoria per situazioni anomale in cui il sistema operativo può continuare.
Nota
Questo argomento è destinato ai programmatori. Se si è un cliente il cui sistema ha visualizzato una schermata blu con un codice di controllo dei bug, vedere Risolvere gli errori della schermata blu.
Dump live del kernel rispetto al controllo dei bug
Con un controllo di bug tradizionale, il PC viene reimpostato e il lavoro dell'utente viene interrotto. L'obiettivo del dump in tempo reale del kernel è raccogliere i dati per risolvere un problema anomalo, ma consentire al sistema operativo di continuare l'operazione. In questo modo si riduce il tempo di inattività rispetto a un controllo dei bug per individuare errori non irreversibili, ma con errori ad alto impatto e blocchi. I dump in tempo reale del kernel vengono usati quando è possibile ripristinare il sistema operativo in uno stato valido noto. Ad esempio, una reimpostazione hardware di un sottosistema, ad esempio video/display, USB3 o Wi-Fi può consentire a tali sistemi di tornare a uno stato valido noto, con un impatto minimo sull'utente.
Un dump live del kernel crea uno snapshot coerente della memoria del kernel e lo salva in un file di dump per l'analisi futura. Per ridurre al minimo l'impatto sulle prestazioni, vengono usate tecniche di copia della memoria per creare il file di dump in un breve periodo di tempo. Inoltre, la raccolta di dump in tempo reale è limitata, in modo che l'impatto dell'utente venga ridotto al minimo.
Un dump in tempo reale del kernel è efficace per una categoria di problemi in cui qualcosa richiede molto tempo, ma nulla è tecnicamente in errore. Un timer watchdog può essere inizializzato all'avvio di un'operazione. Se il watchdog scade prima del completamento dell'operazione con nel tempo previsto, è possibile eseguire un dump live del sistema. È quindi possibile analizzare il dump attraversando lo stack di chiamate e la catena di attesa correlata per verificare il motivo per cui non viene completato con l'intervallo di tempo previsto.
I log di sistema funzionano correttamente quando si verifica un errore e il proprietario del codice ha registrato la causa dell'errore e può identificare la causa. I dump in tempo reale che usano timer watchdog tentano di intercettare i percorsi di errore non previsti e registrati. Tuttavia, come per ogni errore, i log di sistema possono identificare altri problemi che possono fornire indizi sulla causa radice specifica dell'errore.
Contenuto del file di dump live del kernel
Analogamente ai normali file di dump, i file di dump live possono contenere minidump (con dati secondari) e dump completi del kernel, che possono includere anche la memoria in modalità utente, analogamente ai dump attivi. Per informazioni generali sul contenuto del file di dump, vedere Varietà di file di dump in modalità kernel. Alcuni dump live tentano solo di acquisire minidump, poiché sono progettati per acquisire dati specifici correlati all'hardware, mentre altri potrebbero tentare di acquisire un dump live del kernel più grande.
Per prestazioni, dimensioni dei file e per l'affidabilità delle acquisizioni di dump, alcune informazioni non sono incluse, ad esempio pagine dall'elenco in attesa e dalle cache dei file.
I file di dump live contengono in genere pagine di memoria, ad esempio:
- KdDebuggerBlock
- Elenco dei moduli caricati
Per ogni processore vengono acquisite le informazioni seguenti nei dump del kernel:
- KiProcessorBlock
- PrCB
- Stack corrente
- Tabella di directory della pagina corrente
- KI_USER_SHARED_DATA
- Immagine del kernel NTOS
- Immagine HAL
Altre informazioni nei dump del kernel possono includere:
- Stato thread/memoria
- Registrazione in memoria
Alcuni dump live possono contenere pagine di processo in modalità utente.
Altri dati specifici del dominio, ad esempio dati specifici usb per gli errori USB, possono essere inclusi per alcuni dump live.
File di dump live del kernel parziale
Un file di dump live del kernel parziale può essere generato in situazioni in cui il dump attivo non può acquisire in modo affidabile tutte le pagine di memoria previste. Le informazioni acquisite in un dump parziale vengono filtrate e classificate in ordine di priorità, acquisendo pagine contenenti dati importanti necessari per generare un dump valido prima di altre pagine. Ad esempio, le pagine del kernel sono classificate in ordine di priorità rispetto alle pagine utente, quando il dump live include le pagine utente. In alcune situazioni non sono disponibili risorse sufficienti per acquisire tutte le pagine di memoria facoltative desiderate, quindi la memoria potrebbe non essere presente nel file di dump. Il file dump deve comunque essere riconosciuto dal debugger WinDbg, ma può mostrare errori durante il tentativo di dump della memoria. Se il debugger visualizza un errore durante il tentativo di eseguire il dump della memoria in un indirizzo, è possibile usare l'estensione !pte per verificare se il PTE per un indirizzo è valido o meno. Ciò consente di determinare se l'indirizzo di memoria non è valido o se la pagina è valida ma non è disponibile nel file di dump.
Analisi dei file di dump in tempo reale
Quando si verifica un dump in tempo reale, il file di dump può essere analizzato usando le stesse tecniche usate per altri file di dump della memoria. Per comprendere il contenuto della memoria durante un errore, è necessaria la conoscenza dei registri di memoria del processore e della programmazione degli assembly.
Per altre informazioni, vedi:
Uso di WinDbg per visualizzare informazioni sul codice di arresto del dump live
Se in questo argomento non viene visualizzato un codice di dump live specifico, usare l'estensione !analyze in Windows Debugger (WinDbg) con la sintassi seguente (in modalità kernel), sostituendo <code> con un codice di dump live:
!analyze -show <code>
Se si immette questo comando, WinDbg visualizza informazioni sul codice di dump live specificato. Se la base del numero predefinito (radix) non è 16, anteporre <code> 0x.
Specificare i parametri del codice di dump live al comando !analyze per visualizzare le informazioni sui parametri disponibili. Ad esempio, per visualizzare informazioni sul controllo dei bug 0x144 BUGCODE_USB3_DRIVER, con un valore di parametro 1 di 0x3003, usare !analyze -show 0x144 0x3003 come illustrato di seguito.
0: kd> !analyze -show 0x144 0x3003
BUGCODE_USB3_DRIVER (144)
This bugcheck usually happens when the USB3 core stack detects an invalid
operation being performed by a USB client. This bugcheck may also occur
due to hardware failure on a USB Boot Device.
Arguments:
Arg1: 0000000000003003, USB3_WER_BUGCODE_USBHUB3_DEVICE_ENUMERATION_FAILURE
A USB device failed enumeration.
Arg2: 0000000000000000, USBHUB3_LIVEDUMP_CONTEXT
Arg3: 0000000000000000, 0
Arg4: 0000000000000000, 0
Per scaricare WinDbg, vedere Strumenti di debug per Windows. Per altre informazioni sugli strumenti di sviluppo WinDbg, vedere Introduzione al debug di Windows.
Percorsi dei file di dump in tempo reale
I dump in tempo reale per impostazione predefinita vengono archiviati nella directory 'C:\WINDOWS\LiveKernelReports'.
Dump completi: %systemroot%\LiveKernelReports\*.dmp
Minidumps: %systemroot%\LiveKernelReports\<ComponentName>\*.dmp
Una struttura di directory viene usata per archiviare i dump in tempo reale per componenti diversi.
NDIS
PDCRevocation
PoW32kWatchdog
USBHUB3
WATCHDOG
Chiavi del Registro di sistema di dump in tempo reale
Per altre informazioni sulle opzioni di configurazione per i report del kernel live generati dal sistema, vedere Impostazioni wer.
Usare PowerShell per attivare manualmente un dump in tempo reale
Aprire e visualizzare il prompt di PowerShell per l'amministratore.
Ottenere il nome descrittivo di StorageSubsystem usando il comando PowerShell Get-StorageSubSystem .
C:\> Get-StorageSubSystem
FriendlyName HealthStatus OperationalStatus
------------ ------------ -----------------
Windows Storage on 10-2411-PC Healthy OK
- Usare Get-StorageDiagnosticInfo per generare un dump in tempo reale per il sottosistema precedente (insieme ad altri log di diagnostica). Per altre informazioni, vedere Get-StorageDiagnosticInfo.
C:\> Get-StorageDiagnosticInfo -StorageSubSystemFriendlyName "Windows Storage on 10-2411-PC" -IncludeLiveDump -DestinationPath C:\destinationfolder
- L'output indicherà che le informazioni richieste vengono generate.
Gathering storage subsystem diagnostic information
Running
[oooooooooooo ]
- Il dump sarà all'interno
[DestinationPath]\localhostdi .
C:\> dir C:\destinationfolder\localhost\*.dmp
Directory: C:\destinationfolder\localhost
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 5/5/2016 1:08 PM 867135488 LiveDump.dmp
- L'uso del debugger per eseguire !analyze nel file di dump indicherà che si tratta di un codice di dump attivo di LIVE_SYSTEM_DUMP (161).
Codici di dump in tempo reale del kernel
La tabella seguente fornisce collegamenti ai codici di dump live del kernel.
Questi codici di arresto possono essere usati per i dump in tempo reale o per controllare il dispositivo.
| Codice | Nome |
|---|---|
| 0x00000124 | WHEA_UNCORRECTABLE_ERROR |
| 0x00000144 | BUGCODE_USB3_DRIVER |
| 0x00000164 | WIN32K_CRITICAL_FAILURE |
Vedi anche
Riferimento al codice del controllo errori