How to get the content of a Section object in a kernel dump

The section object from a 3thParty vendor is named rpsPdf10.mutex and it's intended use is to mimic a semaphore by writing a Boolean flag to it.

Using LiveKd and with a lot of help from SO, I've issued following command's trying to get detailed info of this Section object.

0: kd>!process 0 0 3thParty.exe
...
PROCESS fffffa800ea80060
    SessionId: 0  Cid: 0a00    Peb: fffdf000  ParentCid: 014c
    DirBase: 99349000  ObjectTable: fffff8a004448bf0  HandleCount: 338.
    Image: 3thParty.exe
...    

0: kd> !handle 0 7 fffffa800ea80060
         ...
         08  fffff8a012e26710 Section                   rpsPdf10.mutex
         ...

0: kd> !object fffff8a012e26710
Object: fffff8a012e26710  Type: (fffffa800cd7cea0) Section
    ObjectHeader: fffff8a012e266e0 (new version)
    HandleCount: 38  PointerCount: 39
    Directory Object: fffff8a00a980080  Name: rpsPdf10.mutex

0: kd> dt -r1 nt!_SECTION_OBJECT 0xfffff8a012e26710
   +0x000 StartingVa       : 0x00000022`00000100 Void
   +0x008 EndingVa         : 0x00000000`0008dfb0 Void
   +0x010 Parent           : 0xfffffa80`c0000001 Void
   +0x018 LeftChild        : (null) 
   +0x020 RightChild       : 0xfffffa80`00000034 Void
   +0x028 Segment          : 0xfffff8a0`102d7820 _SEGMENT_OBJECT
      +0x000 BaseAddress      : 0xfffffa80`0fbed900 Void
      +0x008 TotalNumberOfPtes : 1
      +0x010 SizeOfSegment    : _LARGE_INTEGER 0x1
      +0x018 NonExtendedPtes  : 0x1000
      +0x01c ImageCommitment  : 0
      +0x020 ControlArea      : (null) 
      +0x028 Subsection       : (null) 
      +0x030 MmSectionFlags   : 0xfffffa80`10987b10 _MMSECTION_FLAGS
      +0x038 MmSubSectionFlags : 0x00000000`03400000 _MMSUBSECTION_FLAGS

All this looks correct to me but how can I find the content the section?

points to note as in earlier answer machine is 32 bit and os is win7 and windbg version is insider preview 16278 commands are arch agnostic and pointer arithmetic if any are arch dependent
and the walk through is on live binary not in a dump as there is a very fair chance that the page might have been paged out in the dump and demo might be inconclusive i might add to this answer later

getting contents form section is kinda convoluted
(there are several types of Section like
1) ALPC section(com objects )
2) File backed Section
3) PageFileBacked Section etc

the walkthrough below is for a pagefile backed section (most common type)

Assuming you compiled and executed the code below
the exe will create a SectionObject in global namespace
and the contents will be backed by PagingFile and will be waiting for a keypress

#include <windows.h>
#include <stdio.h>
#define bsize 256
int main(){
    char szMsg[]={"Message from blabb to lieven from Stack Overflow."};
    int ret = NULL;
    HANDLE hMap = CreateFileMapping((HANDLE)-1,NULL,4,0,bsize,"Global\\MyMap");
    if(hMap){
        PCHAR buff = (PCHAR) MapViewOfFile(hMap,0xf001f,0,0,bsize);
        if(buff){
            CopyMemory(buff, szMsg, sizeof(szMsg));
            ret = getchar();
            UnmapViewOfFile(buff);
        }
        CloseHandle(hMap);
    }
    return ret;
}

assuming the process is waiting for a keypress launch livekd or setup a live kernel debugging connection if it is running in a remote machine / vm

C:>livekd -k "c:\Program Files\Windows Kits\10\Debuggers\x86\cdb.exe"

LiveKd v5.62 - Execute kd/windbg on a live system
Launching c:\Program Files\Windows Kits\10\Debuggers\x86\cdb.exe:

Microsoft (R) Windows Debugger Version 10.0.16278.1000 X86

get the the _EPROCESS and set context

kd> !process 0 0 secobj.exe

