Como solucionar problemas .NET 2.0 Erro relatar mensagens no log de eventos?
https://stackoverflow.com/questions/814560
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Eu trabalho em um produto de código aberto chamado Evemon Escrito em C# direcionando a plataforma .NET 2.0, tenho um usuário que está sofrendo de uma estranha falha .NET que não conseguimos resolver.
Event Type: Error Event Source: .NET Runtime 2.0 Error Reporting Event Category: None Event ID: 5000 Date: 4/29/2009 Time: 10:58:10 PM User: N/A Computer: removed this Description: EventType clr20r3, P1 evemon.exe, P2 1.2.7.1301, P3 49ea37c8, P4 system.windows.forms, P5 2.0.0.0, P6 4889dee7, P7 6cd3, P8 18, P9 system.argumentexception, P10 NIL. Data: //hex representation of the above Description
O próprio aplicativo trava sem exibir um erro (apesar de ter uma interface do usuário de manuseio de erros), as mensagens acima foram copiadas para fora do log de eventos do Windows. O usuário final reinstalou o .NET e atualizado para as versões mais recentes. Os arquivos .pdb são distribuídos com cada versão de lançamento do programa para ajudar na depuração e teste, o usuário com o problema em questão tem o complemento completo dos arquivos PDB para a versão correta do EVEMN.
Existe uma técnica específica, testada e testada para analisar e diagnosticar esse tipo de falha? E se sim, quais ferramentas e tecnologias estão disponíveis para ajudar na depuração?
Agradecimentos especiais
Eu gostaria de agradecer especial a Steffen Opel e destacar que sua resposta Embora não responda diretamente à pergunta que eu estava fazendo, abordou o problema maior com minha base de código que o manuseio global de erros estava faltando um componente importante.
Solução
É assim que eu resolveria o problema para um usuário final com uma falha.
Baixe e instale ferramentas de depuração para Windows em http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Depois que as ferramentas forem instaladas (elas acabam indo para C: Arquivos de Programas Por padrão) Inicie uma janela da linha de comando.
Altere para o diretório que contém Adplus (por exemplo, "C: Arquivos de Programas Ferramentas de depuração para Windows (x86)").
Execute o comando Follwing. Isso iniciará o aplicativo e anexará o ADPLUS.
adplus -crash -o C:\debug\ -FullOnFirst -sc C:\path\to\your\app.exe
Depois que o despejo de acidente é criado
Depois que o aplicativo trava o Windbg e carregue o arquivo .dmp criado em C: Debug. (Arquivo -> Abra o despejo de falha)
Execute esses comandos para ver o rastreamento da pilha e, esperançosamente, encontrar o problema.
Para carregar SOS para depuração
- Pre .NET 4.0
.loadby sos mscorwks
- .NET 4.0
.loadby sos clr
Para ver o rastreamento da pilha
!clrstack
Para ver um rastreamento mais útil da pilha
!clrstack –p
Para cutucar dentro de um objeto ... talvez veja o que causou a exceção
!do <address>
Por exemplo, este é o resultado de um aplicativo que falhou aleatoriamente com uma exceção de IO. Windbg apontou o caminho que estava sendo referenciado, que estava incorreto.
0:009> !do 017f2b7c
Name: System.String
MethodTable: 790fd8c4
EEClass: 790fd824
Size: 124(0x7c) bytes
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: \\server\path\not_here.txt
Fields:
MT Field Offset Type VT Attr Value Name
79102290 4000096 4 System.Int32 1 instance 54 m_arrayLength
79102290 4000097 8 System.Int32 1 instance 53 m_stringLength
790ff328 4000098 c System.Char 1 instance 5c m_firstChar
790fd8c4 4000099 10 System.String 0 shared static Empty
>> Domain:Value 00161df8:790d884c <<
7912dd40 400009a 14 System.Char[] 0 shared static WhitespaceChars
>> Domain:Value 00161df8:014113e8 <<
Outras dicas
Espiar seu código -fonte (Trunk) indica que seu manuseio de exceções não atendidas parece estar incompleto em relação aos aplicativos do Windows Forms:
Você precisa lidar Ambas Exceções de thread não UI e exceções de threads da interface do usuário:
Para o primeiro, você precisa implementar um manipulador de exceção do CLR não atribuído via
AppDomain.CurrentDomain.UnhandledException, que já está em vigor.Para este último, você precisa implementar um manipulador de exceção não tratado do Windows via
Application.ThreadException, o que parece estar faltando; Isso poderia realmente produzir exatamente os problemas que você está testemunhando. Para um exemplo de implementação, consulte a documentação do MSDN de Application.ThreadException Event.
Observe que agora você suprime explicitamente captura de exceções do Windows não atendidas via Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException), você precisará mudar isso para UnhandledExceptionMode.CatchException Para ativar o roteamento para o seu manipulador para Application.ThreadException, conforme sugerido corretamente por Jeof já.
Qual sistema operacional (Windows XP, Windows Vista, etc.) o usuário usa?
Se o Windows Vista tentar desativar "Relatórios e soluções de problemas" (painel de controle-> Relatórios e soluções de problemas-> Alterar configurações-> Configurações avançadas-> Desative para meus programas, relatórios de problemas)
Ou tente definir
Application.SetUnhandledExceptionMode( UnhandledExceptionMode.CatchException );
Isso sempre direcionará exceções para o manipulador de ThreadException.
Em poucas palavras: há uma exceção não tratada no aplicativo.
Se você tiver acesso à máquina (por meio de acesso remoto, etc.), tente instalar o Visual Studio Express e iniciar o aplicativo. Você deve ver uma caixa de diálogo oferecendo a chance de depurar o aplicativo com uma nova instância do Visual Studio.
Também pode ser que haja algo que impeça a inicialização de formulários do Windows. Vi postagens do fórum que sugerem que os problemas de fonte podem causar isso - verifique se os usuários têm as fontes instaladas de que seu aplicativo precisa, além dos padrões usuais, como MS Sansserif, Arial, Tahoma, Times e Assim como.
E não ... tente sacrificar um frango sobre o PC. Funciona um charme sempre!
Tivemos problemas com exceções no código de threads. Se você gerar um novo thread e esquecer de lidar com uma exceção no método do thread, o aplicativo apenas "para" - sem mensagem de erro, não nada, mas apenas uma entrada no log de eventos. Nem mesmo assim UnhandledExceptionHandler é acionado.
Talvez algo assim seja a causa?
... se você pode entrar em contato com esse usuário sofrido, aqui está um
Ideia: estágios de pré-execução de log
Em vez de fazer um atalho para o seu program.exe, faça um atalho para program.bat, o que vai
echo "Pre-start" > stage.txt
start program.exe
A primeira linha de Program.cs será, portanto,
File.WriteAllLines("stage.txt", "Program execution started.");
No manipulador de AppDomain.UnhandledException A primeira linha será
File.WriteAllLines("stage.txt", "Unhandled exception has been caught.");
Além disso, verifique se o manipulador não aloca memória ou recursos-pré-alocá-los no início dos programas. O manipulador aciona apenas a escrita para o log.
Comentários
É muito provável que o stage.txt (Enviado pelo usuário) conterá "pré-iniciação". Isso acontece quando uma exceção é lançada na 3ª parte .dll - mesmo antes do início do seu programa.
Nesse caso, você precisará de um programa de verificador simples, que não fará referência aos assemblies que você program.exe faz, mas vai Assembly.Load(...) eles.
Ps
stage.txt deve ser colocado em algum lugar sob %AppData %, não nos arquivos de programas.
eu encontrei Um caso interessante no servidor 2003 e Outra boa discussão.
Você deve obter um rastreamento de pilha mais detalhado enviando o .pdb Arquive para esse lançamento específico para o usuário (a ser colocado ao lado do .exe) e fazê -los reproduzir o acidente.
Você deve lidar AppDomain.UnhandledException em código.
Havia um pergunta semelhante Perguntou. Veja os relacionados também.
