Encuentre todas las causas y soluciones para el código de pantalla azul 0x000000D1

0×0000000C Error de código de acceso. 0×00000002 El sistema no puede encontrar el archivo especificado.

0x000000D1RIVER_IRQL_NOT_LESS_OR_EQUAL　◆Análisis de errores: generalmente causado por un controlador problemático (como los controladores Logitech MouseWare 9.10 y 9.24 para ratones Logitech pueden causar esta falla. Al mismo tiempo, memoria defectuosa, archivos de memoria virtual dañados, ciertos). El software (como software multimedia, software antivirus, software de copia de seguridad, software de reproducción de DVD), etc. también puede causar este error. ◇Solución: verifique el controlador más reciente instalado o actualizado (si aparece "acpi.sys" en la pantalla azul). " y otros nombres de archivos similares, puede estar seguro de que es un problema de controlador) y software; pruebe si hay un problema con la memoria; ingrese a la "Consola de recuperación", vaya a la partición donde se encuentra el archivo de página de memoria virtual Pagefile. sys y ejecute el comando "del pagefile.sys" para eliminar el archivo de la página; luego ejecute el comando "chkdsk /r" en la partición donde se encuentra el archivo de la página; reinicie la memoria virtual después de ingresar a Windows. pantalla azul mientras navega por Internet y está descargando y cargando una gran cantidad de datos (por ejemplo: juegos en línea, descargas BT), entonces debería haber un problema con el controlador de la tarjeta de red y es necesario actualizar su controlador.

Las siguientes situaciones provocarán un fallo de pantalla azul del sistema: 1. Controladores de dispositivo que se ejecutan en modo kernel O una función del sistema operativo genera una excepción no controlada, como una infracción de acceso a la memoria (causada por un intento de escribir en un página de solo lectura o un intento de leer una dirección de memoria que no está asignada actualmente (es decir, una dirección no válida)). 2. Llamar a una rutina de soporte del kernel da como resultado una reprogramación, como esperar por un objeto de programación marcado como en espera cuando el nivel de solicitud de interrupción (IRQL) es el nivel DPC/Dispatch o superior. 3. Se produce un error de página (Error de página) en el nivel DPC/Dispatch o en un nivel IRQL superior porque existen datos en el archivo de página o en el archivo asignado en memoria. (Esto requerirá que el administrador de memoria espere a que ocurra una operación de E/S. Pero como se mencionó en el elemento anterior, la espera no se puede realizar en el nivel DPC/Dispatch o en un nivel IRQL superior, porque eso requerirá una reprogramación). 4. Cuando se detecta un estado interno que indica que los datos se han dañado o que el sistema no puede continuar ejecutándose sin asegurarse de que los datos no estén dañados, el controlador del dispositivo o la función del sistema operativo solicita explícitamente que el sistema se bloquee (llamando a la función del sistema KeBugCheckEx ). 5. Se produce un error de hardware, como que la función de excepción Computer Check (Machine Check) del procesador informe una excepción o una interrupción no enmascarable (NMI). Después de comprender los tres puntos de conocimiento anteriores, creo que apreciará el intrépido espíritu de sacrificio de Windows y perdonará su "cara azul". De hecho, en la gran mayoría de los casos son los controladores de dispositivos de terceros los que provocan que Windows falle. Para los archivos de volcado de memoria enviados por los usuarios de Windows XP al sitio Microsoft Online Crash Analysis (Microsoft OCA, Microsoft Online Crash Analysis), Microsoft ha clasificado estadísticamente las causas de los fallos, como se muestra en la siguiente figura: (Datos generados en abril de 2004) . Ahora que Windows nos ha mostrado una "cara azul" indefensa, deberíamos romper la cazuela y preguntar la verdad, y arrestar al culpable que provocó la caída del sistema lo antes posible para que nuestro sistema se recupere lo antes posible. A continuación, echemos un vistazo a lo que Windows quiere decirnos a través de esta "cara azul". Como se muestra arriba, esta es una imagen de pantalla azul que muestra todos los parámetros. Por supuesto, puede haber diferencias entre las imágenes de pantalla azul que encontramos, como falta de información, etc., pero son más o menos iguales. Lo usaremos como ejemplo para explicarlo completamente. Primero, veamos el área marcada con el número 1 en la figura, donde se enumeran el código de parada y cuatro parámetros pasados ​​a la función KeBugCheckEx.

