locked
Reading Memory Dump file RRS feed

  • Question

  • Hi all

    I am having frequent BSOD on one of my PC. With the help of Windbg, I was able to read the Memory Dump (.dmp) files.

    Now as I could read it but that does not make any sense to me. Is there any way, or read any website or whatever to find out

    what is causing those BSOD by reading those Dump Files? Is there any particular line or lines that I focus in those dump files to find out the

    reasons for those BSOD.

    Deciphering those dump files would be a great acheivement and I would really appreciate if anybody could help me out in doing so.

    Thank you.

    Regards

    Bidhan Giri

    Thursday, July 22, 2010 12:04 PM

Answers

  • I just took a look at these, it would seem that the errors that are
    occurring are related to memory corruption, possibly indicating faulty
    RAM. Even though they there are a few different errors, they all seem to
    reference memory corruption in some way. I would start with running a
    memory diagnostic using the Windows Memory Diagnostic utility,
     
    If you find an error with the RAM, one or more DIMMs may need to be
    replaced. After you track down the error with the RAM and replace the
    faulty DIMM(s), if you still get stop errors, we can look at the newer
    dumps to determine the cause.
     In interpreting these, one of the major telltale signs that this is a
    memory problem is in Debuglog3.txt,
     EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
    referenced memory at 0x%08lx. The memory could not be %s.
     
    FAULTING_IP:
    win32k!SURFREF::bDeleteSurface+12
    bf809647 8539            test    dword ptr [ecx],edi
     
    TRAP_FRAME:  f7656478 -- (.trap 0xfffffffff7656478)
    .trap 0xfffffffff7656478
    ErrCode = 00000000
    eax=00000001 ebx=00000000 ecx=00000000 edx=00000000 esi=f7656500
    edi=00000000
    eip=bf809647 esp=f76564ec ebp=f76564f0 iopl=0         nv up ei ng nz na
    po nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000
    efl=00010282
    win32k!SURFREF::bDeleteSurface+0x12:
    bf809647 8539            test    dword ptr [ecx],edi
    ds:0023:00000000=????????
    .trap
    Resetting default scope
     
    CUSTOMER_CRASH_COUNT:  4
     
    DEFAULT_BUCKET_ID:  CODE_CORRUPTION
     
    BUGCHECK_STR:  0x8E
     
    PROCESS_NAME:  explorer.exe
     
    LAST_CONTROL_TRANSFER:  from bf813811 to bf809647
     
    STACK_TEXT:
    f76564f0 bf813811 00000000 4b050e63 e3e6a878
    win32k!SURFREF::bDeleteSurface+0x12
    f7656504 bf83756c 4b050e63 e238c048 f765652c win32k!bDeleteSurface+0x20
    f7656514 bf8c2421 e3e6a888 00000000 e1473790 win32k!vSpDeleteSurface+0x1c
    f765652c bf8c2bf5 e238c048 f7656578 00000000 win32k!psoSpGetComposite+0x32
    f7656594 bf864d97 e238c048 e1473790 00000000 win32k!vSpRedrawArea+0x5e
    f76565d8 bf864c0e e238c008 00000000 00000000 win32k!bSpUpdateSprite+0x172
    f7656630 bf889c03 e1ccc2d8 0001009e 00000000 win32k!GreUpdateSprite+0xae
    f7656694 bf803bbb e374da18 c6011716 bbeefc18 win32k!UpdateRedirectedDC+0xf1
    f76566ac bf803cf2 c6011716 00000000 f7656714 win32k!ReleaseCacheDC+0x5f
    f76566bc bf80ad30 c6011716 f76567a4 bf80ee6d win32k!_ReleaseDC+0xf
    f7656714 bf80ec8e bbeefc18 00000085 00000001
    win32k!xxxRealDefWindowProc+0x7ad
    f765672c bf81c33e bbeefc18 00000085 00000001
    win32k!xxxWrapRealDefWindowProc+0x16
    f7656748 bf80eed5 bbeefc18 00000085 00000001 win32k!NtUserfnNCDESTROY+0x27
    f7656780 8054163c 0001009e 00000085 00000001 win32k!NtUserMessageCall+0xae
    f7656780 7c90e514 0001009e 00000085 00000001 nt!KiFastCallEntry+0xfc
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    017ff8f8 00000000 00000000 00000000 00000000 0x7c90e514
     STACK_COMMAND:  kb
     
    CHKIMG_EXTENSION: !chkimg -lo 50 -d !win32k
    !chkimg -lo 50 -d !win32k
        bf809648 - win32k!SURFREF::bDeleteSurface+13
     [ c0:39 ]
    1 error : !win32k (bf809648)
     
    MODULE_NAME: memory_corruption
     
    IMAGE_NAME:  memory_corruption
     
    FOLLOWUP_NAME:  memory_corruption
     
    DEBUG_FLR_IMAGE_TIMESTAMP:  0
     
    MEMORY_CORRUPTOR:  ONE_BYTE
     
    FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_ONE_BYTE
     
    BUCKET_ID:  MEMORY_CORRUPTION_ONE_BYTE
     
    Followup: memory_corruption
     
    Debuglog2.txt is a little less obvious because
    DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) is usually attributed to out-of-date
    drivers, but the MODULE_NAME and IMAGE_NAME give it away
     
    STACK_COMMAND:  kb
     
    CHKIMG_EXTENSION: !chkimg -lo 50 -d !USBPORT
    !chkimg -lo 50 -d !USBPORT
        f1077648 - USBPORT!USBPORT_FlushMapTransferList+182
     [ e1:45 ]
    1 error : !USBPORT (f1077648)
     
    MODULE_NAME: memory_corruption
     
    IMAGE_NAME:  memory_corruption
     
    FOLLOWUP_NAME:  memory_corruption
     
    DEBUG_FLR_IMAGE_TIMESTAMP:  0
     
    MEMORY_CORRUPTOR:  ONE_BYTE
     
    FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_ONE_BYTE
     
    BUCKET_ID:  MEMORY_CORRUPTION_ONE_BYTE
     
    Followup: memory_corruption
     
     

    -- Mike Burr
    • Marked as answer by bidhangiri Sunday, August 29, 2010 9:10 AM
    Saturday, July 31, 2010 4:38 AM

