SYSTEM_SERVICE_EXCEPTION (0x0000003B): causas, diagnóstico y soluciones

Cuando Windows muestra un pantallazo azul con el mensaje SYSTEM_SERVICE_EXCEPTION y el código 0x0000003B, está avisando de que algo muy serio ha fallado al pasar del código en modo usuario al código en modo kernel. Este stop code aparece cuando una rutina de servicio del sistema lanza una excepción y el subproceso implicado pertenece al sistema, no a una app cualquiera.

Si te suena haber visto este error en tu PC o servidor, no estás solo. Es un BSOD relativamente habitual que puede surgir por controladores defectuosos, corrupción de memoria o del sistema, utilidades incompatibles o incluso por fallos concretos en determinadas pilas de drivers (como la de IEEE 1394 en versiones antiguas de Windows). A continuación encontrarás una guía completa con causas, síntomas, diagnóstico avanzado con WinDbg, un caso conocido con hotfix oficial, y soluciones prácticas tanto para técnicos como para usuarios.

Qué significa SYSTEM_SERVICE_EXCEPTION (0x0000003B)

Este bug check tiene valor 0x0000003B e indica que se produjo una excepción mientras se ejecutaba una rutina de servicio del sistema. En otras palabras, algo en el salto de modo usuario a modo kernel se torció, y Windows detiene la máquina para evitar daños mayores.

Los códigos de excepción se expresan en formato NTSTATUS y están definidos en ntstatus.h del WDK. Dos códigos frecuentes asociados a este stop son:

• 0x80000003 (STATUS_BREAKPOINT): se encontró un breakpoint/ASSERT sin un depurador de kernel conectado.
• 0xC0000005 (STATUS_ACCESS_VIOLATION): violación de acceso a memoria (lectura/escritura/ejecución inválida).

En términos prácticos, suelen estar en juego desreferencias a puntero NULL, direcciones aleatorias o estructuras de datos dañadas, a veces por liberaciones prematuras de memoria o por drivers que pasan datos incorrectos al kernel.

Parámetros del bug check 0x0000003B

Cuando analizas el volcado, verás cuatro parámetros. Son clave para centrar el tiro al depurar:

Parámetro	Descripción
1	Código de excepción NTSTATUS que disparó el bug check.
2	Dirección de la instrucción que causó el bug check.
3	Dirección del registro de contexto de la excepción (CONTEXT).
4	0 (sin uso).

Con esos datos puedes reconstruir el estado de ejecución. El parámetro 1 te dirá exactamente qué excepción NTSTATUS se produjo, y el 3 te permite cargar el contexto para ver registros y pila en el punto del accidente.

Causas frecuentes

En la práctica, este BSOD aparece por una mezcla de software y hardware. Las causas típicas incluyen:

• Controladores mal escritos, desactualizados o corruptos (gráficos, almacenamiento, red, USB, etc.).
• Corrupción de memoria (RAM), desreferencias NULL o uso de memoria liberada.
• Archivos de sistema dañados o configuración de kernel incoherente.
• Entradas del Registro corruptas o manipuladas por malware/adware.
• Problemas de disco (sectores defectuosos, sistema de archivos con errores).
• Casos específicos de pila de drivers (p. ej., IEEE 1394 en Windows 7/Server 2008 R2).

También puede coincidir con cambios recientes: instalación de nuevo software/hardware, actualización de drivers, actualizaciones del sistema o ajustes de overclocking.

Síntomas y comportamiento

Más allá de la pantalla azul, es común ver bloqueos periódicos, lentitud general, reinicios inesperados y cierres aleatorios de apps. A veces el equipo tarda mucho en cargar el inicio tras el BSOD (inicio de apps como Discord muy lento) y, en no pocas ocasiones, el fallo se manifiesta mientras el PC parece estar inactivo.

En un caso práctico descrito por un usuario, los cuelgues sucedían una vez al día con periodos de 4-5 días sin fallos, e iban acompañados de cierres de Steam, reinicios de Discord o pestañas de Firefox congeladas. El equipo llevaba Windows 11 24H2 con hardware moderno (Intel Core i7‑14700K, RTX 4080, Z790 DDR5, SSDs NVMe) y los minivolcados necesitaban revisión para aislar el origen real. Este tipo de patrón encaja con drivers, utilidades de terceros o corrupción intermitente de memoria.

Diagnóstico avanzado con WinDbg

Si tienes acceso a símbolos y te manejas con WinDbg, puedes ir al grano. La secuencia básica para 0x3B suele ser:

• Usa !analyze -v para obtener un resumen del bug check, módulo sospechoso y pila.
• Carga el contexto del parámetro 3 con .cxr y, a continuación, saca la pila con kb.
• Desensambla alrededor de la instrucción del parámetro 2 con u, ub, uu y observa accesos a memoria.

Un ejemplo de salida (resumida) podría tener este aspecto; fíjate cómo se listan argumentos y direcciones clave:

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code
Arg2: fffff802328375b0, Faulting IP
Arg3: ffff9c0a746c2330, Context record
Arg4: 0000000000000000, Reserved

