A questão

Há várias maneiras manuais de fazer o WinDBG localizar mscordacwks.dll sem um repositório de símbolos (colocando o arquivo no caminho em algum lugar, colocando-o na mesma pasta que o windbg.exe, colocando-o na pasta Framework \ v, especificando o caminho em WinDBG usando.cordll -lp c:\dacFolder, etc.), mas todos eles só consertammim. Eu preciso corrigi-lo mais geralmente paratodos que usam meu repositório de símbolos.

As possíveis soluções que posso imaginar são:

WinDBG ser feito para verificar o armazenamento de símbolo usando o nome da subpasta do mscordacwks.dll em vez do nome da pasta do mscorwks.dll.SymStore.exe ser feito para adicionar mscordacwks.dll sob o nome da subpasta do mscorwks.dll assim WinDBG encontra quando parece lá.

Q:Alguma dessas coisas é possível, ou existe outra maneira que não estou pensando em resolver o problema?

O fundo

Ao analisar um processo .NET, eu encontrei o problema (aparentemente comum) que psscor2 (e sosex) não conseguiu encontrar o mscordacwks.dll apropriado na minha máquina. O erro no WinDBG é:

Failed to load data access DLL, 0x80004005 
Verify that 1) you have a recent build of the debugger (6.2.14 or newer) 
            2) the file mscordacwks.dll that matches your version of mscorwks.dll is 
                in the version directory 
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path. 
            4) you are debugging on the same architecture as the dump file. 
                For example, an IA64 dump file must be debugged on an IA64 
                machine.

You can also run the debugger command .cordll to control the debugger's 
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload. 
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable 
path is pointing to mscorwks.dll as well.

Há muitas perguntas sobre isso e muitas boas respostas, praticamente todas as quais, em última análise, fazem referência ao excelente post de Doug Stewart,O que é um arquivo mscordacwks.dll?.

Graças a isso, eu tenho a minha situação toda endireitada obtendo o mscordacwks.dll correto e colocando-o aqui:

"C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"

onde eu sabia WinDBG ficaria porque eu tinha tentado anteriormente com!sym noisy.

Então, estou tudo pronto agora, mas tive que colocá-lo nesse caminho fisicamente ao invés de adicioná-lo ao meu servidor de símbolo através do normalsymstore.exe mecanismo. Como meu repositório de símbolos é usado por mais do que apenas eu, preciso fazê-lo da maneira certa para todos os outros usuários da loja.

E esse é o problema. Quando adiciono usandosymstore.exe em vez de entrar no caminho acima, ele entra em:

"C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545CB1bd000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"

A única diferença é que o nome da subpasta é4E1545CB1bd000 aqui em vez do4E1545829a3000 que o WinDBG está procurando.

A razão para isso é que ao adicionar um binário ao armazenamento de símbolos,symstore.exe usa o PE do binário para obter o registro de data e hora da imagem e o tamanho da imagem. No caso deste .dll particular,dumpbin.exe /headers mscordacwks.dll revela que estes são:

timestamp da imagem:0x4E1545CB (Qui Jul 07 01:36:11 2011)tamanho da imagem:0x1BD000

Portanto, o nome da subpasta4E1545CB1BD000.

O que o WinDBG está procurando, por outro lado, é uma subpasta baseada no timestamp da imagem e no tamanho da imagem demscorwks.dll, nãomscordacwks.dll, porque o primeiro é carregado no processo, não o último. O WinDBG não pode saber o registro de data e hora e o tamanho do módulo DAC porque esse módulo não está no dump do processo.

Como verificação adicional desta explicação,dumpbin.exe /headers mscorwks.dll revela:

timestamp da imagem:0x4E154582 (Qui jul 07 01:34:58 2011)tamanho da imagem:0x9A3000

que você pode ver, adicione o nome da subpasta4E1545829A3000.

Sabendo disso, agora faz muito mais sentido porque todas essas muitas versões do mscordacwks.dll que as pessoas continuam correndo parecem estar ausentes dos servidores de símbolos da Microsoft. Tenho certeza de que eles estão lá, é só que o WinDBG e psscor2 não podem encontrá-los porque estão escolhendo o nome da subpasta errada. Por que até incomoda procurar o caminho dos símbolos está além de mim já que é garantido que nunca o encontre!

Então esse é o meu desafio. Posso de alguma forma forçarsymstore.exe adicionar mscordacwks.dll usando as informações PE de mscorwks.dll? Se não, estou faltando alguma coisa sobre WinDBG e psscor2, pode haver uma maneira para que eles saibam o timestamp correto e tamanho de mscordacwks.dll, embora não seja carregado (e uma maneira para que eles realmente usam os em vez de mscorwks.dll )