Controllo bug 0x139: KERNEL_SECURITY_CHECK_FAILURE
Il controllo dei bug KERNEL_SECURITY_CHECK_FAILURE ha un valore pari a 0x00000139. Questo controllo di bug indica che il kernel ha rilevato il danneggiamento di una struttura di dati critica.
Importante
Questo articolo è destinato ai programmatori. Se si è un cliente che ha ricevuto un codice di errore della schermata blu durante l'uso del computer, vedere Risolvere gli errori della schermata blu.
Controllo dei bug 0x139 KERNEL_SECURITY_CHECK_FAILURE parametri
| Parametro | Descrizione |
|---|---|
| 1 | Tipo di danneggiamento. Per altre informazioni, vedere la tabella seguente. |
| 2 | Indirizzo del frame trap per l'eccezione che ha causato il controllo del bug |
| 3 | Indirizzo del record di eccezione per l'eccezione che ha causato il controllo del bug |
| 4 | Prenotato |
Nella tabella seguente vengono descritti i valori possibili per il parametro 1.
| Parametro 1 | Descrizione |
|---|---|
| 0 | Un buffer basato su stack è stato sovraccarico (violazione legacy /GS). |
| 1 | Il codice di strumentazione VTGuard ha rilevato un tentativo di usare una tabella di funzioni virtuali non valida. In genere, un oggetto C++ è danneggiato e quindi è stata tentata una chiamata al metodo virtuale usando questo puntatore dell'oggetto danneggiato. |
| 2 | Il codice di strumentazione dei cookie stack ha rilevato un sovraccarico del buffer basato su stack (/GS). |
| 3 | Un LIST_ENTRY è stato danneggiato (ad esempio, una doppia rimozione). Per altre informazioni, vedere la sezione Causa seguente. |
| 4 | Prenotato |
| 5 | Un parametro non valido è stato passato a una funzione che considera irreversibili i parametri non validi. |
| 6 | Il cookie di sicurezza del cookie stack non è stato inizializzato correttamente dal caricatore. Questo problema può essere causato dalla compilazione di un driver solo in Windows 8 e dal tentativo di caricare l'immagine del driver in una versione precedente di Windows. Per evitare questo problema, è necessario compilare il driver da eseguire in una versione precedente di Windows. |
| 7 | È stata richiesta un'uscita irreversibile del programma. |
| 8 | Un controllo dei limiti di matrice inserito dal compilatore ha rilevato un'operazione di indicizzazione di matrice non valida. |
| 9 | È stata effettuata una chiamata a RtlQueryRegistryValues specificando RTL_QUERY_REGISTRY_DIRECT senza RTL_QUERY_REGISTRY_TYPECHECK e il valore di destinazione non si trovava in un hive di sistema attendibile. |
| 10 | Il controllo indiretto della guardia chiamata ha rilevato un trasferimento di controllo non valido. |
| 11 | Il controllo di protezione scrittura ha rilevato una scrittura di memoria non valida. |
| 12 | È stato effettuato un tentativo di passare a un contesto fiber non valido. |
| 13 | È stato effettuato un tentativo di assegnare un contesto di registro non valido. |
| 14 | Il conteggio dei riferimenti per un oggetto non è valido. |
| 18 | È stato effettuato un tentativo di passare a un contesto di jmp_buf non valido. |
| 19 | È stata apportata una modifica non sicura ai dati di sola lettura. |
| 20 | Un auto-test crittografico non è riuscito. |
| 21 | È stata rilevata una catena di eccezioni non valida. |
| 22 | Si è verificato un errore della libreria di crittografia. |
| 23 | È stata effettuata una chiamata non valida dall'interno di DllMain. |
| 24 | È stato rilevato un indirizzo di base dell'immagine non valido. |
| 25 | Errore irreversibile durante la protezione di un'importazione di caricamento ritardata. |
| 26 | È stata effettuata una chiamata a un'estensione non sicura. |
| 27 | È stato richiamato un servizio deprecato. |
| 28 | È stato rilevato un accesso al buffer out-of-bounds. |
| 29 | Una voce RBTree RTL_BALANCED_NODE è stata danneggiata. |
| 37 | È stata richiamata una voce di jumptable non compreso nell'intervallo. |
| 38 | Un longjmp è stato tentato di raggiungere una destinazione non valida. |
| 39 | Non è stato possibile effettuare una destinazione di chiamata valida per un'esportazione eliminata. |
Causa
Usando la tabella del parametro 1 e un file di dump, è possibile limitare la causa di molti controlli di bug di questo tipo.
LIST_ENTRY danneggiamento può essere difficile da rilevare e questo controllo dei bug indica che è stata introdotta un'incoerenza in un elenco collegato doubly (rilevato quando un singolo elemento voce elenco viene aggiunto o rimosso dall'elenco). Sfortunatamente, l'incoerenza non viene necessariamente rilevata al momento in cui si è verificato il danneggiamento, quindi potrebbe essere necessario un lavoro detective per identificare la causa radice.
Le cause comuni del danneggiamento delle voci di elenco includono:
- Un driver ha danneggiato un oggetto di sincronizzazione del kernel, ad esempio un KEVENT ,ad esempio l'inizializzazione doppia di un KEVENT mentre un thread era ancora in attesa dello stesso KEVENT o l'uscita di un KEVENT basato su stack all'esterno dell'ambito mentre un altro thread usava tale KEVENT. Questo tipo di controllo dei bug si verifica in genere in nt! Ke* o nt! Codice Ki*. Può verificarsi quando un thread termina l'attesa su un oggetto di sincronizzazione o quando il codice tenta di inserire un oggetto di sincronizzazione nello stato segnalato. In genere, l'oggetto di sincronizzazione segnalato è quello danneggiato. In alcuni casi, Driver Verifier con pool speciale può aiutare a rilevare il colpevole (se l'oggetto di sincronizzazione danneggiato si trova in un blocco di pool che è già stato liberato).
- Un driver ha danneggiato un KTIMER periodico. Questo tipo di controllo dei bug si verifica in genere in nt! Ke* o nt! Il codice Ki* e prevede la segnalazione di un timer o l'inserimento o la rimozione di un timer da una tabella timer. Il timer modificato può essere quello danneggiato, ma potrebbe essere necessario esaminare la tabella timer con !timer (o manualmente a piedi i collegamenti elenco timer) per identificare il timer danneggiato. A volte, Driver Verifier con pool speciale può aiutare a rilevare il colpevole (se il KTIMER danneggiato si trova in un blocco di pool che è già stato liberato).
- Un driver ha gestito in modo non gestito un elenco collegato interno di LIST_ENTRY. Un esempio tipico è chiamare RemoveEntryList due volte nella stessa voce di elenco senza reinserire la voce di elenco tra le due chiamate RemoveEntryList . Altre varianti sono possibili, ad esempio l'inserimento doppio di una voce nello stesso elenco.
- Un driver ha liberato una struttura di dati che contiene un LIST_ENTRY senza rimuovere la struttura dei dati dall'elenco corrispondente, causando il danneggiamento da rilevare in un secondo momento quando l'elenco viene esaminato dopo il riutilizzo del blocco di pool precedente.
- Un driver ha usato un elenco di LIST_ENTRY stile in modo simultaneo senza una sincronizzazione appropriata, causando un aggiornamento non aggiornato all'elenco.
Nella maggior parte dei casi, è possibile identificare la struttura dei dati danneggiata spostando l'elenco collegato in avanti e indietro (i comandi dl e dlb sono utili per questo scopo) e confrontando i risultati. Dove l'elenco è incoerente tra una passeggiata avanti e indietro è in genere la posizione del danneggiamento. Poiché un'operazione di aggiornamento dell'elenco collegato può modificare i collegamenti di elenco di un elemento adiacente, è consigliabile esaminare attentamente i vicini di una voce di elenco danneggiata, in quanto potrebbero essere il colpevole sottostante.
Poiché molti componenti di sistema usano internamente LIST_ENTRY elenchi, vari tipi di gestione errata delle risorse da parte di un driver che usano le API di sistema potrebbero causare il danneggiamento dell'elenco collegato in un elenco collegato gestito dal sistema.
Risoluzione
Determinare la causa di questo problema richiede in genere l'uso del debugger per raccogliere informazioni aggiuntive. È necessario esaminare più file di dump per verificare se questo codice di arresto presenta caratteristiche simili, ad esempio il codice in esecuzione quando viene visualizzato il codice di arresto.
Per altre informazioni, vedere Analisi del dump di arresto anomalo del sistema usando i debugger di Windows (WinDbg), Uso dell'estensione !analyze e !analyze.
Usare il registro eventi per verificare se sono presenti eventi di livello superiore che si verificano fino a questo codice di arresto.
Questi suggerimenti generali per la risoluzione dei problemi possono essere utili.
Se di recente è stato aggiunto hardware al sistema, provare a rimuoverlo o sostituirlo. In alternativa, rivolgersi al produttore per verificare se sono disponibili patch.
Se di recente sono stati aggiunti nuovi driver di dispositivo o servizi di sistema, provare a rimuoverli o ad aggiornarli. Provare a determinare le modifiche apportate al sistema che hanno causato la visualizzazione del nuovo codice di controllo dei bug.
Controllare l'accesso di sistema Visualizzatore eventi per ulteriori messaggi di errore che potrebbero aiutare a individuare il dispositivo o il driver che causa l'errore. Per altre informazioni, vedere Aprire Visualizzatore eventi. Controllare se nel registro di sistema sono presenti errori critici verificatisi nello stesso intervallo di tempo della schermata blu.
Cercare in Gestione dispositivi per verificare se i dispositivi sono contrassegnati con il punto esclamativo (!). Esaminare il log eventi visualizzato nelle proprietà del driver per qualsiasi driver che causa errori. Provare ad aggiornare il driver correlato.
Eseguire un programma di rilevamento virus. I virus possono infettare tutti i tipi di dischi rigidi formattati per Windows e il danneggiamento del disco risultante può generare codici di controllo dei bug di sistema. Assicurarsi che il programma di rilevamento virus controlli il record di avvio master per rilevare le infezioni.
Per altre informazioni generali sulla risoluzione dei problemi, vedere Analizzare i dati della schermata blu di controllo dei bug.
Vedere anche
Analisi del dump di arresto anomalo del sistema usando i debugger di Windows (WinDbg)