How to trace a mapped_file to the process/user who opened it RRS feed

  • Question

  • I can see 80,000 mapped_file open in a kernel dump. Is there a way to trace a given mapped_file to trace back to the user/process who opened it in the first place?

    For eg.


    0: kd> !ca 8e4d3ca8   

    ControlArea  @ 8e4d3ca8
      Segment      d67416b8  Flink      00000000  Blink        00000000
      Section Ref         1  Pfn Ref         303  Mapped Views        1
      User Ref            0  WaitForDel        0  Flush Count         0
      File Object  905ee740  ModWriteCount     0  System Views        1
      WritableRefs        0 
      Flags (8080) File WasPurged

          File: \WINDOWS\system32\capi.log

    Segment @ d67416b8
    Type nt!_MAPPED_FILE_SEGMENT not found.
    0: kd> !fileobj 905ee740 


    Related File Object: 0x8e4cfc08

    Device Object: 0x90723b88   \Driver\Ftdisk
    Vpb: 0x90c3ef40
    Event signalled
    Access: Read Write SharedRead SharedWrite

    Flags:  0x40042
     Synchronous IO
     Cache Supported
     Handle Created

    FsContext: 0xd85dd0d0 FsContext2: 0xd85dd218
    Private Cache Map: 0x8f1934d8
    CurrentByteOffset: 4797d4
    Cache Data:
      Section Object Pointers: 8f227ac4
      Shared Cache Map: 8f193400         File Offset: 4797d4 in VACB number 11
      Vacb: 90f03620
      Your data is at: d4df97d4


    From here, I dont know how to get the user/process who owned/opened this file. Any help would be appreciated.

    Thanks in advance.

    Friday, March 14, 2014 8:19 PM

All replies

  • Does looking for process, which has open handle to fileobj work for you?
    Open handles list
    It is possible, value at '_object_header - HandleInfoOffset' is 'Process object' itself (!pool), not 'object count data base'

    Vista32 - No warranty
    With kind regards


    Saturday, March 15, 2014 12:43 PM
  • Thank you, will check this and let you know.
    Monday, March 17, 2014 5:46 AM
  • That one is an excellent link, thank you verymuch for your help!!  It worked like a charm for 'cluster.log' file which has got one handle traced to 'Clussvc'.

    However, the 80K files (that I was speaking about seeing them in the kernel dump, btw its a W2K3R2-SP2) are all old log files, listed as mapped_file in the output of !memusage (and causing high paged pool usage with MmSt and other related tags) and they dont have any handles to them.


    For Eg. The output for one of those files is as below -

    2: kd> dt nt!_OBJECT_HEADER 8976cf08
       +0x000 PointerCount     : 0n2
       +0x004 HandleCount      : 0n0
       +0x004 NextToFree       : (null)
       +0x008 Type             : 0x90ea0e70 _OBJECT_TYPE
       +0x00c NameInfoOffset   : 0 ''
       +0x00d HandleInfoOffset : 0x8 ''
       +0x00e QuotaInfoOffset  : 0 ''
       +0x00f Flags            : 0x42 'B'
       +0x010 ObjectCreateInfo : 0x00000001 _OBJECT_CREATE_INFORMATION
       +0x010 QuotaBlockCharged : 0x00000001 Void
       +0x014 SecurityDescriptor : (null)
       +0x018 Body             : _QUAD

    2: kd> dd 8976cf08-8 l2
    8976cf00  00000000 00000000


    Could you please help me with any other ways on how track them to the process that loaded them first?

    Tuesday, March 18, 2014 1:40 PM
  • Here you can find a discussion, in case there exists no handle:
    Linking _FILE_OBJECT to process  
    Think, walking VAD-tree may be an option, but I suspect, there will be a lot of files left (FileObjects), which were already released, therefore cannot be mapped any more to a process - (process may even have gone already).

    Perhaps looking at a forensics tool like Volatility -
    'dumpfiles' plug-in
    may give some info/inspiration.

    No warranty
    With kind regards

    Wednesday, March 19, 2014 12:11 AM
  • Thanks for your valuable time answering my questions, I am working on this, please give me some more time, will update you how it goes.
    Tuesday, March 25, 2014 8:41 PM