El código de parada en esta imagen es 0x000000D1, y los cuatro parámetros son cuatro números hexadecimales separados por comas en los siguientes corchetes. A continuación, echemos un vistazo al área marcada con el número 2 en la imagen, que muestra la explicación en inglés; correspondiente al código 0x000000D1 finalmente, veamos el área marcada con el número 3 en la figura. Esta área ocurre si y solo si uno de los cuatro parámetros del código de parada contiene la dirección del sistema operativo o el código del controlador del dispositivo. Se mostrará. El contenido mostrado es la dirección base del módulo donde se encuentra la dirección y el sello de fecha. En este ejemplo, el nombre de archivo del controlador del dispositivo es "myfault.sys". ¿Cómo nos ayuda esta información a solucionar problemas? Si aparece el área 3 en la imagen de arriba, ese es el mejor resultado, porque verá directamente al culpable: el archivo "myfault.sys". Sin embargo, el área 3 a menudo no aparece, por lo que tenemos que buscar el código de detención y otra información en la ayuda y soporte en línea de Microsoft o usar nuestra herramienta WinDbg para el análisis manual. El autor recomienda lo último, porque el mismo código de detención puede deberse a varios errores del controlador. Obtener el código de detención no significa obtener el nombre del archivo problemático. Además, no todos los errores en la ayuda y soporte en línea de Microsoft pueden ser Search y WinDbg. Simplemente supera estas dos debilidades y puede capturar directamente el archivo culpable, permitiéndote decapitarlo felizmente. WinDbg es un software gratuito. Para conocer su dirección de descarga oficial de Microsoft, consulte la lectura ampliada. El proyecto específico es Instalar herramientas de depuración para la versión de Windows de 32/64 bits. El requisito previo para usar WinDbg para analizar el archivo de volcado de memoria durante una falla es que desea que el sistema genere automáticamente un archivo de volcado de memoria cuando falla. El método es el siguiente: 1. Haga clic en Inicio, luego haga clic en Ejecutar. 2. Escriba control sysdm.cpl Copiar código y haga clic en Aceptar. Abrirá las propiedades del sistema, cambie a la pestaña Avanzado. Los resultados se muestran a continuación: 3. En la pestaña Avanzado, haga clic en Configuración en la sección Inicio y recuperación. Esto abrirá el cuadro de diálogo de inicio y recuperación, como se muestra a continuación: 4. En la lista de información de depuración de escritura, seleccione "Volcado de memoria pequeña (64 KB)" o "Volcado de memoria central" para que el sistema El archivo de volcado de memoria correspondiente ser generado automáticamente. Si no desea que la pantalla azul parpadee solo una vez, pero desea verla claramente hasta que reinicie manualmente la computadora, desactive la casilla de verificación frente al elemento Reiniciar automáticamente(R) en la sección Fallas del sistema. Luego haga clic en Aceptar. 5. En el cuadro de diálogo Inicio y recuperación, haga clic en Aceptar. 6. Haga clic en Aceptar para cerrar el cuadro de diálogo Propiedades del sistema. 7. En el cuadro de diálogo Cambio de configuración del sistema, haga clic en Sí si desea reiniciar la computadora inmediatamente; haga clic en No si desea reiniciar la computadora más tarde. Nota: Los usuarios de Vista deben realizar operaciones similares. Para los sistemas operativos básicos, las configuraciones anteriores son las predeterminadas (excepto la desactivación del reinicio automático). Con respecto al contenido de la lista escrita de información de depuración en el punto 4, se proporciona la siguiente interpretación de referencia: (Los tamaños de los tres archivos de volcado anteriores aumentan en secuencia. La comparación de los tres está más allá del alcance de este artículo. El autor solo recomienda configurándolo en "Volcado de memoria pequeña" o "volcado de memoria central", para errores generales, "volcado de memoria pequeña" es suficiente. Si no se puede analizar por completo, seleccione "volcado de memoria central" para ver la riqueza de datos, también puede hacerlo directamente. Seleccione "Volcado de memoria central", pero el autor no recomienda enfáticamente un volcado de memoria completo). Vale la pena señalar que para garantizar que se genere automáticamente un archivo de volcado de memoria cuando ocurre un bloqueo, es posible que también deba habilitar el. archivo de página de memoria virtual. En particular, cuando elige registrar un volcado de memoria central, debe habilitar el archivo de página de memoria virtual, y debido a que el tamaño del archivo de volcado de memoria central depende de la cantidad de memoria en modo kernel que ha asignado el sistema operativo y todos los controladores activos en esa máquina, por lo que no existe una buena manera de predecir el tamaño de un volcado de memoria del kernel. La siguiente tabla solo proporciona el valor de configuración del tamaño de la memoria virtual de referencia en este caso: Además, además del espacio en disco ocupado por el archivo de página, el disco donde se genera el archivo de volcado de memoria (*.DMP) debe tener suficiente espacio libre. para extraer De lo contrario, este archivo de volcado "no se generará" (en realidad se perderá). Después de configurarlos, una vez que su sistema falle con una pantalla azul, el sistema generará un archivo de volcado en el directorio correspondiente bajo el tipo de archivo de volcado de memoria correspondiente seleccionado en la configuración anterior.

