Ganter Lab
Iniciar sesión Descargas

Informes de fallo

Qué guarda la estación cuando se cierra de forma inesperada, qué envía y cuándo pregunta, y los dos comandos de depuración que lleva una compilación de desarrollo.

Ver como Markdown

Informes de fallo es la única fila del grupo DIAGNÓSTICO de la página Ajustes. Un fallo no se envía nunca mientras la aplicación se está cayendo: se captura en un archivo, y el arranque siguiente o lo envía o se lo enseña a usted y le pregunta. Esta sección contiene el único interruptor que decide cuál de las dos cosas. La página exige el permiso Cambiar los ajustes.

Enviar los informes de fallo automáticamente

Campo Qué es Valores / valor por defecto Efecto
Enviar los informes de fallo automáticamente "Cuando la aplicación falle, envía el informe en el siguiente arranque sin preguntar. Desactivado: se le enseña el informe y se le pregunta antes." Encendido o apagado. Apagado por defecto. Encendido: el arranque siguiente envía el informe capturado en silencio y lo borra en cuanto el servidor lo acepta. Apagado: el siguiente arranque visible abre el diálogo de consentimiento.

Mientras el runtime está detenido, esta página no se dibuja siquiera (véase Ajustes). La misma aceptación se ofrece dentro del propio diálogo de consentimiento, como la casilla "Enviar siempre los informes de fallo automáticamente", y marcarla allí enciende este interruptor. Bajo el interruptor, la tarjeta dice: "Para informar de un fallo, sugerir una mejora o pedir un controlador, use la página Cuenta." Ese formulario es Avisos, porque se envía con la cuenta Ganter.

Qué contiene un informe

Cuando un error no controlado tumba la aplicación, los manejadores globales escriben un único archivo, crash\pending-crash.json bajo la raíz de datos de la estación, y guardan solo el fallo más reciente. Contiene:

  • la versión de la aplicación y la versión de Windows;
  • dónde se capturó el error (Dispatcher, AppDomain, TaskScheduler, o Startup para un arranque que no llegó a terminar);
  • el tipo de la excepción, su mensaje y el texto completo de la pila, con las excepciones internas incluidas;
  • las últimas 60 líneas del archivo de diario más reciente, como contexto que lleva al fallo;
  • el momento en que ocurrió.

Antes de escribirlo, el nombre de usuario de Windows y la ruta del perfil se sustituyen por <user> y <userprofile> dondequiera que aparezcan. Ese saneamiento es una red de seguridad, no una garantía: las líneas de diario de texto libre pueden llevar otros nombres, y por eso el diálogo muestra la carga útil entera antes de que salga nada.

Con el interruptor apagado, el primer arranque visible tras un fallo abre ¿Enviar el informe de fallo? sobre el shell: "Ganter Lab se cerró de forma inesperada la última vez. Enviar este informe nos ayuda a corregirlo. Contiene el error y un fragmento breve del diario técnico reciente. Revíselo abajo antes de enviarlo." El cuadro Detalle del fallo muestra exactamente lo que se enviaría, con un botón Copiar que pone ese mismo texto en el portapapeles ("Copiado" durante un momento) para que usted lo pueda buscar o entregárselo al soporte. Si el portapapeles se niega, el botón dice "No se pudo copiar", para que una copia que no ocurrió no se tome por una que sí; el texto sigue en pantalla para seleccionarlo a mano.

Comando Qué hace Atenuado cuando (situación) No se dibuja cuando (rol)
Enviar siempre los informes de fallo automáticamente (casilla) Enciende el interruptor de arriba cuando el diálogo se cierra, envíe usted este informe o no. Mientras el runtime está detenido (información emergente "Runtime detenido"). El diálogo pertenece al shell, así que se dibuja igualmente cuando esta página no. Nunca.
No enviar Descarta este informe y borra el archivo; no se le vuelve a preguntar por él. Nunca. Nunca.
Enviar el informe Lo envía. "Informe de fallo enviado" como notificación al lograrlo; "Informe de fallo no enviado" con el motivo cuando no se pudo alcanzar el servidor, en cuyo caso el archivo se queda y usted lo puede enviar ahora o se le vuelve a preguntar en el arranque siguiente. Nunca. Nunca.

Un arranque oculto en el área de notificación (Arrancar con Windows, o un lanzamiento con --tray) no muestra ningún diálogo; el informe espera al siguiente arranque visible. Con el interruptor encendido, el envío ocurre en segundo plano sin ningún diálogo, y una estación que estaba sin conexión guarda el archivo y lo vuelve a intentar en el arranque siguiente.

El informe va al punto de conexión de avisos del servidor de Ganter. Se atribuye a la cuenta Ganter con la sesión iniciada en la página Cuenta cuando la hay, y se acepta sin cuenta cuando no. No sale nada más de la estación: no hay telemetría de uso.

Los comandos de depuración

Una compilación de desarrollo de la aplicación lleva dos botones bajo el interruptor; una versión instalada no lleva ninguno.

Comando Qué hace Atenuado cuando (situación) No se dibuja cuando (rol)
Simular un fallo (depuración) Lanza un error no controlado en el hilo de la interfaz para que el camino de captura escriba un archivo de fallo de verdad y el arranque siguiente ejercite el flujo de consentimiento. Nunca. No en una compilación de versión.
Capturar la pantalla (depuración) Ejecuta la misma captura de pantalla que usan las herramientas de interfaz del agente, dentro del proceso, e imprime el resultado bajo el botón: "Guardada: <ruta>" o "La captura falló: <motivo>". En un host sin ventana, el resultado dice que la captura no está disponible. Nunca. No en una compilación de versión.

Lo que esta sección no hace

Aquí no hay ningún visor de diario: el diario vive en Eventos, en su pestaña Consola, junto con la captura de diagnóstico y el paquete de soporte. Los avisos de fallos y las peticiones están en Avisos. El archivo de fallo no se puede editar desde la aplicación, y la aplicación no envía nunca nada sin el interruptor o sin el Enviar del diálogo.