PROCESS 8605ab28  SessionId: 1  Cid: 0fbc    Peb: 7ffd9000  ParentCid: 0af4
    DirBase: 7e2712e0  ObjectTable: c288ba00  HandleCount:   9.
    Image: secobj.exe

kd> .process /p /r 8605ab28

Implicit process is now 8605ab28

kd> ? @$proc
Evaluate expression: -2046448856 = 8605ab28

kd> ?? (char *)@$proc->ImageFileName
char * 0x8605ac94
 "secobj.exe"

look for a handle of type Section in the current process notice since our section is named in global namespace windbg deciphers that for us

kd> !handle 0 3 @$proc Section

Searching for handles of type Section

PROCESS 8605ab28  SessionId: 1  Cid: 0fbc    Peb: 7ffd9000  ParentCid: 0af4
    DirBase: 7e2712e0  ObjectTable: c288ba00  HandleCount:   9.
    Image: secobj.exe

Handle table at c288ba00 with 9 entries in use

0024: Object: c238e9c8  GrantedAccess: 000f0007 Entry: c37b7048
Object: c238e9c8  Type: (84ec6040) Section
    ObjectHeader: c238e9b0 (new version)
        HandleCount: 1 PointerCount: 2
        Directory Object: 98a0f170  Name: MyMap

dumping the SectionObject

kd> dt nt!_SECTION_OBJECT c238e9c8
   +0x000 StartingVa       : 0xc227e2c8 Void
   +0x004 EndingVa         : 0x00d3db6c Void
   +0x008 Parent           : 0xb0d3db20 Void
   +0x00c LeftChild        : (null)
   +0x010 RightChild       : 0x00000003 Void
   +0x014 Segment          : 0xc36aba20 _SEGMENT_OBJECT

kd> $$ Notice the Last Segment member it is not SEGMENT_OBJECT but
nt!_segment or actually a pointer to ControlArea for this Section

kd> dt nt!_SEGMENT 0xc36aba20
   +0x000 ControlArea      : 0x85182d08 _CONTROL_AREA
   +0x004 TotalNumberOfPtes : 1
   +0x008 SegmentFlags     : _SEGMENT_FLAGS
   +0x00c NumberOfCommittedPages : 1
   +0x010 SizeOfSegment    : 0x1000
   +0x018 ExtendInfo       : (null)
   +0x018 BasedAddress     : (null)
   +0x01c SegmentLock      : _EX_PUSH_LOCK
   +0x020 u1               : <unnamed-tag>
   +0x024 u2               : <unnamed-tag>
   +0x028 PrototypePte     : 0xc36aba50 _MMPTE
   +0x030 ThePtes          : [1] _MMPTE

kd> $$ you can expand the union u2 and dump the FirstMappedVa of the union to look at the contents of this Section

kd> dt nt!_SEGMENT u2.FirstMappedVa 0xc36aba20
   +0x024 u2               :
      +0x000 FirstMappedVa    : 0x000e0000 Void

dumping the contents

kd> da 0xe0000
000e0000  "Message from blabb to lieven fro"
000e0020  "m Stack Overflow."
kd>

or do !ca to get the FirstMappedVa which points to the first page
if the contents are greater than one page boundary fetching them is
kinda tedious as they may have been paged out and would need an execution operation and thus a page fault handled to get them into view

kd> !ca poi(0xc36aba20)

ControlArea  @ 85182d08
  Segment      c36aba20  Flink      00000000  Blink        00000000
  Section Ref         1  Pfn Ref           0  Mapped Views        1
  User Ref            2  WaitForDel        0  Flush Count         0
  File Object  00000000  ModWriteCount     0  System Views        0
  WritableRefs        0
  Flags (2000) Commit

      Pagefile-backed section

Segment @ c36aba20
  ControlArea       85182d08  ExtendInfo    00000000
  Total Ptes               1
  Segment Size          1000  Committed            1
  CreatingProcess   8605ab28  FirstMappedVa    e0000 <-------------
  ProtoPtes         c36aba50
  Flags (80000) ProtectionMask

Subsection 1 @ 85182d58
  ControlArea  85182d08  Starting Sector        0  Number Of Sectors    0
  Base Pte     c36aba50  Ptes In Subsect        1  Unused Ptes          0
  Flags               8  Sector Offset          0  Protection           4
kd>