Ganter Lab
Entrar Baixar

Relatórios de falha

O que a estação guarda quando fecha de forma inesperada, o que ela envia e quando pergunta, e os dois comandos de depuração que uma compilação de desenvolvimento carrega.

Ver como Markdown

Relatórios de falha é a única linha do grupo DIAGNÓSTICO na página Configurações. Uma falha nunca é enviada enquanto o aplicativo está caindo: ela é capturada num arquivo, e a partida seguinte ou a envia ou a mostra a você e pergunta. Esta seção guarda a única chave que decide qual das duas. A página exige a permissão Alterar configurações.

Enviar relatórios de falha automaticamente

Campo O que é Valores / padrão Efeito
Enviar relatórios de falha automaticamente "Quando o aplicativo falhar, envia o relatório na próxima inicialização sem perguntar. Desligado: o relatório é mostrado e a pergunta vem antes." Ligada ou desligada. Desligada por padrão. Ligada: a partida seguinte envia o relatório capturado em silêncio e o limpa assim que o servidor o aceita. Desligada: a próxima partida visível abre o diálogo de consentimento.

Enquanto o runtime está parado esta página não é desenhada (veja Configurações). A mesma adesão é oferecida dentro do próprio diálogo de consentimento, como a caixa de seleção "Enviar sempre os relatórios de falha automaticamente", e marcá-la ali liga esta chave. Sob a chave o cartão diz: "Para relatar um defeito, sugerir uma melhoria ou pedir um driver, use a página Conta." Esse formulário é o Sua opinião, porque ele envia com a conta Ganter.

O que um relatório contém

Quando um erro não tratado derruba o aplicativo, os tratadores globais escrevem um arquivo, crash\pending-crash.json sob a raiz de dados da estação, e guardam só a falha mais recente. Ele guarda:

  • a versão do aplicativo e a versão do Windows;
  • onde o erro foi capturado (Dispatcher, AppDomain, TaskScheduler, ou Startup para uma partida que não terminou);
  • o tipo da exceção, a mensagem dela e o texto completo da pilha, com as exceções internas incluídas;
  • as últimas 60 linhas do arquivo de log mais novo, como contexto que leva à falha;
  • o momento em que ela aconteceu.

Antes de o arquivo ser escrito, o nome de usuário do Windows e o caminho do perfil são substituídos por <user> e <userprofile> onde quer que apareçam. Essa limpeza é uma rede de segurança, não uma garantia: linhas de log em texto livre podem carregar outros nomes, e é por isso que o diálogo mostra a carga inteira antes de qualquer coisa sair.

Com a chave desligada, a primeira partida visível depois de uma falha abre Enviar o relatório de falha? sobre o shell: "O Ganter Lab fechou de forma inesperada na última vez. Enviar este relatório ajuda a corrigir o problema. Ele contém o erro e um trecho curto do diário recente. Revise o conteúdo abaixo antes de enviar." A caixa Detalhe da falha mostra exatamente o que seria enviado, com um botão Copiar que põe o mesmo texto na área de transferência ("Copiado" por um instante) para você poder pesquisá-lo ou entregá-lo ao suporte. Se a área de transferência recusar, o botão passa a dizer "A cópia não funcionou", para que uma cópia que não aconteceu não seja tomada por uma que aconteceu; o texto continua na tela para você selecionar à mão.

Comando O que ele faz Esmaecido quando (situação) Não aparece quando (papel)
Enviar sempre os relatórios de falha automaticamente (caixa de seleção) Liga a chave acima quando o diálogo fecha, tenha você enviado este relatório ou não. Enquanto o runtime está parado (dica "Runtime parado"). O diálogo pertence ao shell, então ele ainda é desenhado quando esta página não é. Nunca.
Não enviar Descarta este relatório e limpa o arquivo; você não é perguntado de novo sobre ele. Nunca. Nunca.
Enviar o relatório Envia o relatório. "Relatório de falha enviado" como notificação no sucesso; "Relatório de falha não enviado" com a razão quando o servidor não pôde ser alcançado, caso em que o arquivo fica e você pode enviá-lo agora ou é perguntado de novo na partida seguinte. Nunca. Nunca.

Uma partida escondida na área de notificação (o Iniciar com o Windows, ou uma abertura com --tray) não mostra diálogo nenhum; o relatório espera pela próxima partida visível. Com a chave ligada, o envio acontece em segundo plano sem diálogo, e uma estação que estava offline guarda o arquivo e tenta de novo na partida seguinte.

O relatório vai para o endpoint de feedback do servidor da Ganter. Ele é atribuído à conta Ganter autenticada na página Conta quando há uma, e aceito sem conta no resto dos casos. Nada mais sai da estação: não há telemetria de uso.

Os comandos de depuração

Uma compilação de desenvolvimento do aplicativo carrega dois botões sob a chave; uma versão instalada não carrega nenhum dos dois.

Comando O que ele faz Esmaecido quando (situação) Não aparece quando (papel)
Simular uma falha (depuração) Lança um erro não tratado na thread da interface, para que o caminho de captura escreva um arquivo de falha de verdade e a partida seguinte exercite o fluxo de consentimento. Nunca. Não numa compilação de versão.
Capturar tela (depuração) Roda a mesma captura de tela que as ferramentas de interface do agente usam, dentro do processo, e escreve o resultado sob o botão: "Salvo: <path>" ou "Falha na captura: <reason>". Num hospedeiro sem janela, o resultado diz que a captura está indisponível. Nunca. Não numa compilação de versão.

O que esta seção não faz

Não há visualizador de log aqui: o diário mora nos Eventos, na aba Console deles, junto com a captura de diagnóstico e o pacote de suporte. Os relatos de defeito e os pedidos estão em Sua opinião. O arquivo de falha não é editável pelo aplicativo, e o aplicativo nunca envia nada sem a chave ou sem o Enviar do diálogo.