locked
memory-mapped file Commit Charge (Windbg) RRS feed

  • Question

  • I tried to use Windbg in Live Kernel Debugger mode (lkd) to view details about file memory mapped by an application (dynamips-wxp-exe)

    lkd> !process 898627e0 1
    PROCESS 898627e0  SessionId: 0  Cid: 14f8    Peb: 7ffde000  ParentCid: 15c8
        DirBase: 0b4007a0  ObjectTable: e7360110  HandleCount: 330.
        Image: dynamips-wxp.exe
        VadRoot 893c16f0 Vads 125 Clone 0 Private 34357. Modified 28923. Locked 0.
        DeviceMap e61b5c90
        Token                             e7432940
        ElapsedTime                       00:21:50.042
        UserTime                          00:06:26.046
        KernelTime                        00:00:01.421
        QuotaPoolUsage[PagedPool]         346764
        QuotaPoolUsage[NonPagedPool]      13896
        Working Set Sizes (now,min,max)  (39378, 50, 345) (157512KB, 200KB, 1380KB)
        PeakWorkingSetSize                39378
        VirtualSize                       597 Mb
        PeakVirtualSize                   635 Mb
        PageFaultCount                    68497
        MemoryPriority                    BACKGROUND
        BasePriority                      8
        CommitCharge                      68385
    
    lkd> .process /P 898627e0
    Implicit process is now 898627e0
    
    
    lkd> !vad
    .....
    
    89a56240 (10)      69a50    71a4f      65536 Mapped       EXECUTE_WRITECOPY  \Documents and Settings\20144620\Desktop\CCIE\GNS3 Lab\ospf\working\c3725-adventerprisek9-mz.124-21a.bin-127.0.0.1.ghost
    .....
    
    
    lkd> !vad 89a56240 1
    
    VAD @ 89a56240
    
      Start VPN        69a50  End VPN    71a4f  Control Area  896b8ad0
      FirstProtoPte e5e3e000  LastPte e5e4dff8  Commit Charge    10000 (65536.)
      Secured.Flink        0  Blink          0  Banked/Extend        0
      File Offset          0  
          ViewShare CopyOnWrite EXECUTE_WRITECOPY
    
    ControlArea  @ 896b8ad0
      Segment      e116d588  Flink      00000000  Blink        00000000
      Section Ref         1  Pfn Ref        8000  Mapped Views        1
      User Ref            2  WaitForDel        0  Flush Count         0
      File Object  898bc580  ModWriteCount     0  System Views        0
    
      Flags (9008080) File WasPurged HadUserReference Accessed
    
          \Documents and Settings\20144620\Desktop\CCIE\GNS3 Lab\ospf\working\c3725-adventerprisek9-mz.124-21a.bin-127.0.0.1.ghost
    
    Segment @ e116d588
    Type nt!_MAPPED_FILE_SEGMENT not found 

    Here you can see file c3725-adventerprisek9-mz.124-21a.bin-127.0.0.1.ghost is memory mapped in the user virtual memory range 0x69a50000 - 0x71a4f000 (131KB) with attribute protection EXECUTE_WRITECOPY.

    However lkd show a commit charge of 262144 KB (65536 pages of 4KB each) 

    Why this difference between them ? Can some expert help me ?

    Friday, April 6, 2012 1:54 PM

All replies

  • I'm not expert, maybe I'm wrong. When copy-on-write access is specified, the system and process commit charge taken is for the entire view because the calling process can potentially write to every page in the view, making all pages private. The contents of the new page are never written back to the original file and are lost when the view is unmapped. http://msdn.microsoft.com/en-us/library/windows/desktop/aa366761(v=vs.85).aspx

    I'm preparing for the exam 70-660 TS: Windows Internals


    
    • Edited by sergmat Saturday, April 7, 2012 6:24 AM
    Friday, April 6, 2012 10:34 PM
  • Thanks for reply....

    Yes, I know this behaviour for copy-on-write pages

    But.....AFAIK Commit Charge value should be include only (RAM + pagefile) backed memory pages and not pages backed by files on disk (EXE, DLL or data file)

    So I expected to find there only the quota backed by RAM + pagefile (basically half of total: 32768 pages 4KB each)

    Does it make sense ?

    Saturday, April 7, 2012 10:05 AM
  • I think that CommitCharge in virtual address descriptor structure _MMVAD   contains total amount of pages referencing to the range of virtual memory which _MMVAD describes. It limits 2GB (x86) virtual address space. There is no difference what kind of backing these pages. http://www.reactos.com/wiki/Techwiki:Ntoskrnl/MMVAD

    lkd> dt _MMVAD_FLAGS

    nt!_MMVAD_FLAGS

    +0x000 CommitCharge : Pos 0, 19 Bits


    I'm preparing for the exam 70-660 TS: Windows Internals


    • Edited by sergmat Saturday, April 7, 2012 2:26 PM
    Saturday, April 7, 2012 2:25 PM
  • i guess, if the file is mapped as image section, mm will charge its full size, even if it's partially mapped.
    Sunday, April 8, 2012 10:42 AM
  • John, how can check if file is mapped as image section ?

    !vad show other EXECUTE_WRITECOPY mapped regions haven't "double counted" commit charge; for example

    lkd> !vad 8956fbf0 1
    
    VAD @ 8956fbf0
      Start VPN        10000  End VPN    1004b  Control Area  894ee838
      FirstProtoPte e7cbad70  LastPte fffffffc  Commit Charge        c (12.)
      Secured.Flink        0  Blink          0  Banked/Extend        0
      File Offset          0  
          ImageMap ViewShare EXECUTE_WRITECOPY 
    
    ControlArea  @ 894ee838
      Segment      e7cbad30  Flink      00000000  Blink        00000000
      Section Ref         0  Pfn Ref          27  Mapped Views        1
      User Ref            1  WaitForDel        0  Flush Count         0
      File Object  89561bd0  ModWriteCount     0  System Views        0
    
      Flags (90000a0) Image File HadUserReference Accessed 
    
          \WINDOWS\system32\wpcap.dll
    
    Segment @ e7cbad30
      ControlArea     894ee838  BasedAddress  10000000
      Total Ptes            4c
      WriteUserRef           0  SizeOfSegment    4c000
      Committed              0  PTE Template  894ee90800000420
      Based Addr      10000000  Image Base           0
      Image Commit           b  Image Info    e7cbafd0
      ProtoPtes       e7cbad70
    What is the difference with case previously exhibited ?


    • Edited by cianfa7 Monday, April 9, 2012 7:15 PM
    Sunday, April 8, 2012 6:19 PM
  • Any answer ? Thanks
    Thursday, April 12, 2012 1:33 PM