Conforme dei uma prévia no post anterior, encontrei alguns problemas para analisar um Dump gerado em um servidor que rodava Windows Server 2003 SP2 64Bits em uma máquina rodando Windows 7 Ultimate 64bits.
Obs: Só tive este problema, pois não possuia uma VM ou uma máquina disponível com o mesmo Sistema Operacional do servidor, ou pelo menos o mesmo framework .net montado na mesma arquitetura. Se voce tiver como montar um ambiente semelhante ou ao menos parecido, vale a pena perder um pouquinho de tempo e deixar este ambiente na manga para utilizações futuras.
Geralmente, tudo que encontramos na internet é que um dump gerado em uma máquina com sistema operacional 64 Bits deve ser analisado em outra máquina 64 Bits de mesma arquitetura, porém a coisa não é bem assim.
Logo ao carregar a extensão SOS.dll (extensão para debugar aplicações gerenciadas do .net) e tentar verificar as Threads da aplicação e o seguinte erro apareceu na minha tela:
0:000> .load C:\Windows\Microsoft.NET\Framework64\v2.0.50727\sos.dll
0:000> !threads
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___.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.
Conforme está descrito no Erro ao verificar a versão da DLL do servidor e de minha máquina local confirmei que as dlls do framework eram de versões diferentes mesmo ambos sendo 64 Bits e com o framework 3.5 instalados:
Tentei baixar e instalar o Framework novamente no Windows 7 e até mesmo alterar a versão do arquivo manualmente (gambiarra), mas nenhuma dessas alternativas deu certo. O framework .Net que vem por padrão no Windows 7 é definitivamente de uma versão mais atual do que os disponíveis para downloads em outros SO's. (O "porquê" fica para uma próxima pesquisa e um novo post 
).
Como tinha acesso ao servidor para obter as dll's (não podia analisar o Dump no Servidor por motivos de performance) tive a idéia de tentar trazê-las a minha máquina, sobrescrevendo as dll's do framework atual.
O primeiro imprevisto que temos no caminho é que desde o Windows Vista os arquivos de sistema são gerenciados pelos TrustedInstaller, um serviço que roda no Windows e cuida da instalação de módulos e gerenciamento de arquivos de sistemas. Esse serviço pode ser desabilitado através do services.msc (ou simplesmente Services no Windows 7) -> Instalador de Módulos do Windows, porem desabilitá-lo não é recomendado já que ele garante a integridade dos arquivos de sistema do Windows.
Para não desabilitar o serviço fiz o seguinte para as 4 dll's de sistema utilizadas no debug de aplicações gerenciadas (mscordacwks, mscorlib, mscorwks, sos):
takeown /f C:\Windows\Microsoft.NET\Framework64\v2.0.50727\sos.dll
cacls C:\Windows\Microsoft.NET\Framework64\v2.0.50727\sos.dll /G username:F
Com estes comandos voce passa a ter passa a ter permissões sobre as dlls desejadas.
Tendo permissão sobre as dll's, fiz backup das minhas dll's atuais e as sobrescrevi com as que eu obtive do servidor.
Feito tudo isso é só abrir o WinDBG novamente carregar a "nova" SOS.dll e PRONTO. É Navegar e se divertir no seu dump.
Espero ter ajudado.
Até o próximo post!