Todo lo que tiene que hacer es sacar su herramienta inmediatamente e iniciar WinDbg para su análisis. El autor dará una explicación detallada con un ejemplo aquí. El proceso incluye algunos comandos utilizados para depurar pantallas azules en WinDbg. Estos comandos no se organizarán adicionalmente, así que téngalos en cuenta durante el proceso de lectura. Primero, debe configurar la ubicación del archivo de símbolos de depuración (Archivo de símbolos) que utilizará WinDbg. ¿Qué es un archivo de símbolos de depuración? Los archivos de símbolos se generan cuando se crea un archivo DLL o EXE y proporcionan espacio de marcador de posición para funciones contenidas en archivos ejecutables y bibliotecas de vínculos dinámicos (DLL). Además, un archivo de símbolos puede representar una hoja de ruta de llamadas a funciones que conducen a un punto de falla. Cuando utilizamos varias herramientas de Microsoft para depurar aplicaciones, debemos tener información simbólica para poder analizar correctamente la causa raíz del problema. Entonces, ¿cómo configuramos la ubicación del archivo de símbolos de depuración? Podemos descargar el paquete completo de archivos de símbolos desde el sitio web oficial de Microsoft (también ubicado en la página de descarga de WinDbg) o utilizar el servidor de archivos de símbolos de Microsoft (Microsoft Symbol Server). El autor recomienda lo último, porque los archivos de símbolos utilizados en un análisis están limitados a un número limitado. El uso de este último permite que el programa se descargue automáticamente, lo que no sólo ahorra tiempo, sino que también garantiza que los archivos de símbolos estén actualizados y sean correctos. . Haga clic en el menú "Archivo" en WinDbg, seleccione "Ruta del archivo de símbolo...", ingrese "Copiar código" en el cuadro de diálogo que se abre y haga clic en el botón "Aceptar". Por supuesto, el siguiente paso es hacer clic nuevamente en el menú "Archivo" y seleccionar "Guardar espacio de trabajo" para guardar la configuración actual. Después de configurar el archivo de símbolos, puede analizar el archivo de volcado de memoria. También haga clic en el menú "Archivo", esta vez seleccione "Abrir volcado de memoria ..." y luego abra el archivo de volcado de memoria generado para analizarlo a través del cuadro de diálogo de apertura de archivo. En este ejemplo, se establece el tipo de volcado de memoria central, por lo que debe ubicar "%SystemRoot%" (es decir, en la carpeta de Windows del disco del sistema) y abrir el archivo MEMORY.DMP. Sin embargo, el autor lo transfirió a "E:\Memory Dump\MEMORY.DMP" de antemano, por lo que en las imágenes siguientes se ve esta dirección. En este momento, WinDbg se desplazará y mostrará cierta información y se sentirá ligeramente colgado hasta que todos los archivos de símbolos necesarios para analizar el archivo de fallo se descarguen del servidor de archivos de símbolos de Microsoft. En la imagen de arriba, vemos la ventana de comandos del depurador abierta (el archivo de símbolos se ha cargado y está en espera). Primero veamos el área 6 en la parte inferior. Esta pequeña barra rectangular es WinDbg. se divide en dos áreas: el área izquierda que muestra "0: kd>" es el área de solicitud y el área en blanco de la derecha es el área de entrada de comandos. Cuando se acaba de abrir esta ventana y el archivo de símbolos no se ha descargado/cargado, no se mostrará nada en el área de solicitud y se mostrará "Debuggee no conectado" en el área de entrada de comandos. No quedará inactivo hasta que se carguen los símbolos y se muestre la última línea "Seguimiento: MachineOwner" en la ventana. Cuando esté inactivo, aparecerá similar a la imagen de arriba. ¿Por qué es parecido? Debido a que este mensaje de espera inactivo varía según el tipo de depuración y la configuración del hardware del procesador de la computadora, en este ejemplo se realiza la depuración del kernel, por lo que se muestra "kd>" (depuración del kernel). entonces en " También se muestra un "0:" antes de kd>", lo que indica que actualmente se encuentra en el procesador con el número 0. Después de ejecutar un comando, si el comando necesita procesar muchas tareas (como "! Analyze -v"), el área de solicitud se mostrará como "*BUSY*" en el estado ocupado. Una vez que se muestra en este estado, no. No importa lo que ingrese, los comandos no se ejecutarán inmediatamente, sino que se pospondrán hasta que queden inactivos.

