locked
Pantalla azul de la muerte RRS feed

  • Pregunta

  • Desde el dia 3 de Noviembre empezo a fallar la laptop, tengo windows 7 32 bits y la pantalla azul da el mensaje de error_registry

    stop y una serie de numeros, la laptop se reinicia y no me deja entrar a windows de forma normal, pense que era el disco duro, pero esta en buen estado, no puedo reinstalar el sistema operativo, ya que no tengo disco de instalacion , pues no venia incluido en mi lap. por favor necesito ayuda urgente, tengo documentos importantes a lo que no me deja accesar en forma segura, no puedo desinstalar programas, ni hacer ningun movimiento, de antemano gracias.

    este es el registro

    Problem signature:

    Problem Event Name: BlueScreen

    OS Version: 6.1.7600.2.0.0.768.3

    Locale ID: 2058

    Additional information about the problem:

    BCCode: 51

    BCP1: 00000001

    BCP2: 8981A250

    BCP3: 00E13000

    BCP4: 00000374

    OS Version: 6_1_7600

    Service Pack: 0_0

    Product: 768_1

    Files that help describe the problem:

    C:\Windows\Minidump\111910-39093-01.dmp

    C:\Users\Richo\AppData\Local\Temp\WER-64927-0.sysdata.xml

    Read our privacy statement online:

     

    If the online privacy statement is not available, please read our privacy statement offline:

     

    C:\windows\system32\en-US\erofflps.txt

    viernes, 19 de noviembre de 2010 21:51

Respuestas

  • Entiendo! Por eso suele mostrar en la mayoría de veces el causante o lo más cercano a esto, después de todo entiendo que por estas llamadas es que en la mayoría de veces hace que Windows no pueda completar la operación y haga el crash.

    Gracias por tu tiempo Jose, seguiré atento este hilo para aprender un poco más.


    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft

    No. El 99% de las veces el crah es debido a una mala programacion que implican a veces reintentos hardware no permitidos. El crash lo hace el hardware en ese caso pero windows, aun así, es capaz todavia de interceptar y si puede (que puede casi siempre a menos que sea en la controladora de disco) es capaz de grabar el dump.

     


    Jose Manuel Tella Llop news://jmtella.com

    • Marcado como respuesta Ismael Borche miércoles, 1 de diciembre de 2010 19:11
    sábado, 20 de noviembre de 2010 19:28

