C’è un problema noto relativo ai simboli del kernel di Windows 7?

Ho alcune macchine Windows 7 che non sono in grado di leggere i loro dump della memoria. Ho trovato qualcosa che sospetto possa essere correlato, ma non sono positivo:

Ho anche trovato questo: http://support.microsoft.com/kb/2528507

Tuttavia, il messaggio di scenario riguardante wow64exts dato nel documento non è visto in nessuno dei miei dump. Non posso anche applicare questo hotfix in questo momento per testarlo. Quindi sto solo cercando altre informazioni o opinioni.

Sono in grado di aprire qualsiasi altro dump del sistema operativo e il dump di Windows 7 del mio sistema, ma ci sono altri 2 computer che eseguono Win 7 e mi dice che ho i simboli del kernel sbagliati.

Ho provato a svuotare la cache dei simboli, ho reinstallato l’SDK di Windows e ho anche provato ad aprire i dump su altre due macchine con lo stesso risultato. Se è importante, l’arresto anomalo viene creato manualmente utilizzando il metodo Scroll Lock.

Percorso del simbolo: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;

Vedendo questi errori: seguito da “Tipo di riferimento: nt! _KPRCB”

Qualcuno sa del problema menzionato da Alex nel link di twitter e se è forse correlato a ciò che sto vedendo?

Aggiornamento 2015-10-22:

Con Microsoft patch day (2015-10-13) e KB3088195 , i simboli sono nuovamente disponibili.

Tuttavia, i simboli per la versione non funzionante non sono stati forniti, quindi di seguito potrebbe essere ancora utile.


Microsoft ha già pubblicato “buoni” simboli per ntdll in passato, contenenti informazioni di tipo come _TEB o _KPRCB . A partire da metà luglio 2015, Microsoft ha ancora pubblicato i simboli per ntdll , ma non contenenti tali informazioni.

Quindi dipende dalla versione di ntdll se ottieni informazioni sul tipo o meno. I vecchi dump che fanno riferimento a una vecchia versione di ntdll scaricheranno vecchi PDB contenenti informazioni di tipo mentre i nuovi dump fanno riferimento alle nuove versioni di ntdll e WinDbg (o qualsiasi altro debugger) scaricando PDB senza informazioni di tipo.

Microsoft potrebbe rimuovere le informazioni sul tipo di simboli “buoni” retrotriggersmente, rendendoli così “cattivi”?

Sì. Come descritto in questa risposta , esiste uno strumento per rimuovere le informazioni sul tipo dai PDB esistenti. Facendo questo e sostituendo il PPB si otterrebbe un tale effetto.

Microsoft può pubblicare la versione “buona” di quei PDB attualmente “cattivi”?

È difficile da dire, dal momento che non sappiamo se Microsoft ha conservato una copia della versione “buona” in modo da poter sostituire la versione “ctriggers” sul server dei simboli con quella “buona”. La ricostruzione di ntdll dallo stesso codice sorgente e quindi la creazione di nuovi PDB sembra ansible, ma il PDB ottiene un nuovo time stamp e checksum. Questo può potenzialmente essere corretto manualmente, specialmente Microsoft, dal momento che dovrebbero avere la conoscenza del formato interno del PDB, ma IMHO è improbabile che lo facciano. Le cose potrebbero andare storte e MS difficilmente avrà test per garantire la correttezza di una cosa del genere.

Quindi cosa posso fare?

IMHO non puoi fare nulla per correggere veramente la situazione.

Si può presumere che i tipi in ntdll non siano cambiati così tanto. Ciò consentirebbe di prendere una versione precedente di wntdll.pdb e la nuova versione di ntdll.dll e applicare ChkMatch -m . Ciò copierà il timestamp e il checksum dalla DLL al PDB. Dopo averlo fatto (in una cartella vuota), sostituire il file wntdll.pdb esistente nella directory dei simboli con quello hackerato.