Para identificar el controlador responsable, el kernel expone KiBugCheckDriver. Puedes consultarlo con dx:

dx KiBugCheckDriver
// Ejemplo de salida: "nvlddmkm.sys" (cadena UNICODE)

Cuando el arg1 sea un NTSTATUS, !error te traduce el código:

!error 00000000c0000005
(NTSTATUS) 0xC0000005 - The instruction at 0x%p referenced memory at 0x%p.

Más comandos útiles durante la sesión: lm t n para enumerar módulos, !memusage para ver el estado de memoria global y !pte o !pool para profundizar en páginas y pools. La sección STACK TEXT (pila) proporciona pistas evidentes sobre qué código estaba ejecutándose y cómo llegó ahí.

Consejo práctico: si sospechas un consumo excesivo de paged pool por un cruce entre drivers en modo usuario y kernel (históricamente común con gráficos), activa Driver Verifier con reglas de pool para capturar violaciones justo en el punto de fallo.

Comprobador de controladores (Driver Verifier)

Driver Verifier se ejecuta en tiempo real para fiscalizar el comportamiento de los controladores, forzando excepciones proactivamente cuando detecta uso indebido de memoria, IRQL o sincronización. Está integrado en Windows y puedes iniciarlo desde un símbolo de sistema o PowerShell con verifier.

Pasos básicos: elige Crear configuración estándar, pide que seleccione controladores no firmados o más recientes, y limita el conjunto a los sospechosos (gráficos, almacenamiento, red). Evita marcar absolutamente todos para no penalizar en exceso el sistema. Si Driver Verifier encuentra problemas, el sistema generará un BSOD inmediato con información más útil.

Apoyo para el análisis y memoria

Si necesitas profundizar en el subsistema de memoria de Windows, Windows Internals (7ª edición, Parte 1) es un recurso excelente para comprender cómo y dónde mirar. En WinDbg, recuerda utilizar !memusage para una foto general, y luego refinar con !pte y !pool cuando el fallo apunte a corrupción en paginación o en pools.

Caso conocido: BSOD con IEEE 1394 en Windows 7/Server 2008 R2

Existe un problema documentado por Microsoft donde equipos con Windows 7 o Windows Server 2008 R2 se bloqueaban al usar ciertos dispositivos IEEE 1394, mostrando un Stop similar. El origen era un bug en la pila de controladores IEEE 1394 de Microsoft: el búfer asignado no se inicializaba correctamente.

Microsoft publicó un hotfix específico destinado únicamente a este problema. Recomendaciones oficiales: aplícalo solo si sufres exactamente este fallo, pues puede incluir comprobaciones adicionales. Si la descarga no aparece, debes contactar con Soporte de Microsoft. Requiere reiniciar tras instalar y no sustituye a otros hotfix previos.

Detalles de archivos clave incluidos (selección representativa): 1394bus.sys, 1394ohci.sys, ohci1394.sys. A modo orientativo, estas eran algunas versiones/fechas por plataforma:

• x86 (Windows 7): 1394bus.sys 6.1.7600.16385 (~54 KB, 13‑Jul‑2009), 1394ohci.sys 6.1.7600.20649 (~164 KB, 20‑Feb‑2010), ohci1394.sys 6.1.7600.16385 (~62 KB, 13‑Jul‑2009).
• x64 (Windows 7 / Server 2008 R2): 1394bus.sys 6.1.7600.16385 (~68 KB, 14‑Jul‑2009), 1394ohci.sys 6.1.7600.20649 (~228 KB, 20‑Feb‑2010), ohci1394.sys 6.1.7600.16385 (~72 KB, 14‑Jul‑2009).
• IA‑64 (Server 2008 R2): 1394bus.sys 6.1.7600.16385 (~182 KB, 14‑Jul‑2009), 1394ohci.sys 6.1.7600.20649 (~509 KB, 20‑Feb‑2010), ohci1394.sys 6.1.7600.16385 (~172 KB, 14‑Jul‑2009).

Además se distribuían manifiestos y paquetes MUM específicos por arquitectura (por ejemplo, X86_1394.inf_…_6.1.7600.20649…, AMD64_1394.inf_… y IA64_1394.inf_…), con su correspondiente firma de catálogo (.cat). No había requisitos previos para la instalación más allá del reinicio posterior, y Microsoft confirmó el problema en los productos indicados.

Soluciones prácticas (de más común a más técnico)

Sin acceso a WinDbg también puedes avanzar mucho. Empieza por lo sencillo y ve subiendo escalones si el problema persiste:

1) Revisar software y controladores recientes

Si el fallo apareció tras instalar algo, desinstala ese software o vuelve al controlador anterior. En el Administrador de dispositivos, revisa dispositivos con signo de exclamación, y desde sus propiedades consulta eventos/errores. Prueba a actualizar o revertir controladores (gráficos, almacenamiento, red, USB, monitores) y, si el problema comenzó tras una actualización, usa Volver al controlador anterior cuando esté disponible.

2) Comprobar malware

Ejecuta un análisis completo con tu antivirus o con la solución de Microsoft. Los análisis rápidos pueden dejar residuos; mejor una exploración completa para limpiar entradas del Registro y binarios alterados por malware/adware.

