La pregunta

Hay muchas formas manuales de hacer que WinDBG encuentre mscordacwks.dll sin un almacén de símbolos (colocando el archivo en la ruta en algún lugar, colocándolo en la misma carpeta que windbg.exe, colocándolo en mi carpeta Framework \ v, especificando la ruta en WinDBG utilizando.cordll -lp c:\dacFolder, etc.), pero todos ellos solo lo arreglan parayo. Necesito arreglarlo mas generalmente paratodos los que usan mi tienda de símbolos.

Las posibles soluciones que puedo imaginar son:

WinDBG debe hacerse para verificar el almacén de símbolos usando el nombre de la subcarpeta mscordacwks.dll en lugar del nombre de la carpeta mscorwks.dll.Se debe crear SymStore.exe para agregar mscordacwks.dll bajo el nombre de la subcarpeta mscorwks.dll, de modo que WinDBG lo encuentre cuando lo busque.

Q:¿Alguna de estas cosas es posible, o hay otra forma en la que no estoy pensando para resolver el problema?

El fondo

Al analizar un proceso .NET, encontré el problema (aparentemente común) de que psscor2 (y sosex) no pudieron encontrar el mscordacwks.dll apropiado en mi máquina. El error en WinDBG es:

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.

Hay un montón de preguntas de SO sobre esto y muchas buenas respuestas, prácticamente todas las cuales en última instancia hacen referencia a la destacada publicación de blog de Doug Stewart,¿Qué es el archivo mscordacwks.dll?.

Gracias a eso, resolví mi situación obteniendo el mscordacwks.dll correcto y colocándolo aquí:

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

donde sabía que WinDBG se vería porque lo había probado anteriormente con!sym noisy.

Así que ya estoy listo, pero tuve que ponerlo físicamente en esa ruta en lugar de agregarlo a mi servidor de símbolos a través de lo normal.symstore.exe mecanismo. Ya que mi tienda de símbolos es utilizada por más que solo yo, necesito hacerlo de la manera correcta para que todos los demás usen la tienda.

Y ese es el problema. Cuando agrego usandosymstore.exe En lugar de entrar en el camino anterior, entra en:

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

La única diferencia es que el nombre de la subcarpeta es4E1545CB1bd000 aquí en lugar de la4E1545829a3000 que WinDBG está buscando.

La razón de esto es que al agregar un binario al almacén de símbolos,symstore.exe utiliza el PE del binario para obtener la marca de tiempo de la imagen y el tamaño de la imagen. En el caso de este .dll particular,dumpbin.exe /headers mscordacwks.dll revela que estos son:

marca de tiempo de la imagen:0x4E1545CB (Jue 07 de julio 01:36:11 2011)tamaño de la imagen:0x1BD000

Por lo tanto, el nombre de la subcarpeta4E1545CB1BD000.

Lo que WinDBG está buscando, por otro lado, es una subcarpeta basada en la marca de tiempo de la imagen y el tamaño de la imagen demscorwks.dllnomscordacwks.dll, porque el primero se carga en el proceso, no el segundo. WinDBG no puede saber la marca de tiempo y el tamaño del módulo DAC porque ese módulo no está en el volcado de proceso.

Como verificación adicional de esta explicación,dumpbin.exe /headers mscorwks.dll revela:

marca de tiempo de la imagen:0x4E154582 (Jue 07 de julio 01:34:58 2011)tamaño de la imagen:0x9A3000

que puedes ver sumar al nombre de la subcarpeta4E1545829A3000.

Sabiendo esto, ahora tiene mucho más sentido por qué todas estas muchas versiones de mscordacwks.dll que la gente sigue encontrando parece que faltan en los servidores de símbolos de Microsoft. Estoy seguro de que están allí, es solo que WinDBG y psscor2 no pueden encontrarlos porque están escogiendo el nombre de subcarpeta incorrecto. ¡Por qué incluso molesta buscar el camino de los símbolos me supera, ya que está garantizado que nunca lo encontrará!

Así que ese es mi reto. Puedo forzar de alguna manerasymstore.exe agregar mscordacwks.dll usando la información de PE de mscorwks.dll? Si no, me estoy perdiendo algo sobre WinDBG y psscor2, podría haber una manera de que ellos conozcan la marca de tiempo y el tamaño correctos de mscordacwks.dll aunque no esté cargado (y una forma de que realmente usen esos en lugar de mscorwks.dll) )?