WinDbg walkthrough (con output abbreviato per le cose rilevanti). Sto usando l’ultima versione di wntdll.pdb ho trovato sul mio PC.

ATTENZIONE: fare quanto segue può correggere le informazioni sul tipo ma probabilmente distruggerà la correttezza dei callstacks. Poiché qualsiasi modifica all’implementazione (che è probabile per le correzioni di sicurezza) cambierà le correzioni del metodo.

 0:005> dt nt!_PEB ************************************************************************* *** *** *** Either you specified an unqualified symbol, or your debugger *** ... *** Type referenced: nt!_PEB *** *** *** ************************************************************************* Symbol nt!_PEB not found. 0:005> lm m ntdll start end module name 773f0000 77570000 ntdll (pdb symbols) e:\debug\symbols\wntdll.pdb\FA9C48F9C11D4E0894B8970DECD92C972\wntdll.pdb 0:005> .shell cmd /c copy C:\Windows\SysWOW64\ntdll.dll e:\debug\temp\ntdllhack\ntdll.dll 1 file(s) copied. 0:005> .shell cmd /c copy "E:\Windows SDk\8.0\Debuggers\x86\sym\wntdll.pdb\B081677DFC724CC4AC53992627BEEA242\wntdll.pdb" e:\debug\temp\ntdllhack\wntdll.pdb 1 file(s) copied. 0:005> .shell cmd /c E:\debug\temp\ntdllhack\chkmatch.exe -m E:\debug\temp\ntdllhack\ntdll.dll E:\debug\temp\ntdllhack\wntdll.pdb ... Executable: E:\debug\temp\ntdllhack\ntdll.dll Debug info file: E:\debug\temp\ntdllhack\wntdll.pdb Executable: TimeDateStamp: 55a69e20 Debug info: 2 ( CodeView ) TimeStamp: 55a68c18 Characteristics: 0 MajorVer: 0 MinorVer: 0 Size: 35 RVA: 000e63e0 FileOffset: 000d67e0 CodeView format: RSDS Signature: {fa9c48f9-c11d-4e08-94b8-970decd92c97} Age: 2 PdbFile: wntdll.pdb Debug info: 10 ( Unknown ) TimeStamp: 55a68c18 Characteristics: 0 MajorVer: 565 MinorVer: 6526 Size: 4 RVA: 000e63dc FileOffset: 000d67dc Debug information file: Format: PDB 7.00 Signature: {b081677d-fc72-4cc4-ac53-992627beea24} Age: 4 Writing to the debug information file... Result: Success. 0:005> .shell cmd /c copy E:\debug\temp\ntdllhack\wntdll.pdb E:\debug\symbols\wntdll.pdb\FA9C48F9C11D4E0894B8970DECD92C972\wntdll.pdb 1 file(s) copied. 0:005> .reload Reloading current modules ............................. 0:005> dt nt!_PEB ntdll!_PEB +0x000 InheritedAddressSpace : UChar +0x001 ReadImageFileExecOptions : UChar ... 0:005> !heap -s LFH Key : 0x219ab08b Termination on corruption : DISABLED Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast (k) (k) (k) (k) length blocks cont. heap ----------------------------------------------------------------------------- Virtual block: 00920000 - 00920000 (size 00000000) Virtual block: 02c60000 - 02c60000 (size 00000000) Virtual block: 02e10000 - 02e10000 (size 00000000) ... 

Nota: l’utilizzo di ChkMatch come questo ha il vantaggio che non è necessario triggersre .symopt- 100 , poiché tale opzione influirebbe su tutti i file PDB e non si troveranno potenziali altri problemi relativi ai simboli. Se non ti dispiace usare .symopt , potresti semplicemente copiare un vecchio wntdll.PDB su quello nuovo.

Il problema è ora risolto in base a Microsoft e Microsoft mi ha detto che dovresti cancellare la cache dei simboli per ottenere i nuovi PDB, altrimenti Windbg userebbe i vecchi Simboli che mancano le informazioni.