Como se muestra en la figura anterior, el Área 1 en la figura mostrará la ruta física del archivo de volcado de memoria abierto. El Área 2 muestra la ubicación del archivo de símbolos actualmente cargado, que en este caso indica que se descargó de un servidor de Microsoft; El área 2 3*** tiene tres líneas, que muestran información del sistema. La primera línea indica que el sistema es Windows XP, la versión del kernel es 2600 (SP3), multiprocesador (2), 32 bits y la segunda línea. indica que el tipo de sistema es sistema NT, sistema cliente, la tercera línea indica la identificación detallada de la versión del sistema. El área 4*** tiene dos líneas, la primera línea indica la hora en que se generó el archivo de volcado de memoria, que es el; hora específica de la falla del sistema, en este ejemplo (Este es un archivo de volcado de falla obtenido en diciembre del año pasado, que ahora se usa como ejemplo para ilustración. Es sábado (sábado), 27 de diciembre (diciembre), 22:56). :31.062, 2008, Distrito 8 Este, GMT (GMT+8), la segunda línea muestra que el sistema ha estado funcionando durante 0 días, 4 horas, 5 minutos y 15,797 segundos desde que se inició en el momento del accidente. El área 5 es un mensaje de error muy crítico. Su primera línea solo se muestra cuando se encuentra un error al cargar el archivo de símbolos. En este caso, nos dice "Para el archivo BaseTDI.SYS, el módulo se ha cargado pero no se puede cargar. "Archivo de símbolos", si se ha configurado antes la ruta correcta del archivo de símbolos, esto nos indica que BaseTDI.SYS no es un archivo de Microsoft, sino un archivo de controlador de terceros. Es probable que esta sea la causa del error y lo merece. atención pero requiere mayor análisis. La segunda línea del área 5 es el resultado del análisis automático de WinDbg. Nos dice que la causa del bloqueo (Probablemente causado por:) es probablemente el archivo HookUrl.sys. Generalmente, este es el culpable de los errores, pero hay muchas excepciones. La más típica es que aquí se muestra un archivo propio de Microsoft. Para evitar matar a personas inocentes, es mejor analizarlo más a fondo. ¡Echemos un vistazo a qué módulos estuvieron involucrados en el último momento del bloqueo, para que podamos asegurarnos de que la prueba sea correcta! El comando para un análisis adicional se puede iniciar con "!analyze -v". Podemos escribir manualmente el comando !analyze -v Copiar código en el área de entrada del comando o hacer clic en el comando azul como se muestra en el área 7 en la figura anterior. Después de eso, el área de solicitud se mostrará como "*BUSY*" y WinDbg analizará durante un período de tiempo hasta que se muestren los resultados y vuelva a estar inactivo. A continuación ilustramos los diversos resultados que se muestran después de ejecutar "!analyze -v" basándose en una imagen de ejemplo: Después del análisis automático por parte de WinDbg, se puede mostrar la primera línea de la interpretación de verificación de errores que se muestra en el área 1 en la imagen de arriba. la segunda línea ofrece una explicación detallada. Se puede ver en la información de la figura que este error se debe a que "el controlador se descarga antes de que se complete el elemento de trabajo de la cola". Este "DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATION" debe ser la descripción del error que se muestra encima de la pantalla azul, y los siguientes argumentos 1 a 4 son los cuatro parámetros después del código de detención cuando aparece la pantalla azul. BUGCHECK_STR que se muestra en el área 2 de la figura es una de las comprobaciones de errores clasificadas (Bug Check) en WinDbg. En este ejemplo, es 0xCE, que también es la abreviatura de clasificación del código de parada. Ejecutamos el comando Copiar código .bugcheck. el área de entrada de comando. Se puede obtener el código de parada y sus parámetros, lo cual es consistente con la información en el área 1 y la pantalla azul en la figura anterior. En este ejemplo se pueden obtener los siguientes resultados: 0: kd> .bugcheckBugcheck code 000000CE Argumentos bacb0a4e 00000008 bacb0a4e 00000000 Podemos obtener la información en la pantalla azul añadiendo "0x" antes del valor del código Bugcheck "***STOP: 0x000000CE (bacb0a4e, 00000008, bacb0a4e, 00000000)".