All replies

  • Hi,
     
    This involves using the debugging tools for Windows, here is a post that
    outlines the procedure,
     
     
    If you post the output from the !analyze -v debugger command, someone
    can likely help you interpret it.
     
     

    -- Mike Burr
    Friday, July 23, 2010 3:12 PM
  • Also, If you want to skydrive the file and post a link, I can take a look at it.
    -- Mike Burr
    Friday, July 23, 2010 9:47 PM
  • Thank you very much for trying to help me out and my apology for a delay in responding you back.

    I am following the website that you recommended.Its the kind I was looking for.

    In the meanwhile, I have quite a few Memory Dump files that describe about different issues. Is that normal to have different kind of

    errors in those files as every dump talks about a slightly different issues?

    Anyway, attached is the zipped file. I would really appreciate if you could decrypt it and, if possible, explain a little bit on

    how you made your decision. I would really like to learn on how Memory Dump files help us.

    Also here is the link to the skydrive: https://cid-925f7138e4c5599a.office.live.com/self.aspx/Public%20Folder/MemoryDump.7z

    Thank you again.

    Regards

    Bidhan Giri

    Sunday, July 25, 2010 11:11 AM
  • Hi again

    My apology for sending you the skdrive link to my Private folder. Please find the right link toward my Public Folder.

    https://cid-925f7138e4c5599a.skydrive.live.com/redir.aspx?resid=925F7138E4C5599A!134&Bpub=SDX.Docs&Bsrc=GetSharingLink&authkey=to5nESToK3E%24

     

    Kind Regards

    Bidhan Giri

    Monday, July 26, 2010 5:33 AM
  • I just took a look at these, it would seem that the errors that are
    occurring are related to memory corruption, possibly indicating faulty
    RAM. Even though they there are a few different errors, they all seem to
    reference memory corruption in some way. I would start with running a
    memory diagnostic using the Windows Memory Diagnostic utility,
     
    If you find an error with the RAM, one or more DIMMs may need to be
    replaced. After you track down the error with the RAM and replace the
    faulty DIMM(s), if you still get stop errors, we can look at the newer
    dumps to determine the cause.
     In interpreting these, one of the major telltale signs that this is a
    memory problem is in Debuglog3.txt,
     EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
    referenced memory at 0x%08lx. The memory could not be %s.
     
    FAULTING_IP:
    win32k!SURFREF::bDeleteSurface+12
    bf809647 8539            test    dword ptr [ecx],edi
     
    TRAP_FRAME:  f7656478 -- (.trap 0xfffffffff7656478)
    .trap 0xfffffffff7656478
    ErrCode = 00000000
    eax=00000001 ebx=00000000 ecx=00000000 edx=00000000 esi=f7656500
    edi=00000000
    eip=bf809647 esp=f76564ec ebp=f76564f0 iopl=0         nv up ei ng nz na
    po nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000
    efl=00010282
    win32k!SURFREF::bDeleteSurface+0x12:
    bf809647 8539            test    dword ptr [ecx],edi
    ds:0023:00000000=????????
    .trap
    Resetting default scope
     
    CUSTOMER_CRASH_COUNT:  4
     
    DEFAULT_BUCKET_ID:  CODE_CORRUPTION
     
    BUGCHECK_STR:  0x8E
     
    PROCESS_NAME:  explorer.exe
     
    LAST_CONTROL_TRANSFER:  from bf813811 to bf809647
     
    STACK_TEXT:
    f76564f0 bf813811 00000000 4b050e63 e3e6a878
    win32k!SURFREF::bDeleteSurface+0x12
    f7656504 bf83756c 4b050e63 e238c048 f765652c win32k!bDeleteSurface+0x20
    f7656514 bf8c2421 e3e6a888 00000000 e1473790 win32k!vSpDeleteSurface+0x1c
    f765652c bf8c2bf5 e238c048 f7656578 00000000 win32k!psoSpGetComposite+0x32
    f7656594 bf864d97 e238c048 e1473790 00000000 win32k!vSpRedrawArea+0x5e
    f76565d8 bf864c0e e238c008 00000000 00000000 win32k!bSpUpdateSprite+0x172
    f7656630 bf889c03 e1ccc2d8 0001009e 00000000 win32k!GreUpdateSprite+0xae
    f7656694 bf803bbb e374da18 c6011716 bbeefc18 win32k!UpdateRedirectedDC+0xf1
    f76566ac bf803cf2 c6011716 00000000 f7656714 win32k!ReleaseCacheDC+0x5f
    f76566bc bf80ad30 c6011716 f76567a4 bf80ee6d win32k!_ReleaseDC+0xf
    f7656714 bf80ec8e bbeefc18 00000085 00000001
    win32k!xxxRealDefWindowProc+0x7ad
    f765672c bf81c33e bbeefc18 00000085 00000001
    win32k!xxxWrapRealDefWindowProc+0x16
    f7656748 bf80eed5 bbeefc18 00000085 00000001 win32k!NtUserfnNCDESTROY+0x27
    f7656780 8054163c 0001009e 00000085 00000001 win32k!NtUserMessageCall+0xae
    f7656780 7c90e514 0001009e 00000085 00000001 nt!KiFastCallEntry+0xfc
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    017ff8f8 00000000 00000000 00000000 00000000 0x7c90e514
     STACK_COMMAND:  kb
     
    CHKIMG_EXTENSION: !chkimg -lo 50 -d !win32k
    !chkimg -lo 50 -d !win32k
        bf809648 - win32k!SURFREF::bDeleteSurface+13
     [ c0:39 ]
    1 error : !win32k (bf809648)
     
    MODULE_NAME: memory_corruption
     
    IMAGE_NAME:  memory_corruption
     
    FOLLOWUP_NAME:  memory_corruption
     
    DEBUG_FLR_IMAGE_TIMESTAMP:  0
     
    MEMORY_CORRUPTOR:  ONE_BYTE
     
    FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_ONE_BYTE
     
    BUCKET_ID:  MEMORY_CORRUPTION_ONE_BYTE
     
    Followup: memory_corruption
     
    Debuglog2.txt is a little less obvious because
    DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) is usually attributed to out-of-date
    drivers, but the MODULE_NAME and IMAGE_NAME give it away
     
    STACK_COMMAND:  kb
     
    CHKIMG_EXTENSION: !chkimg -lo 50 -d !USBPORT
    !chkimg -lo 50 -d !USBPORT
        f1077648 - USBPORT!USBPORT_FlushMapTransferList+182
     [ e1:45 ]
    1 error : !USBPORT (f1077648)
     
    MODULE_NAME: memory_corruption
     
    IMAGE_NAME:  memory_corruption
     
    FOLLOWUP_NAME:  memory_corruption
     
    DEBUG_FLR_IMAGE_TIMESTAMP:  0
     
    MEMORY_CORRUPTOR:  ONE_BYTE
     
    FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_ONE_BYTE
     
    BUCKET_ID:  MEMORY_CORRUPTION_ONE_BYTE
     
    Followup: memory_corruption
     
     

    -- Mike Burr
    • Marked as answer by bidhangiri Sunday, August 29, 2010 9:10 AM
    Saturday, July 31, 2010 4:38 AM
  •  

    Hi,

     

    Thank you for visiting the Microsoft forum. This forum focuses on Perfmon and diagnostic tools. I am moving your question to the moderator forum ("Where is the forum for..?"). The owner of the forum will direct you to a right forum.

     

    Thanks.

    Bruce Adamczak

    Friday, August 27, 2010 7:43 PM
  • Thank you Mike for your help.

    It was indeed the memory. I replaced the memory and it seem ok so far. It has been one week since I replaced the RAM with no BSOD.

    So the way you have described, does that mean, Module Name and Image name are the lines that ideally tells us the real cause of BSOD?

    Kind Regrads

    Bidhan Giri

    Sunday, August 29, 2010 9:09 AM
  • Not always, but it does usually provide a good first step. Occasionally you get errors where the image and module name are meaningless, as is the case witha  failing processor. Here's an example of a processor cache issue that I worked on,

    http://mikemstech.blogspot.com/2010/07/windbgkd-debugging-processor-cache.html


    -- Mike Burr
    Monday, August 30, 2010 12:46 AM
  • Wow!! You got Accounting degree as well. Awesome. Thats a 180 degree the other way round.

    Thank you again for helping me out on my Debugging issue. Like your blog. I am not into web development but I will certailnly keep following your Mike's Microsoft Technogies Blog frequently. I am just getting greedy that I might keep finding better things in your blog. So yeah, Mike's Microsoft Technolgies blog is definitely for me but not the Mike's Development Blog.

    Please do keep up your good work.

    Kind Regards

    Bidhan Giri

    Monday, August 30, 2010 11:12 PM