Todas las respuestas

  • Desde el dia 3 de Noviembre empezo a fallar la laptop, tengo windows 7 32 bits y la pantalla azul da el mensaje de error_registry

    stop y una serie de numeros, la laptop se reinicia y no me deja entrar a windows de forma normal, pense que era el disco duro, pero esta en buen estado, no puedo reinstalar el sistema operativo, ya que no tengo disco de instalacion , pues no venia incluido en mi lap. por favor necesito ayuda urgente, tengo documentos importantes a lo que no me deja accesar en forma segura, no puedo desinstalar programas, ni hacer ningun movimiento, de antemano gracias.

    este es el registro

    Problem signature:

    Problem Event Name: BlueScreen

    OS Version: 6.1.7600.2.0.0.768.3

    Locale ID: 2058

    Additional information about the problem:

    BCCode: 51

    BCP1: 00000001

    BCP2: 8981A250

    BCP3: 00E13000

    BCP4: 00000374

    OS Version: 6_1_7600

    Service Pack: 0_0

    Product: 768_1

    Files that help describe the problem:

    C:\Windows\Minidump\111910-39093-01.dmp

    C:\Users\Richo\AppData\Local\Temp\WER-64927-0.sysdata.xml

    Read our privacy statement online:

     

    If the online privacy statement is not available, please read our privacy statement offline:

     

    C:\windows\system32\en-US\erofflps.txt

    Con este articulo mio: http://multingles.net/docs/jmt/bsod.htm analiza el fichero de volcado de memoria: C:\Windows\Minidump\111910-39093-01.dmp

    Y dejanos aqui los resultados...


    Jose Manuel Tella Llop news://jmtella.com

    viernes, 19 de noviembre de 2010 22:59
  • Jose hasta hoy vine a entender un poco más de esto, por lo que entiendo ya el STACK_TEXT nos va a dar siempre los errores a los llamados que hace el controlador, servicio, etc, y veo que desde las últimas líneas ya especificaba (En el caso de tu artículo) los posibles causantes (USBPORT), ahora... siempre hay que ir hasta el contenido de las líneas de los argumentos para llegar al fondo?

    Gepardo, déjanos la salida del análisis con el Debugger, así encontramos el causante y aprendemos todos =)


    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft

    sábado, 20 de noviembre de 2010 1:47
  • Jose hasta hoy vine a entender un poco más de esto, por lo que entiendo ya el STACK_TEXT nos va a dar siempre los errores a los llamados que hace el controlador, servicio, etc, y veo que desde las últimas líneas ya especificaba (En el caso de tu artículo) los posibles causantes (USBPORT), ahora... siempre hay que ir hasta el contenido de las líneas de los argumentos para llegar al fondo?

    Gepardo, déjanos la salida del análisis con el Debugger, así encontramos el causante y aprendemos todos =)

     


     

    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft

    Cada analisis es un mundo... y dependiendo del error, para saberlo completamente a veces hay que dar muchos comandos y diferentes. Ahora bien, tambien es cierto que en 95% de los casos, solo con el previo del !analyze -v  ya vale...

     


    Jose Manuel Tella Llop news://jmtella.com

    sábado, 20 de noviembre de 2010 13:42
  • Jose hasta hoy vine a entender un poco más de esto, por lo que entiendo ya el STACK_TEXT nos va a dar siempre los errores a los llamados que hace el controlador, servicio, etc, y veo que desde las últimas líneas ya especificaba (En el caso de tu artículo) los posibles causantes (USBPORT), ahora... siempre hay que ir hasta el contenido de las líneas de los argumentos para llegar al fondo?

    Gepardo, déjanos la salida del análisis con el Debugger, así encontramos el causante y aprendemos todos =)

     


     

    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft

    Cada analisis es un mundo... y dependiendo del error, para saberlo completamente a veces hay que dar muchos comandos y diferentes. Ahora bien, tambien es cierto que en 95% de los casos, solo con el previo del !analyze -v  ya vale...

     


    Jose Manuel Tella Llop news://jmtella.com


    Perfecto! Muchas gracias :)

    Ahora, por qué en la mayoría de las veces que lo causa un controlador trata de hacer llamadas o permisos en kernel que no tiene permitido? Drivers no firmados? incompatibilidad?


    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft
    sábado, 20 de noviembre de 2010 13:50
  • Jose hasta hoy vine a entender un poco más de esto, por lo que entiendo ya el STACK_TEXT nos va a dar siempre los errores a los llamados que hace el controlador, servicio, etc, y veo que desde las últimas líneas ya especificaba (En el caso de tu artículo) los posibles causantes (USBPORT), ahora... siempre hay que ir hasta el contenido de las líneas de los argumentos para llegar al fondo?

    Gepardo, déjanos la salida del análisis con el Debugger, así encontramos el causante y aprendemos todos =)

     


     

    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft

    Cada analisis es un mundo... y dependiendo del error, para saberlo completamente a veces hay que dar muchos comandos y diferentes. Ahora bien, tambien es cierto que en 95% de los casos, solo con el previo del !analyze -v  ya vale...

     


    Jose Manuel Tella Llop news://jmtella.com


    Perfecto! Muchas gracias :)

    Ahora, por qué en la mayoría de las veces que lo causa un controlador trata de hacer llamadas o permisos en kernel que no tiene permitido? Drivers no firmados? incompatibilidad?


    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft
    Normalmente las llamadas con correctas... ponme un ejemplo...

    Jose Manuel Tella Llop news://jmtella.com

    sábado, 20 de noviembre de 2010 13:52
  • Jose hasta hoy vine a entender un poco más de esto, por lo que entiendo ya el STACK_TEXT nos va a dar siempre los errores a los llamados que hace el controlador, servicio, etc, y veo que desde las últimas líneas ya especificaba (En el caso de tu artículo) los posibles causantes (USBPORT), ahora... siempre hay que ir hasta el contenido de las líneas de los argumentos para llegar al fondo?

    Gepardo, déjanos la salida del análisis con el Debugger, así encontramos el causante y aprendemos todos =)

     


     

    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft

    Cada analisis es un mundo... y dependiendo del error, para saberlo completamente a veces hay que dar muchos comandos y diferentes. Ahora bien, tambien es cierto que en 95% de los casos, solo con el previo del !analyze -v  ya vale...

     


    Jose Manuel Tella Llop news://jmtella.com


    Perfecto! Muchas gracias :)

    Ahora, por qué en la mayoría de las veces que lo causa un controlador trata de hacer llamadas o permisos en kernel que no tiene permitido? Drivers no firmados? incompatibilidad?


    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft
    Normalmente las llamadas con correctas... ponme un ejemplo...

    Jose Manuel Tella Llop news://jmtella.com


    Estaba pensando que el STACK mostraba siempre los accesos denegados restringidos o que en general un controlador no debería de hacer a modo kernel (No sé si sea así, por eso pregunto), entonces si se dan estas denegaciones es porque elc ontrolador o aplicación o servicio no hace lo que "debería" de hacer?

    Gracias Jose!


    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft
    sábado, 20 de noviembre de 2010 13:57
  • Jose hasta hoy vine a entender un poco más de esto, por lo que entiendo ya el STACK_TEXT nos va a dar siempre los errores a los llamados que hace el controlador, servicio, etc, y veo que desde las últimas líneas ya especificaba (En el caso de tu artículo) los posibles causantes (USBPORT), ahora... siempre hay que ir hasta el contenido de las líneas de los argumentos para llegar al fondo?

    Gepardo, déjanos la salida del análisis con el Debugger, así encontramos el causante y aprendemos todos =)

     


     

    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft

    Cada analisis es un mundo... y dependiendo del error, para saberlo completamente a veces hay que dar muchos comandos y diferentes. Ahora bien, tambien es cierto que en 95% de los casos, solo con el previo del !analyze -v  ya vale...

     


    Jose Manuel Tella Llop news://jmtella.com


    Perfecto! Muchas gracias :)

    Ahora, por qué en la mayoría de las veces que lo causa un controlador trata de hacer llamadas o permisos en kernel que no tiene permitido? Drivers no firmados? incompatibilidad?


    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft
    Normalmente las llamadas con correctas... ponme un ejemplo...

    Jose Manuel Tella Llop news://jmtella.com


    Estaba pensando que el STACK mostraba siempre los accesos denegados restringidos o que en general un controlador no debería de hacer a modo kernel (No sé si sea así, por eso pregunto), entonces si se dan estas denegaciones es porque elc ontrolador o aplicación o servicio no hace lo que "debería" de hacer?

    Gracias Jose!


    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft

    No, no.. en el stack lo que hay normalmente son las direcciones de retorino de las ultimas llamadas realizadas... por ese programa o por modulos, etc... el analisis del stack suele ser lo mas complejo...

     


    Jose Manuel Tella Llop news://jmtella.com

    sábado, 20 de noviembre de 2010 14:11
  • Entiendo! Por eso suele mostrar en la mayoría de veces el causante o lo más cercano a esto, después de todo entiendo que por estas llamadas es que en la mayoría de veces hace que Windows no pueda completar la operación y haga el crash.

    Gracias por tu tiempo Jose, seguiré atento este hilo para aprender un poco más.


    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft
    sábado, 20 de noviembre de 2010 15:14
  • Entiendo! Por eso suele mostrar en la mayoría de veces el causante o lo más cercano a esto, después de todo entiendo que por estas llamadas es que en la mayoría de veces hace que Windows no pueda completar la operación y haga el crash.

    Gracias por tu tiempo Jose, seguiré atento este hilo para aprender un poco más.


    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft

    No. El 99% de las veces el crah es debido a una mala programacion que implican a veces reintentos hardware no permitidos. El crash lo hace el hardware en ese caso pero windows, aun así, es capaz todavia de interceptar y si puede (que puede casi siempre a menos que sea en la controladora de disco) es capaz de grabar el dump.

     


    Jose Manuel Tella Llop news://jmtella.com

    • Marcado como respuesta Ismael Borche miércoles, 1 de diciembre de 2010 19:11
    sábado, 20 de noviembre de 2010 19:28
  • Hola Gepardo,

    Tienes alguna actualización de tu problema?

    Saludos,


    Sergio Calderón | Microsoft Student Partner Senior | Swat Team Microsoft
    martes, 23 de noviembre de 2010 12:32