Debugger / Blue Screen of Death help


  1. Posts : 7
    Windows 10 professional 64 Bit
       #1

    Debugger / Blue Screen of Death help


    This is my first time using the debugger, so bear with me.

    So, Windows 7 professional 64 bit RTM crashed with the dreaded Blue Screen of Death after just running for 5 days. All I was doing was changing one of the system fonts, hit the apply button, and Blue Screen of Death appeared. I tried bringing the system back to the most recent restore point, but that created even further problems, so I rebuilt the system from a recent image backup (Boy, am I glad I set up backups on the first day of installing Windows!). I saved the memory.dmp file before the rebuild. I am now trying to read the file to see what happened so I can isolate the problem and prevent it from happening again.

    I installed windbg program per the tutorial on this website and upon reading the memory.dmp file, this is what windbg returned.

    My questions are.

    1) Did windbg work properly?

    2) If so, what are the results telling me? What is the next step to isolate the problem?

    3) Is it better to have Windows write to the default "memory.dmp" file, or should I change it to a minidump file and only change to the memory.dmp file if advanced troubleshooting is needed? It looks as if you must choose either one or the other.

    Here are the results:

    ---------------------------
    Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
    Copyright (c) Microsoft Corporation. All rights reserved.

    Loading Dump File [F:\MEMORY.DMP]
    Kernel Summary Dump File: Only kernel address space is available
    Symbol search path is: SRV*C:\SymCache*Symbol information
    Executable search path is:
    Windows 7 Kernel Version 7600 MP (8 procs) Free x64
    Product: WinNt, suite: TerminalServer SingleUserTS
    Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
    Machine Name:
    Kernel base = 0xfffff800`02c0b000 PsLoadedModuleList = 0xfffff800`02e48e50
    Debug session time: Thu Nov 12 10:04:53.853 2009 (GMT-5)
    System Uptime: 0 days 2:35:02.853
    Loading Kernel Symbols
    ...............................................................
    ................................................................
    ............................
    Loading User Symbols
    PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
    Loading unloaded module list
    .....
    *******************************************************************************
    * *
    * Bugcheck Analysis *
    * *
    *******************************************************************************
    Use !analyze -v to get detailed debugging information.
    BugCheck 19, {3, fffff900c1f28d80, fffff900c1f28d80, fff900c1f28d8000}
    Page 215c4c not present in the dump file. Type ".hh dbgerr004" for details
    PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
    PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
    Probably caused by : Pool_Corruption ( nt!ExFreePool+780 )
    Followup: Pool_corruption
    -----------------------

    Thanks.
      My Computer


  2. Posts : 28,845
    Win 8 Release candidate 8400
       #2

    pjc123 said:
    This is my first time using the debugger, so bear with me.

    So, Windows 7 professional 64 bit RTM crashed with the dreaded Blue Screen of Death after just running for 5 days. All I was doing was changing one of the system fonts, hit the apply button, and Blue Screen of Death appeared. I tried bringing the system back to the most recent restore point, but that created even further problems, so I rebuilt the system from a recent image backup (Boy, am I glad I set up backups on the first day of installing Windows!). I saved the memory.dmp file before the rebuild. I am now trying to read the file to see what happened so I can isolate the problem and prevent it from happening again.

    I installed windbg program per the tutorial on this website and upon reading the memory.dmp file, this is what windbg returned.

    My questions are.

    1) Did windbg work properly?

    2) If so, what are the results telling me? What is the next step to isolate the problem?

    3) Is it better to have Windows write to the default "memory.dmp" file, or should I change it to a minidump file and only change to the memory.dmp file if advanced troubleshooting is needed? It looks as if you must choose either one or the other.

    Here are the results:

    ---------------------------
    Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
    Copyright (c) Microsoft Corporation. All rights reserved.

    Loading Dump File [F:\MEMORY.DMP]
    Kernel Summary Dump File: Only kernel address space is available
    Symbol search path is: SRV*C:\SymCache*Symbol information
    Executable search path is:
    Windows 7 Kernel Version 7600 MP (8 procs) Free x64
    Product: WinNt, suite: TerminalServer SingleUserTS
    Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
    Machine Name:
    Kernel base = 0xfffff800`02c0b000 PsLoadedModuleList = 0xfffff800`02e48e50
    Debug session time: Thu Nov 12 10:04:53.853 2009 (GMT-5)
    System Uptime: 0 days 2:35:02.853
    Loading Kernel Symbols
    ...............................................................
    ................................................................
    ............................
    Loading User Symbols
    PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
    Loading unloaded module list
    .....
    *******************************************************************************
    * *
    * Bugcheck Analysis *
    * *
    *******************************************************************************
    Use !analyze -v to get detailed debugging information.
    BugCheck 19, {3, fffff900c1f28d80, fffff900c1f28d80, fff900c1f28d8000}
    Page 215c4c not present in the dump file. Type ".hh dbgerr004" for details
    PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
    PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
    Probably caused by : Pool_Corruption ( nt!ExFreePool+780 )
    Followup: Pool_corruption

    -----------------------

    Thanks.
    Hi and welcome to seven forums

    First my congrats for trying to figure this out on your own. I will be more than willing to help if you like

    The debugger is installed and working. If you upload that dump file I can run it and upload the result so you can compare them.

    Without any further debugging I can tell you something. If you look at the bit in bold you will see Bugcheck 19. that is a bad pool header. what that means is the memory pool returned bad information (mem corruption) which could have been caused by any file/driver loaded at the time.

    thats why we need the original DMP file

    Hope that helps a bit more to follow when you upload the dmp file


    Ken J
      My Computer


  3. Posts : 7
    Windows 10 professional 64 Bit
    Thread Starter
       #3

    I can attach the memory.dmp file. What is the proper way to attach it, ie just attach a zipped version to a reply message of this thread?
      My Computer


  4. Posts : 7
    Windows 10 professional 64 Bit
    Thread Starter
       #4

    I see that the memory.dmp file is 100MB and exceeds sevenforums 8MB limit, so I guess that is why my connection keeps disconnecting. My system was set to save full dumps by default as Windows 7 set up during the install, not minidumps, and the memory.dmp is the only file I saved before rebuilding the system. Oh well. I will change the setting to minidumps, so at least the next time I can send you something.
      My Computer


 

  Related Discussions
Our Sites
Site Links
About Us
Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 18:41.
Find Us