Por supuesto, si desea saber más sobre este error, puede buscar la cadena "0x000000CE" en el sitio web de soporte y ayuda en línea de Microsoft, y puede usar el valor BUGCHECK_STR "0xCE" en el área 2 en la imagen de arriba para ejecutar Comprobación de errores .hh 0xCE: copie el comando de código y haga clic en el botón "Mostrar" en la esquina inferior derecha de la columna izquierda de la ventana abierta. Si desea mostrar un código de parada o una descripción detallada de la clase de verificación de errores en WinDbg (usando este error como ejemplo), escriba el comando !analyze -show 0x000000CE　Copiar código o !analyze -show 000000CE Copiar código, o !analyze -show 0xCE Copia el código. Lo que se muestra en el área 3 es la información importante de la información de la pila del hilo de juicio de segunda instancia. Preste especial atención a la parte en el cuadro rojo. La primera línea es "ADVERTENCIA: IP de marco no en ningún módulo conocido. Los siguientes marcos pueden ser incorrectos". Significa "Advertencia: IP de marco de pila (InstructionPtr, solo procesadores x86, utilizados para). determinar el marco El puntero de instrucción para el rastreo de la pila) no existe en ningún módulo conocido y puede ocurrir un error en el siguiente marco." La explicación de este significado está más allá del alcance de este artículo. El autor solo le dice que el módulo en el lado derecho de la línea debajo de esta línea de texto es el último módulo utilizado cuando la pantalla azul del sistema falla (excepto el kernel de Windows). que finalmente llama a KeBugCheckEx para que se sacrifique, que es el módulo encima del texto de advertencia (tres líneas), ¡a menudo es la causa del bloqueo! Echemos un vistazo más de cerca. Si comprende la estructura de datos de la pila o el mecanismo de asignación de memoria de Windows, debe saber que cuando Windows asigna memoria adicional para los subprocesos, apunta de direcciones altas a bajas. En otras palabras, para la información de la pila en el área azul 3, usamos. Tienes que revertirlo Mirando de abajo hacia arriba, esta es la llamada y transferencia de las funciones de estado del kernel en el momento antes de que el sistema falle. Por ejemplo, en este ejemplo, el cuerpo de ejecución del kernel del sistema (nt!, Ntoskrnl.exe) llama. BaseTDI a través de la función IopfCallDriver, y luego BaseTDI llama a HookUrl.sys (la palabra Unloaded_ significa no cargado), y luego aparece una pantalla azul. Entonces, en este último momento, están involucrados dos módulos del kernel que no son de Windows: BaseTDI y HookUrl.sys. El motivo de este "juicio de segunda instancia" es evitar una situación: en caso de que HookUrl.sys y BaseTDI sean módulos de dos empresas o dos software, y el último HookUrl.sys cargado no tenga ningún problema y se produzca un error, se debe a que BaseTDI. pasó información de parámetros mal formada, dañada o ilegal a HookUrl.sys, y HookUrl.sys aceptó estos datos no válidos y provocó un bloqueo. Si no miramos la pila de subprocesos y hacemos un juicio basado en la "Probablemente causa por: HookUrl.sys" anterior, es probable que matemos a una persona inocente y dejemos que el asesino quede libre. Sólo a través de la pila de subprocesos descubrimos que también estaba involucrado otro controlador, BaseTDI. (En el análisis de depuración donde la falla de la aplicación no causa que el sistema falle, ya que está en el modo de usuario, el "Probablemente causado por:" en los resultados del análisis automático de WinDbg casi siempre es incorrecto. En este caso, el hilo ! El comando no se puede usar para mostrar ninguna información, porque este comando solo es efectivo para la depuración de fallas en el modo kernel. Sin embargo, el comando kb no muestra información útil. Solo usando "~*kb" para mostrar todas las pilas de subprocesos detalladas puede la raíz. encontrar la causa del problema. A veces también necesita cooperar con otros comandos, que no se discutirán en este artículo) Por supuesto, si se vuelve competente y siente que no es necesario usar el comando "!analyze -v". , Puede utilizar directamente el comando !thread Copiar código o kb Copiar código para mostrar la información de la pila de subprocesos principales. Bueno, ahora los sospechosos tienen como objetivo BaseTDI y HookUrl.sys. Ahora, echemos un vistazo a qué son exactamente, qué empresa y qué módulos de programa son.

