2011-09-15 16 views
37

Sto riscontrando un problema con alcune mie app. Si tratta di un'applicazione WCF-based che funziona sotto IIS6 in Windows Server 2003 (x86):
Nel registro eventi ottengo un errore del genere da "W3SVC-WP" fonte (EventID = 2262):Cosa fare con "La versione di SOS non corrisponde alla versione di CLR che si sta eseguendo il debug" in WinDbg?

ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'. 

Sono cercando di capire cosa sta succedendo. Ho impostato la creazione di dump per il processo di lavoro orfano come descritto in questo KB. Quando si verifica un deadlock, viene creato un minidump.
Quindi prendo questo minidump per cercare di capire cosa è successo. Ecco che sono bloccato.

corro WinDbg x86, aprire il mio dump e poi:

0:037> .loadby sos clr 
0:037> .sympath SRV*c:\temp\symbols*http://msdl.microsoft.com/download/symbols 
Symbol search path is: SRV*c:\temp\symbols*http://msdl.microsoft.com/download/symbols 
Expanded Symbol search path is: srv*c:\temp\symbols*http://msdl.microsoft.com/download/symbols 
0:037> !clrstack 
The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging. 
CLR Version: 4.0.30319.1 
SOS Version: 4.0.30319.235 
CLRDLL: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll:4.0.30319.235 f:8 doesn't match desired version 4.0.30319.01 f:8 
CLRDLL: Loaded DLL c:\temp\symbols\mscordacwks_x86_x86_4.0.30319.01.dll\4BA1D9EF66f000\mscordacwks_x86_x86_4.0.30319.01.dll 
OS Thread Id: 0x690 (37) 
Unable to walk the managed stack. The current thread is likely not a managed thread. 
You can run !threads to get a list of managed threads in the process 

Cosa fare con questo errore - "La versione di SOS non corrisponde alla versione di CLR il debug"?

Lo stesso errore ("La versione di SOS non corrisponde alla versione di CLR di cui si sta eseguendo il debug") Vengo quando apro il minidump in VS2010.

Ho letto questo post - http://tech-thinker.com/Forums/tabid/62/forumid/12/postid/471/scope/posts/Default.aspx e ho provato a installare KB2518870. Non aiuta

+0

Bel articolo sulla compatibilità SOS/MSCORDACWKS - http://jonathan.dickinsons.co.za/blog/2010/08/windbg-stack-fix/ – Shrike

+0

Questo mi ha aiutato: http://blogs.msdn.com/ b/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-o-what-is-mscordacwks-dll.aspx – Wally

risposta

23

WinDbg non sarà in grado di utilizzare l'adattatore di debug mscordacwks.dll a meno che non sia la stessa versione di quella della macchina originale. È possibile aggirare questo errore copiando questa DLL dal computer di destinazione che ha generato il dump nella directory degli strumenti di debug per Windows.

Eseguiamo il debug di applicazioni .NET 2.0 con WinDbg. Riceviamo continuamente questo stesso errore riguardo a mscordacwks_x86_x86_2.0.50727.3615.dll. Dovevo copiare questo file dal server sul mio client e inserirlo nella cartella C: \ Programmi \ Debugging Tools per Windows (x86) \. WinDbg ha smesso di lamentarsi dopo.

Se tutto il resto fallisce, è possibile provare il debugging con WinDbg sullo stesso server da cui è stato recuperato il dump di arresto anomalo.

+0

grazie. A proposito, sembra che .sympath abbia impostato il percorso fornito a livello globale. – Shrike

41

Questo è ciò che ha funzionato per me:

scaricare i seguenti DLL:

  • clr.dll
  • Mscordacwks.dll
  • Sos.dll

da questa cartella sulla macchina che ha generato il dump:

C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319

Eseguire il seguente comando. Il percorso di SOS.DLL deve essere senza virgolette, delimitatori di percorso senza caratteri di escape:

. Carica percorso SOS scaricato.DLL

Penso che sia necessaria una nuova sessione WinDbg perché funzioni.

+3

