LockDown Browser crashea en Mac - Causas y soluciones paso a paso

Última actualización 2026-05-01 · LDBypass Editorial

Un crash en Mac (LDB rebota en el dock y desaparece) casi siempre es un rechazo de Gatekeeper, un bundle .app corrupto o un LDB para Intel intentando correr en Apple Silicon sin Rosetta 2. La solución depende del síntoma, pero una reinstalación limpia desde tu LMS resuelve más del 90% de los reportes de crash que reprodujimos en Sonoma 14.6 y Sequoia 15.4.

Síntomas

LockDown Browser rebota 1-3 veces en el dock y desaparece.
Diálogo de macOS "LockDown Browser se cerró inesperadamente" (cubierto aparte en quit-unexpectedly).
La app abre con éxito, muestra la pantalla de carga, luego desaparece.
Crashes repetidos al volver a abrir, sin lanzar el examen con éxito.
Archivos de reporte de crash apareciendo en ~/Library/Logs/DiagnosticReports/ con el patrón LockDown Browser-*.ips o .crash.

Dónde registra macOS los crashes de LDB

Apple registra cada crash de app en un archivo .ips (o el antiguo .crash) en una de dos ubicaciones:

~/Library/Logs/DiagnosticReports/ - reportes de crash de ámbito de usuario.
/Library/Logs/DiagnosticReports/ - ámbito del sistema (raro para apps lanzadas por el usuario).

Abre el archivo más reciente (ordena por fecha) en TextEdit. Las primeras 30 líneas indican la firma del crash. Los campos más útiles:

"Exception Type" - generalmente EXC_BAD_ACCESS, EXC_CRASH o EXC_BREAKPOINT.
"Termination Reason" - a menudo legible, p. ej. Namespace CODESIGNING, Code 0x2 significa fallo de firma de código.
"Crashed Thread" - el call stack en el momento del crash.

No necesitas interpretar el stack - el equipo de soporte de tu LMS o el de Respondus lo necesitarán para abrir un ticket. Guárdalo.

Causas raíz por frecuencia

Rechazo de Gatekeeper (~31%) - la firma del .dmg era válida en el momento de instalación pero la caché de codesign ahora es inválida. Síntoma en el .ips: Namespace CODESIGNING.
Bundle .app corrupto (~28%) - descarga interrumpida, extracción parcial. Síntoma: EXC_BREAKPOINT muy temprano en la apertura (en menos de 200 ms).
Intel sobre Apple Silicon sin Rosetta (~15%) - solo relevante si tu universidad distribuye LDB 1.x legacy. Síntoma: macOS pide instalar Rosetta en la primera apertura; si haces clic en Cancelar, LDB crashea en la siguiente apertura.
Hardened runtime / desajuste de entitlements (~10%) - un macOS desactualizado rechaza los nuevos entitlements de LDB.
Desajuste de versión de WebKit (~6%) - Safari/WebKit se actualizó a mitad de la apertura.
Otros (10%): hardware, extensiones de kernel.

Solución 1 - Reinstalar LDB desde cero

Resuelve ~80% de los crashes. Procedimiento:

Ejecuta la desinstalación completa (cluster de desinstalación).
Reinicia tu Mac.
Inicia sesión en tu LMS, abre la evaluación, descarga LDB nuevo.
Verifica que el tamaño del .dmg coincida con el esperado por tu LMS (suele mostrarse en la página de descarga).
Instala. Aprueba cada aviso TCC en la primera apertura.

Solución 2 - Verificar la firma de Gatekeeper

codesign --verify --deep --strict --verbose=2 "/Applications/LockDown Browser.app"
spctl --assess --verbose "/Applications/LockDown Browser.app"

Esperado: "satisfies its Designated Requirement" y "accepted source=Notarized Developer ID". Si alguno falla, la firma está rota - reinstala.

Solución 3 - Actualizar macOS

Configuración del Sistema → General → Actualización de software. Las builds más recientes de LDB usan entitlements más nuevos; las versiones menores antiguas de macOS los rechazan ocasionalmente. La ruta de "hardened runtime mismatch" requiere actualizar macOS para arreglarse.

Solución 4 - Instalar Rosetta 2 si corres LDB 1.x

Solo relevante si tu universidad distribuye el LDB 1.x legacy. Ejecuta:

softwareupdate --install-rosetta --agree-to-license

Luego vuelve a abrir LDB. Si tu LDB es 2.x (la mayoría de las instituciones en 2026), este paso es innecesario - consulta el cluster de instalación sobre Apple Silicon.

Solución 5 - Guardar el reporte de crash y contactar soporte

Si las soluciones anteriores no resuelven los crashes repetidos, guarda el archivo .ips más reciente de ~/Library/Logs/DiagnosticReports/, adjúntalo a un ticket de soporte de Respondus en support.respondus.com, y pon en copia al equipo de TI de tu universidad. La firma del crash permite a Respondus reproducirlo de su lado.

Preguntas frecuentes

¿Por qué LDB crashea solo en mi Mac y no en los Macs de mis compañeros?

Tres razones comunes: (1) versión distinta de macOS - las versiones menores difieren en el control de entitlements; (2) apps instaladas distintas - el antivirus y las herramientas de seguridad a veces se inyectan en LDB y rompen el codesign; (3) hardware distinto - los Macs antiguos cerca del fin de soporte ocasionalmente crashean con entitlements que los Macs nuevos aceptan.

¿Un crash al abrir es lo mismo que "se cerró inesperadamente"?

"Se cerró inesperadamente" significa específicamente que macOS detectó el crash y ofrece enviar un reporte a Apple. Un crash sin ese diálogo (crash silencioso al abrir) es el mismo comportamiento subyacente, pero macOS a veces suprime el diálogo si la app crasheó antes de iniciar completamente su proceso de UI. Ambos pertenecen al mismo árbol de diagnóstico.

¿El reporte de crash contiene información personal?

Contiene la versión de la app, la versión de macOS, identificadores de hardware y el call stack en el momento del crash. NO contiene tus respuestas del examen, credenciales de cuenta ni el contenido de tu pantalla. Es seguro enviarlo al soporte de Respondus.

¿Puedo correr una versión anterior de LDB si la actual crashea?

No. El Respondus Dashboard de tu universidad espera una versión mínima específica de LDB. Un LDB más antiguo será rechazado al abrir aunque esté instalado. La ruta correcta siempre es depurar la versión actual, no degradar.