(Puede saber que deben ser controladores de terceros, ya que antes no podía cargar automáticamente archivos de símbolos desde los servidores de Microsoft). Utilice el comando lm kv m Basetdi* para copiar el código (use el comando lm (lista de módulos) y la opción k del kernel. La opción v detallada y el parámetro m, junto con la cadena BaseTDI que contiene el carácter comodín *, enumeran la información detallada de todos los archivos de controlador que contienen el carácter BaseTDI que están actualmente cargados en modo kernel. Utilice caracteres comodín para reemplazar. el sufijo completo del nombre del archivo para evitar limitaciones de información (mediante el cual podemos encontrar múltiples módulos relacionados para proporcionar más pistas de diagnóstico), obtenemos los resultados en la siguiente figura: Desde la selección del cuadro azul en la figura, podemos ver. que solo había uno llamado BaseTDI.SYS en el archivo de estado del kernel en ese momento, la ruta de este archivo se encuentra en System32\Drivers y pertenece al componente del programa llamado "Rising Personal Firewall" (Nombre del producto: Rising PFW, PFW= Personal Firewall). La marca registrada de la compañía de software es "Rising" (Marcas comerciales legales: RISING). Si no conoce la información de descripción en inglés del archivo, puede buscarla en Baidu. Por supuesto, la información que no ha sido resaltada por el autor (como la marca de tiempo del archivo, la versión, la suma de verificación, etc.) también es muy útil. Por ejemplo, si busca la versión del archivo en Baidu, puede encontrar que el software tiene. proporcionó una solución actualizada a este problema. De manera similar, usamos lm kv m hookurl* Copiar código para mostrar el archivo que contiene HookUrl y su información detallada en el modo kernel en ese momento. El resultado es el siguiente: La ilustración es un resultado insatisfactorio porque, como se resalta, el módulo no está cargado y por lo tanto no se registra ninguna información. Pero tenemos a Baidu, así que no te preocupes, lo sabrás después de solo Baidu. Después de buscar HookUrl.sys, descubrí que este también es el archivo de Rising Personal Firewall. De hecho, este caso es el famoso incidente de la "pantalla azul causada por la actualización de versiones cruzadas del firewall personal a la versión 2009". Puede buscar en Baidu con la palabra clave "Pantalla azul causada por la actualización de Rising Firewall 2009". Hasta el momento, los funcionarios de Rising no han dado ninguna respuesta oficial a este incidente. Aunque no todos los usuarios tienen este problema, muchos usuarios han informado de este problema.