Ho usato .load psscor4.dll e ho seguito il tuo consiglio per prendere clr sos e mscordacwks dalla destinazione. Questo l'ha risolto per me. – GregC

+0

Dove posso ottenere le versioni corrette di quelle DLL se non ho accesso alla macchina guasta? Posso individuare quelle DLL dagli aggiornamenti di Windows corretti (ad es. [Questo qui] (http://support.microsoft.com/kb/2898870)) e ho scaricato il file di aggiornamento (.msu). Ma quando decomprimo il file '.msu', sono solo un mucchio di file di taxi. Mi è sembrato di ricordare un sito Web con tutte le versioni dei binari CLR da scaricare. – KFL

6
The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging. 
CLR Version: 4.0.30319.1 
SOS Version: 4.0.30319.235 

Questo significa che la macchina di destinazione che ha reso la discarica è in esecuzione su CLR versione 4.0.30319.1.
Il sistema è in esecuzione con la versione 4.0.30319.235.

Questo perché c'era un aggiornamento di sicurezza su .Net 4.0 che ha modificato i file CLR e SOS. E alcuni computer potrebbero non avere ancora questo aggiornamento.

See: http://support.microsoft.com/kb/2572078

Ciò può causare alcune delle linee nello stack di essere un po 'sbagliato ... È possibile evitare l'errore ottenendo il Sos.dll e CLR.dll e mscordacwks.dll e mscorwks.dll della versione originale e caricare quelli quando si carica il SOS.
I file originali sono normalmente in: C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319
Dipende dalla versione del framework ... e quindi li copia in una cartella specifica.
caricare i file corretti in questo modo:

.load C:\CurrectFiles\sos 

Nota che è solo "sos" e non Sos.dll.

16

Il problema principale in genere consiste in una versione non corrispondente mscordacwks.dll (mscorwks.dll non dovrebbe essere necessaria se è stato eseguito un dump completo). In teoria, dovrebbe essere raggiungibile dal server dei simboli: è sufficiente eseguire .cordll -ve -u -l. Per ulteriori informazioni su mscordacwks.dll, vedere Failed to load data access DLL, 0x80004005” – OR – What is mscordacwks.dll.

Sfortunatamente, alcune versioni di mscordacwks.dll non sono state indicizzate, il che significa che quanto sopra non funzionerà sempre. In questi casi, è possibile provare ad ottenere la versione corretta dalla macchina su cui è stato eseguito il dump, come indicato in Yocahi e Thomas (ad esempio da C:\Windows\Microsoft.NET\Framework64\v4.0.30319). Una volta ottenuto, emettere il seguente comando per caricarlo: .cordll -u -ve -lp PathToFolderContainingMscorDAC. Ovviamente, quella macchina potrebbe essere inaccessibile, oppure potrebbe essere stata riparata dal momento in cui è stata effettuata la discarica.

Fortunatamente, c'è uno way to extract mscorwdacwks.dll from the actual update KB package (risiede in uno dei file cab all'interno del file eseguibile autoestraente - utilizzare uno strumento come 7-Zip per estrarlo). Esistono anche repository di.aggiornamenti NET (per gentile concessione di MS dipendente Doug Stewart), in modo da poterli cercare il numero esatto di costruzione richiedono:

Una volta che hai il corretto mscordacwks.dll, il SOS.dll avviso potrebbe essere ignorato nella maggior parte dei casi, come la più recente versione SOS.dll avrebbe funzionato la maggior parte del tempo nonostante l'avviso. Tuttavia, in alcuni casi è necessaria anche la versione corretta SOS.dll (e come bonus ti sbarazzi delle fastidiose avvertenze). Dunken collegamenti a uno blog post che dovrebbero essere utili a tale riguardo (in pratica è necessario posizionare il server dei simboli nella variabile di ambiente _NT_SYMBOL_PATH ed eseguire !analyze –vsenza caricareSOS.dll prima - caricherà la versione corretta stessa). Se ciò non funziona, puoi provare a estrarre SOS.dll da uno dei pacchetti di aggiornamento come descritto sopra. This site potrebbe rivelarsi più facile da utilizzare a tale scopo, in quanto indicizza in modo specifico le versioni SOS.dll.

Infine, considerare PsscorR2 (per .NET 2.0-3.5) e Psscor4 (per .NET 4.0). Psscor è un superset di SOS.dll che non si lamenta di versioni non corrispondenti, a condizione che si stia utilizzando la versione principale appropriata. Va notato che nel tempo, non è stato mantenuto come pure SOS.dll, quindi quest'ultimo può includere miglioramenti e correzioni di bug assenti dal primo. Al momento della stesura della scrittura non era disponibile la versione Psscor per .NET 4.5.

1

In breve, effettuare le seguenti operazioni:

  1. ottenere la versione CLR formano la discarica
  2. Trovare e scaricare appropriata Microsoft Patch
  3. Estrarre il sos.dll e Mscordacwks.dll da la patch
  4. Usalo

Di seguito è riportato un esempio:

1. Dopo aver caricato un crash dump ottengo la versione che ho bisogno:

>lm vm clr 

mi dà

File version:  4.0.30319.18051 

2. Io google per l'aggiornamento di MS che contiene questa versione:

sos.dll 4.0.30319.18051

In questo caso, google fornisce uno MS KB page con un collegamento per il download. Di solito scarica la versione x64, perché contiene entrambe le DLL x86 e x64, quindi ora ho Windows8-RT-KB2833958-x64.msu.

Nota: a volte è difficile da ottenere la patch necessaria, ma non in questo esempio.

3. Utilizzando FAR file manager estraggo archivio armadietto da questa MSU:

Windows8-RT-KB2833958-x64.cab

Nota: A volte ci sei diversi armadietti all'interno, in modo è necessario verificare quale contiene sos.dll.

Nota: A volte le patch sono distribuiti come .EXE, quindi è necessario prima di estrarre i file MSU o MSP (lo faccio con FAR), e quindi estrarre armadi da loro.

4. A volte i file da CAB può essere estratto di gran lunga, ma a volte hanno struttura molto diversa e utilizzare Expand.exe da WinAIK. WinAIK è 1.7 Gb ISO, ma è necessaria solo una piccola parte. Io uso il seguente file BAT

mkdir Extracted 
..\winaik_amd64\servicing\Expand.exe "%1" -F:sos.dll "Extracted" 
..\winaik_amd64\servicing\Expand.exe "%1" -F:mscordacwks.dll "Extracted" 

Questo comando consente di estrarre tutte le versioni di DLL specifici, ognuno all'interno del proprio dir. A volte ci sono 2 versioni di entrambi mscordacwks.dll e sos.dll. Credo che questo sia dovuto al personale GRD/LDR (QFE). Nel nostro esempio ci sono 4.0.30319. e 4.0.30319. . proprietà controllo del file con Windows Explorer.

5. Rinominare i file in modo appropriato: Mscordacwks.dll devono essere chiamati come mscordacwks_% arco% _% arco% _% versione% .dll e posto vicino al sos.dll

Così Mscordacwks.dll (4.0.30319.18051) va a mscordacwks_AMD64_AMD64_4.0.30319.18051.dll

(versione x86 rinominare in mscordacwks_ x86_x86 _4.0.30319.18051.dll)

sos.dll potrebbe rimanere come è intatto, ma ho rinominarlo in sos.4.0.30319.18051.dll

fare lo stesso per 4.0 .30319.19079 versione (per eventuali esigenze future)

6. Copiare questi file 'C: \ SOS \' cartella che contiene un sacco di sos.4.xxxdll e mscordacwks_AMD64_AMD64_4.xxxdll

7. lo uso con

.load C:\SOS\sos.4.0.30319.18051.dll 

Nota: A volte per .Net 4.5 è necessario aggiungere ulteriori '0' per mscordacwks versione mscordacwks_AMD64_AMD64_4.6.1055. .dll invece di mscordacwks_AMD64_AMD64_4.6.1055. .dll. Non ho scavato più a fondo però, perché potevo gestirlo entro un breve lasso di tempo.

BTW, WinDbg dirà se non è possibile trovare mscordacwks e specificherà la versione (che avrà il doppio '0' alla fine).

Problemi correlati