Por que há símbolos carregados quando depuração remota?
-
02-07-2019 - |
Pergunta
Eu quero usar a depuração remota. O programa que eu quero depuração é executado na máquina b. Visual Studio é executado na máquina de um.
Na máquina b Eu tenho uma pasta com os seguintes arquivos:
- msvcr72.dll
- msvsmon.exe
- NatDbgDE.dll
- NatDbgDEUI.dll
- NatDbgEE.dll
- NatDbgEEUI.dll
Se você acha que alguns arquivos estão faltando, você também pode descrever o local onde eles geralmente estão localizados?
Na próxima etapa, eu comecei a msvsmon.exe
e meu programa na máquina b. Na máquina, comecei Visual Studio 2008 e minha solução em que o programa foi escrito. Então eu escolher "Debug - Anexar ao processo". Eu escolhi "Transporte remoto (Native Apenas sem autenticação)". Eu usei o IP correto como um qualificador e levou o processo de direita (program.exe). Depois de um tempo a seguinte mensagem ocorreu em uma janela pop-up:
Excepção em 0x7c812a7b em program.exe: 0xE0434F4D: 0xe0434f4d
eu possa continuar ou quebrar; Ao continuar, a exceção ocorre novamente e novamente e novamente. Então eu pressionei pausa e a seguinte mensagem ocorreu:
Não símbolos são carregados para qualquer quadro de pilha de chamadas. O código fonte não pode ser exibida.
Solução
Certifique-se de copiar o arquivo .PDB que é gerado com a sua montagem na mesma pasta na máquina remota. Isso permitirá que o depurador para pegar os símbolos de depuração.
Outras dicas
- Adicionar uma pasta compartilhada em sua máquina dev que aponta para a localização dos arquivos .PDB
- Configurar uma variável de ambiente chamada
_NT_SYMBOL_PATH
na máquina remota que aponta para a pasta compartilhada em sua máquina dev
O depurador remoto irá agora procurar sua máquina dev para símbolos. Não há necessidade de copiá-los para cada compilação.
Veja MS Vídeo aqui .
começar a assistir 8-9 minutos. Ele demonstra como configurar o depurador remoto para símbolos de carga de um compartilhamento de unidade em sua máquina de desenvolvimento.
Boa sorte!
- No menu Ferramentas no Visual Studio 2010, escolha Opções.
- Na caixa de diálogo Opções, abra o nó de depuração e, em seguida, clique generais.
- Verifique Mostrar todos os ajustes se necessário, e localizar Ativar Just My Code (Conseguiu apenas)
- desmarque- e clique em OK
Depois você pode anexar o processo remoto
depuração remota no .NET não vai funcionar se você não colocar os ficheiros.PDB no mesmo diretório , onde existe o código depurado.
Se VS ainda não pode encontrar fonte de depuração, o código depurado ea fonte projeto VS são não a mesma versão . A solução é reconstruir e reimplantar o projeto.
0xE0434F4D é uma exceção do CLR (ou seja, o código gerenciado). Você precisa fazer depuração remota com autenticação e escolha para depurar código gerenciado. Como alternativa, é possível extrair as informações de exceção gerenciada usando algumas extensões de depurador mas é um trabalho um pouco mais difícil.
Referências:
1800 INFORMATION está certo, você tem que fazer remoto depuração com a autenticação do Windows, a fim de depurar código gerenciado, caso contrário você não será capaz de carregar os símbolos para os conjuntos gerenciados. Começar este trabalho com a autenticação é bastante complicado, pois exige contas locais em ambas as máquinas com senhas idênticas, entre outras coisas. Esta pergunta e as respostas de cada um são bastante úteis para conseguir que o trabalho.
depuração remota no Visual Studio (VS2008), Windows Forms aplicação
Eu tive os mesmos problemas. Encontrou a resposta nos fóruns MSDN vou apenas copiar / colar a resposta correta aqui:
Certifique-se de que você está usando o versão correta do msvsmon.exe !!! Isso é tudo o que era! Eu tive o mesmo problema, enquanto remoto depuração de um C # inscrição. Eu estava usando x64 msvsmon.exe porque o servidor é executado Windows Server 2008 64-bit, mas o aplicativo foi escrito para x86, então eu teve que correr a versão x86 do msvsmon.exe, a fim de se livrar de este erro irritante. Nada mais era necessário. Basta executar a versão do msvsmon.exe que corresponde à arquitectura alvo de sua aplicação ^ _ ^
Enquanto as respostas acima estão corretas, eu corri para casos em que os PDBs que foram construídas com a montagem que está sendo depurado estavam no local no local remoto, e não estavam sendo apanhados. Se você estiver usando TFS ou outro mecanismo de construção que suporta publicação de seus símbolos de depuração, eu recomendo fazê-lo. Em seguida, no Visual Studio Opções> Depuração> Símbolos você pode adicionar esse local para a opção Servidores Símbolo para carregar os símbolos a qualquer momento eles são encontrados para jogo.
Isto permitiu-me depurar darned perto de qualquer coisa que esteja executando o que eu escrevi, mesmo que seja um chamado dinamicamente durante a montagem (algo que eu não poderia começar a trabalhar para a vida de mim quando apenas a publicação de símbolos com a montagem). Fazer uso deste recurso muito útil!
Eu era capaz de começar este trabalho, indo para Projeto Properties, guia Compilar e definir o caminho de saída de compilação para a minha máquina por exemplo remoto \ Myserver \ myshare \ myappdir
Na guia depuração Eu tenho Use máquina remota verificado e pronto para myserver
Eu também corri para este quando se utiliza um costume construção de configuração . ( DEV em vez de depuração )
Para corrigir isso, eu modifiquei Propriedades do projeto -> Build -> Saída -> configuração avançada e garantiu a saída -> Configuração de informações de depuração foi completo ou pdb- única . O padrão Release configuração é normalmente definida como nenhum .
Vá para Ferramentas> Opções> Debugging-> Símbolos e adicione o caminho para os arquivos PDB para o executável. O caminho na minha máquina local funcionou bem.
De acordo com a documentação, para geridos (eu tentei ligar para um serviço gerenciado do Windows (construída contra .net 4.5) na máquina remota com o visual studio 2012) os símbolos devem ser no telecomando máquina.
símbolos Então, eu continuei (certifique-se eles correspondem aos módulos / assembléias do aplicativo na máquina remota) na máquina remota, compartilhá-lo e se refere a ele através das definições de símbolo de sistema local (onde vs é executado).
Nota:. O serviço e símbolos não precisam estar no mesmo diretório que o seu trabalho para mim com um serviço 2k12 + .net 4,5 janelas
para mais detalhes:
http://msdn.microsoft. com / en-us / library / bt727f1t (v = vs.100) .aspx
Trecho do link:
Símbolo de Localização (PDB) Arquivos
arquivos
símbolo contêm as informações de depuração para executáveis ??compilados. Os arquivos de símbolos do aplicativo a ser depurado devem ser os arquivos que foram criados quando os executáveis ??de aplicação foram compilados. Os arquivos de símbolo também deve ser localizado onde o depurador pode encontrá-los.
• Os arquivos de símbolos para aplicações nativas devem estar localizados no computador host Visual Studio.
• Os arquivos de símbolos para aplicativos gerenciados deve estar localizado no computador remoto.
• Os arquivos de símbolos para aplicações mistas (gerenciado e nativo) deve estar localizado no computador anfitrião do Visual Studio e o computador remoto.
Saudações!
Eu corri para este problema e as soluções acima não corrigi-lo para mim. No meu caso, a minha solução VS2010 tinha muitos projetos na mesma. O projeto que eu estava tentando depurar remotamente era não definido na minha solução VS2010 como o projeto de inicialização, porque meus criar programas não eram muito certo.
Eu cliquei direito sobre o projeto dentro de minha solução que eu estava tentando depurar e selecionado Set as StartUp Project
e depois meus símbolos carregado corretamente e meu ponto de interrupção foi atingido.
Eu tive o mesmo problema durante a depuração remota, ele ficou resolvido com as seguintes etapas no VS 2008:
- você copiar o arquivo pdb local, juntamente com seus binários
- Executar a mesma versão do msvmon como seu aplicativo foi construído para, se seu aplicativo é construído para a arquitetura x86, você precisa executar a versão x86 do msvmon, mesmo se você estiver executando-o em máquina x64. Ele lhe dará aviso ao tentar correr, mas ele deve ser executado.