Crashdump Support Test (LOGO)
Questo test verifica che il driver miniport di archiviazione in Windows supporti la creazione di un file di dump della memoria dopo che si verifica un errore di arresto del sistema.
Dettagli del test
| Specifiche |
|
| Piattaforme |
|
| Versioni supportate |
|
| Tempo di esecuzione previsto (in minuti) | 45 |
| Categoria | Scenario |
| Timeout (in minuti) | 2700 |
| Richiede il riavvio | false |
| Richiede una configurazione speciale | true |
| Tipo | automatic |
Documentazione aggiuntiva
I test in questa area di funzionalità potrebbero avere documentazione aggiuntiva, inclusi i prerequisiti, la configurazione e le informazioni sulla risoluzione dei problemi, disponibili negli argomenti seguenti:
- Documentazione aggiuntiva su Device.Storage
- Documentazione aggiuntiva di System.Fundamentals
- Documentazione aggiuntiva di System.Server
Esecuzione del test
Prima di eseguire il test, completare la configurazione di test descritta nei requisiti di test per il tipo di controller di archiviazione che si sta testando. Per altre informazioni, vedi Panoramica dei test dell'adattatore di archiviazione o del controller.
Questo test richiede software e hardware aggiuntivi:
Dispositivo da testare
Disco rigido con un minimo di 20 GB disponibile nella partizione C:.
Prima di eseguire il test, è necessario completare anche i prerequisiti seguenti:
Se il sistema di test ha una connessione Internet, non è necessario eseguire alcuna azione.
Se il sistema di test non dispone di una connessione Internet, creare una cartella denominata C:\Symbols e scaricare e installare i simboli del sistema operativo Windows. A questo scopo, seguire questa procedura:
Nota
I simboli sono necessari per analizzare il file di dump. L'errore di installazione dei simboli è il problema di configurazione dei test più comune che causa l'esito negativo di questo test. La versione dei simboli deve corrispondere alla versione del sistema operativo installata nel computer di test. Pertanto, deve essere scaricato esternamente al kit.
In un computer con connessione Internet scaricare i pacchetti Simboli di Windows. Per altre informazioni, vedere Scaricare i pacchetti di simboli di Windows.
Copiare i file di simboli nel computer di test nella cartella C:\Symbols . Poiché i simboli possono essere di grandi dimensioni, è sufficiente copiare ntkrnlmp.pdb (per x64 o Arm) o ntkrpamp.pdb (per x86).
Risoluzione dei problemi relativi
Per la risoluzione generica degli errori di test HLK, vedere Risoluzione dei problemi di test di Windows HLK.
Per informazioni sulla risoluzione dei problemi, vedere Risoluzione dei problemi relativi ai test di Device.Storage.
Il messaggio di errore del log di test "Non è stato possibile caricare i simboli corretti"
Al riavvio, il test esamina il file di dump per verificare la correttezza. Il test esegue questa operazione, proprio come farebbe uno sviluppatore, usando il debugger del kernel kd (vedere Scaricare e installare gli strumenti di debug per Windows). Per analizzare un file di dump, il debugger deve accedere ai simboli (vedere File di simboli). Si tratta di un dizionario per il dump. Consentono al debugger di analizzare il contenuto della memoria (o un file crashdump) in singoli moduli (eseguibili, librerie, driver e così via), funzioni all'interno di tali moduli e strutture di dati. Come regola generale, se non è possibile esaminare il file di dump usando il debugger del kernel, il test non può superare.
Affinché il test funzioni correttamente, deve fornire al debugger simboli. Quando non dispone di simboli appropriati, registra gli avvisi durante gli errori del log durante la prima fase di analisi del test. Il meccanismo corrente per eseguire questa operazione consiste nel scaricare i pacchetti di simboli pubblici (vedere Scaricare pacchetti di simboli di Windows) e installarli nel computer di test prima di eseguire il test. Quando i simboli non sono installati o non corrispondono al sistema operativo sottoposto a test, il messaggio seguente può essere visualizzato nel log di test:
(x) Impossibile caricare i simboli corretti.
(i) Fare riferimento alla documentazione di WDK su come installare i simboli del sistema operativo.
(i) I simboli potrebbero anche non essere aggiornati, aggiornare i simboli usando il server dei simboli Microsoft.
Questo messaggio non causa effettivamente l'esito negativo del test perché in alcuni casi il dump può comunque essere analizzato con simboli parzialmente corrispondenti. Se il test continua e altri test case hanno esito negativo con messaggi come Errore durante il recupero degli indirizzi ... o Non è possibile ottenere..., significa che il debugger non può analizzare il dump a causa di simboli mancanti. Un modo per aggirare un simbolo consiste nell'integrare il simbolo installato localmente in pacchetto con simboli memorizzati nella cache da un server di simboli Internet. Seguire questa procedura per memorizzare nella cache i simboli in locale:
Assicurarsi di aver già creato un crashdump. Il modo più semplice per eseguire questa operazione consiste nell'eseguire il test una sola volta e lasciare che non riesca.
Assicurarsi di avere installato gli strumenti di debug. Anche in questo caso, il modo più semplice per eseguire il test è una sola volta. Installerà gli strumenti in C:\Debuggers.
Apri una finestra del prompt dei comandi con privilegi elevati.
Digitare il comando seguente
c:\Debuggers\kd -z c:\Windows\MEMORY.DMP -y SRV*C:\Symbols*http://msdl.microsoft.com/download/symbolsQuesto carica il dump nel debugger del kernel usando l'archivio simboli remoto in Microsoft e la directory locale C:\Symbols come archivio downstream per memorizzare nella cache i simboli.
Assicurarsi che i simboli siano disponibili per i file del sistema operativo, ad esempio NTOSKRNL e NTDLL. Questi file sono necessari per analizzare il dump. È OK se vengono visualizzati errori durante il caricamento dei simboli per altri moduli, ad esempio driver di terze parti.
A questo momento dovrebbe essere visualizzato un prompt 0: kd>. A questo prompt, digitare il comando .reload /f. Questo comando forza il debugger a caricare e memorizzare nella cache tutti i simboli per i moduli caricati nel dump.
Per uscire dal debugger, premere CTRL+B e quindi premere INVIO.
Il messaggio di errore del log di test indica che le dimensioni del file di paging sono troppo piccole per scopi di dump completi.
Nel caso di un arresto anomalo, non c'è certezza di quali parti del sistema operativo saranno ancora funzionanti. I driver di rete o file system potrebbero aver causato l'arresto anomalo; ad esempio, impedendo l'accesso alle strutture del file system per creare un file dump o una rete per archiviare il file in modalità remota. Il sistema operativo gestisce questa operazione usando un file già noto (il file di paging) e scrive direttamente negli extent di blocco logici del file su disco. Il processo di dump scrive il contenuto della memoria fisica nel file di paging sul disco di sistema ( in generec:\pagefile.sys). Il file di paging deve essere sufficientemente grande da contenere il dump. Il dump più grande è un dump completo, che richiede le dimensioni della memoria fisica (ad esempio, 4096) più un megabyte aggiuntivo per contenere le informazioni sull'intestazione. Il test richiede che l'utente configuri il file di pagina in base alle dimensioni appropriate prima dell'esecuzione. Se le dimensioni del file di pagina non sono sufficienti, il test porterà l'errore seguente durante la fase di inizializzazione:
(i) Verifica delle dimensioni del file di paging.
(x) Le dimensioni del file di paging sono troppo piccole per scopi di dump completi.
(i) Dimensioni del file di paging: 330989568
(i) Dimensioni della memoria fisica: 1073094656
(i) Configurare le dimensioni minime del file di paging per le dimensioni fisiche della RAM + 1 MB.
Viene visualizzato l'errore di arresto del sistema (schermata blu), ma il codice di controllo bug non è E2
Dopo la convalida di alcune impostazioni di base, il test installerà un driver usato per arrestare il sistema e riavviare il sistema. Dopo il riavvio, il test modifica le impostazioni del controllo di arresto anomalo (per il dump completo della memoria), elimina tutti i file di dump precedenti e arresta in modo anomalo il sistema. Al momento dell'arresto anomalo, il sistema visualizzerà una schermata di controllo dei bug (schermata blu) con i dettagli della natura dell'arresto anomalo. Il tipo di controllo dei bug deve essere MANUALLY_INITIATED_CRASH (e2). Se viene visualizzato qualcos'altro, significa che si è verificato un secondo controllo di bug durante il processo di scrittura del file di dump. Questa operazione deve essere esaminata connettendo un debugger del kernel al client di test e eseguendo il debug del driver dell'adattatore di archiviazione.
Il messaggio di errore del log di test indica che il file di dump viene usato da un altro processo. HRESULT: 0x80070020"
Dopo aver scritto il file di dump, il computer di test dovrebbe essere riavviato automaticamente. All'avvio dopo un arresto anomalo, il sistema operativo rileverà la presenza di informazioni di dump nel file di pagina e inizierà il processo di scrittura di un dump. Questo processo si verifica in modo asincrono durante l'avvio del computer e anche dopo l'accesso dell'utente. Durante questo processo, è possibile visualizzare lo stato di avanzamento controllando le dimensioni del file di dump (C:\windows\memory.dmp) o visualizzando il processo in Gestione attività (werfault.exe). Il test verrà spesso eseguito contemporaneamente a questo processo, provando ad accedere allo stesso file di dump. In questo caso, nel log verranno visualizzati i messaggi seguenti:
(i) Connessione a DumpFile: C:\Windows\MEMORY. DMP
(i) Il file di dump viene usato da un altro processo. HRESULT: 0x80070020
(i) In genere memory.dmp è ancora in fase di scrittura a causa di RAM di grandi dimensioni, riprovare dopo 5 minuti.
Il test dovrebbe quindi riprovare ad accedere al file. Se il codice del messaggio di errore è diverso o se viene modificato (ad esempio, 0x80070002 : ERROR_FILE_NOT_FOUND), significa che il file non può essere scritto su disco. La prima posizione in cui verificare la presenza di informazioni di debug preziose è il registro eventi di sistema. Per visualizzare il registro eventi fare clic su Start, fare clic su Esegui, quindi digitare Compmgmt.msc. Nella finestra gestione computer selezionare Gestione computer\Strumenti di sistema\Visualizzatore eventi\Sistema. Scorrere l'elenco degli eventi per un evento con BugCheck di origine. La causa più comune per un file di dump mancante è spazio libero insufficiente sul disco. La chiave del Registro di sistema HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\MachineCrash contiene informazioni sull'ultimo arresto anomalo (prima di un riavvio), incluso il file di dump parziale se ne è stato creato uno. Ciò può essere utile quando si tenta di eseguire il debug di altri problemi di dump mancanti.
Altre informazioni
Crashdump è il meccanismo in cui il sistema operativo chiama il driver dell'adattatore di archiviazione per scrivere il contenuto della memoria in un file dump dopo un errore di arresto del sistema. A causa della natura di un errore di arresto del sistema, il sistema operativo non può fare ipotesi sulla stabilità del sistema. Pertanto, pochissimi servizi di sistema sono disponibili per i driver di archiviazione. Il test di supporto crashdump verifica che il driver dell'adattatore di archiviazione possa comunque funzionare in questi ambienti vincolati ed eseguire l'I/O per scrivere correttamente nel dump.
Il sistema operativo Windows consente di generare tre diversi tipi di file di dump della memoria:
Full
Kernel
Mini
Il test testa i tipi di file kernel e mini dump. Per altre informazioni su questi tipi di file di dump, vedere File di dump in modalità kernel.
Il test completerà la sequenza di operazioni seguente:
Installare gli strumenti di debug per Windows nella directory %SystemDrive%\Debuggers e inizializzare il sistema.
Installare il driver di test per simulare l'arresto anomalo.
Impostare le dimensioni del file di pagina.
Simulare gli errori di arresto del sistema (schermata blu) con il codice di controllo bug 0x000000E2.
Riavviare il sistema e riavviare automaticamente il test.
Esaminare l'arresto anomalo precedente analizzando il file di dump della memoria tramite il debugger del kernel e verificare che il dump sia stato scritto correttamente.
Ripetere i passaggi da 4 a 6 per ogni tipo di file dump.
Sintassi dei comandi
| Comando | Descrizione |
|---|---|
Crashdumptest.exe -c |
Cancellare eventuali errori passati. |
crashdumptest.exe -dtm -y [SymbolsDirectory] -ypass |
Inizializzare il test. |
crashdumptest.exe -autorun -y [SymbolsDirectory] -dtm" |
Esegue il test. |
Elenco file
| Opzione di comando | Descrizione |
|---|---|
Crashdumptest.exe |
[TestBinRoot]\nttest\driverstest\storage\wdk\ |
BugCheck.sys |
[TestBinRoot]\nttest\driverstest\storage\wdk\ |
Parametri
| Nome parametro | Descrizione dei parametri |
|---|---|
| DebuggerDirectory | Directory in cui installare i debugger. |
| SymbolsDirectory | Directory in cui sono già installati i simboli. |
| LLU_LclAdminUsr | Account utente per l'esecuzione del test. |
| LLU_NetAccessOnly | Account utente per l'accesso alla condivisione file di test. |
| PagefileSize | Dimensioni del file di paging in MB (supporta il formato mem+N) |