none
Debugging with windbg. Unable to load PEB pointer RRS feed

  • Question

  • Hi,

    Im completely new to debugging with windbg, but I think I have got the debugging tools set up correctly. My problem is that I have two user-initiated memory-dumps from the same server and It seems I can only debug one of them.

    When I start up the one that is working I get this feedback:

    Loading Dump File [D:\work\memorydump\46.dmp]
    User Dump File: Only application data is available

    Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;SRV*d:\localsymbols*http://msdl.microsoft.com/download/symbols
    Executable search path is:
    Windows Server 2003 Version 3790 UP Free x64
    Product: Server, suite: TerminalServer SingleUserTS
    Machine Name:
    Debug session time: Tue May 14 13:41:27.179 2013 (UTC + 2:00)
    System Uptime: 82 days 19:48:15.281
    Process Uptime: not available
    ................................................................
    ................................................................
    ................................................................
    ................................................................
    ................................................................
    ................................................................
    ......................
    Loading unloaded module list
    ................
    00430052`0045004d ??              ???

    and afterwards commands like "!dumpheap -stat" returns what I expect.


    But when I start up the other dump-file the feedback starts out the same, but ends with this:

    Process Uptime: not available
    Unable to get PEB pointer
    66363863`665c676e ??              ???

    And when I try to run dumpheap i get this:

    0:068> !dumpheap -stat
    Failed to find runtime DLL (clr.dll), 0x80004005
    Extension commands need clr.dll in order to have something to do.
    0:068> .loadby sos clr
    Unable to find module 'clr'

    It's not me who have produced the dump-files, so I don't know if they have been made with different parameters or something. But I thought I would just ask here first if someone knew what might be the problem here before I requested a new dump-file. So if someone has any ideas here they would share I'd appreciate it.

    Best regards,
    Frank Johannessen.

    Thursday, June 6, 2013 1:39 PM

All replies

  • This one

    0:068> !dumpheap -stat
     Failed to find runtime DLL (clr.dll), 0x80004005
     Extension commands need clr.dll in order to have something to do.
     0:068> .loadby sos clr
     Unable to find module 'clr'
    indicates that a .NET 4.0 sos-extension-dll (did you load it with full-path?) is loaded, but clr.dll is missing in loaded-module list, which is unusual - if I assume a .NET 4.0 dump.
    You may verify existance of clr.dll with
    lmvm clr

    May happen for example, when dump from a .Net 4.0 application was taken before clr.dll was loaded in early start-up stage - though unlikely.
    - Besides, for a .NET 2.0/3.5 dump mscorwks.dll is needed for sos to succeed (clr.dll is lacking in this case). -

    To get some info about dumps (corruption?), one can use
    Dumpchk
    http://msdn.microsoft.com/en-us/library/windows/hardware/ff560109(v=vs.85).aspx
    Especially the 'flags' section will tell, which information is included in dump-files.

    No warranty
    With kind regards


    Thursday, June 6, 2013 9:35 PM
  • Hi and thanks for the answer,

    The sos.dll is loaded when i open both crash-dumps in windbg. Both dumps are for the same .net 4.0 application btw. running "lmvm clr" result in finding the dll on the working dumpfile and not finding it on the one not working.

    I tried running dumpchk on both dumps as well. Both reports ends with "Finished dump check" so i guess none of them are corrupt.  But the one not working mostly only gives me a long list of memory-addresses and the line before the last says "PEB NULL...". While the working dump also gives me a list of loaded dll's and env.variables etc.

    I guess ill have to ask for a new dump, and that the one who performs it does it in the same manner as the working dump.

    Friday, June 7, 2013 7:42 AM