3) Reparar archivos de sistema

Abre una consola como administrador y ejecuta primero sfc /scannow. Cuando termine, lanza DISM /Online /Cleanup-Image /RestoreHealth. SFC repara desde la caché local y DISM ajusta la imagen del sistema para corregir inconsistencias más profundas.

4) Verificar el disco y el sistema de archivos

Abre CMD como admin y ejecuta chkdsk /f (o chkdsk c: /r desde entorno de recuperación). Si encuentra sectores defectuosos, los marcará como no utilizables; eso puede evitar que el kernel tropiece al cargar controladores o DLLs dañadas.

5) Probar la memoria RAM

Inicia la herramienta de Diagnóstico de memoria con mdsched.exe y elige reiniciar y comprobar. Si reporta errores, valora reemplazar el módulo defectuoso o bajar XMP/overclock. Si usas DDR5 a frecuencias ajustadas, prueba con los valores JEDEC de fábrica.

6) Arranque limpio

Con msconfig, oculta los servicios de Microsoft y deshabilita el resto; en el Administrador de tareas, desactiva el inicio de apps. Esto aísla software de terceros (antivirus, utilidades RGB, overlays, etc.) que pueda engancharse al kernel.

7) Actualizar BIOS y chipset

Descarga desde el soporte del fabricante de tu placa base la última BIOS/UEFI y drivers de chipset. Mejoras en microcódigo, gestión de energía y compatibilidad de memoria/PCIe reducen BSOD ligados a timings y ACPI.

8) Desactivar overclock o restablecer UEFI

Vuelve a valores por defecto en CPU, GPU y RAM. Los timings agresivos o voltajes cortos suelen traducirse en corrupción de memoria muy difícil de rastrear. Guarda y prueba estabilidad en stock.

9) Restaurar sistema

Si el problema empezó recientemente, ejecuta rstrui.exe y restaura a un punto anterior. Es una forma rápida de deshacer cambios en drivers/registro sin reinstalar.

10) Reparaciones de arranque y BCD (cuando no inicia)

Desde el Entorno de recuperación: Reparación de inicio. Si no basta, abre CMD y ejecuta bootrec /fixmbr y bootrec /fixboot. Útil cuando el BSOD viene acompañado de problemas al iniciar o de cortes a mitad de instalación.

11) Opcional: desactivar Secure Boot temporalmente

En algunos escenarios concretos, deshabilitar Secure Boot en la UEFI permite iniciar con controladores alternativos para aislar el conflicto. Recuerda reactivarlo cuando finalices las pruebas.

12) Reinstalación de Windows (último recurso)

Si nada funciona, una instalación limpia eliminará corrupción persistente y controladores problemáticos. Haz copia de seguridad primero porque se borrarán los datos. Si el instalador también BSOD hacia el final, prueba con otra USB ISO, otra unidad M.2 y BIOS por defecto.

Recuperar datos si no puedes iniciar

Perder datos tras un 0x0000003B es relativamente común, sobre todo si el sistema entra en bucles de fallo. Antes de reinstalar, valora extraer archivos con medios de arranque de recuperación.

Herramientas como Recoverit permiten crear un USB arrancable desde otro PC, iniciar la máquina afectada y copiar documentos, fotos y vídeos a un destino seguro. El flujo típico es crear el medio, arrancar desde él y seleccionar la unidad a escanear para recuperar lo importante.

Otra opción es EaseUS Data Recovery Wizard WinPE, que ofrece arranque sin tocar la instalación y modo seguro para discos de sistema dañados. Sus ventajas incluyen no sobrescribir datos, previsualización de archivos y no exigir reinstalar Windows para empezar a recuperar. Si tu equipo se congela a menudo o se reinicia, iniciar desde su medio te permitirá extraer lo crítico.

Consejos adicionales de resolución

Además de lo anterior, conviene repasar algunos básicos. En el Visor de eventos (Registro del sistema), busca errores críticos en la misma ventana temporal del pantallazo azul; suelen apuntar a servicios o drivers. Si añadiste hardware hace poco, prueba a retirarlo o consulta al fabricante por revisiones firmadas. En el Administrador de dispositivos, cualquier signo de exclamación es una pista. Y cuando identifiques un controlador en la pantalla azul, toma nota exacta del nombre del .sys.

SYSTEM_SERVICE_EXCEPTION (0x0000003B) es el reflejo de una excepción crítica en el tránsito a kernel. Con WinDbg, los parámetros del bug check, !analyze, .cxr y kb suele bastar para identificar el punto de fallo; si no, Driver Verifier ayudará a forzar la mano al controlador culpable. Para casos conocidos como el de IEEE 1394 en Windows 7/2008 R2, Microsoft dispone de hotfix con versiones de archivos concretas. Para el resto, una escalera de acciones —drivers, SFC/DISM, disco, RAM, BIOS/UEFI, arranque limpio y, si toca, reinstalación— devuelve la estabilidad, y siempre es posible salvar tus datos con medios de recuperación antes de tomar medidas drásticas.