.MO Output Field Descriptions

Output from .MO appears tabular for with one of the following headings:

 hob       va     flgs own  hmte  sown,cnt lt st xf
 0004  %fff13238  8000 ffe1 0000  0000 00  00 00 00 vmah
 0006  %fff0a891  8000 ffa6 0000  0000 00  00 00 00 mte       doscalls.dll

 hob     pob     har hobnxt flgs own  hmte  sown,cnt lt st xf
 0003 %fec80040  0003 fec8  0000 ffec 0000  0000 00  01 00 00
 0004 %fec80050  %fff13238  8000 ffe1 0000  0000 00  00 00 00

 hob   har hobnxt flgs own  hmte  sown,cnt lt st xf
 0001  0001 fec8  0000 fff1 0000  0000 00  00 00 00 vmob
 0002  0002 fec8  0000 ffe3 0000  0000 00  00 00 00 vmar

Each of the heading fields has the following meaning:

hob

The handle of the object record being formatted. This is the unique identifier by which the object record is known.
hobnext
The handle of next shared instance data object that maps to the same linear address range (shares the same arena record but maps to a different physical address).
har
The handle of the arena record that describes the linear address range allocated to this object.
pob
The linear address of the object record.
va
The virtual address of the pseudo-object named in the object description.
flgs
Object record flags.

The following flags are defined:

┌───────────────┬───────┬────────────────────────────────────────┐
│Name           │Bit    │Description                             │
│               │Mask   │                                        │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_PSEUDO      │0x8000 │Pseudo-object                           │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_API         │0x4000 │API located object                      │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_LOCKWAIT    │0x2000 │Waiting for a lock conflict to resolve  │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_LALIAS      │0x1000 │Object has aliases                      │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_SHARED      │0x0800 │Object's contents are shared            │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_UVIRT       │0x0400 │UVirt object                            │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_ZEROINIT    │0x0200 │Object is zero-initialised              │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_RESIDENT    │0x0100 │Initial allocation was resident         │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_LOWMEM      │0x0040 │Object is in low memory                 │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_GUARD       │0x0080 │Guard page attribute                    │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_EXEC        │0x0020 │Executable attribute                    │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_READ        │0x0010 │Readable attribute                      │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_USER        │0x0008 │User attribute                          │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_WRITE       │0x0004 │Writeable attribute                     │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_HUGE        │0x0002 │Object is huge                          │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_SHRINKABLE  │0x0001 │Object is Shrinkable (only if also      │
│               │       │OB_SHARED)                              │
├───────────────┼───────┼────────────────────────────────────────┤
│OB_DHSETMEM    │0x0001 │DevHlp_VMSetMems are allowed the object │
└───────────────┴───────┴────────────────────────────────────────┘

Notes:

See Pseudo-Objects when OB_PSEUDO is set.

OB_API is set as a result of allocation made by some APIs (for example, DosExecPgm). It forces page alignment and signals a likelihood of long-term locking.

OB_HUGE is set when the object is created by DosAllocHuge API.

When OB_LOCKWAIT is set then the thread has detected a lock request conflict and wishes to wait for the conflict to resolve. The conflict occurs because a contiguous storage lock has been requested but cannot be satisfied because one or more of the pages are already short-term locked. If the current request is for a short-term lock then the thread will wait up to 10 seconds for the conflict to clear. If the time-out expires then the current short-term lock request ends in error and the following message appears on the debugger screen:

VMLOCK: Short term lock for > 10 secs: hob=hob

If the current request is for a long-term lock then the thread will wait indefinitely. In both cases the block Id the thread waits on is the address of the VMOB flag word (VMOB+0x4). See .PB command for information on thread slots waiting on Block Ids.

own
This is the hob of the owner of this object. The owning hob may be in one of three categories:
• System Owner
  Used to indicate system owned objects. The owner description usually indicates the type of object that is being displayed. For example, the LDT for process 9 running pulse.exe is owned by system object 0xffb9 and has a description
  ldt 0009 c:pulse.exe.
  2. Module Owner (hmte)
  This is used for shared (code and data) objects that are part of a load module file. The .hmte of the associated load module is used as the Owner Id for the object. The object description names the owning module from the MTE/SMTE structures. See .LM command for related information.
  3. Process owner (hptda)
  Process owned objects are those allocated in the private arena of a running process and are either dynamic allocations or non-shared module segments, for example stack segments. The hptda of the process is used as the owner. The owner description names the process id and executable module of the owning process.
  hmte
  This names the hmte or System Object Id of the executable code that allocated the memory object or in the case of data segments of modules, whith which they are associated.
  sown
  Semaphore owner id. This is the thread slot number that owns the memory management semaphore associated with this object. Memory management uses the address of the VMOB as the block Id to sleep on when the semaphore is held. This semaphore is used to serialise access to a VMOB structure. See .PB command for information on thread slots waiting on Block Ids.
  cnt
  Count of owners of the VMOB semaphore and wait flag.

  The low order bit of cnt is used as a wait indicator. The high order 7 bits are a count of the number of times the owning thread has requested the VMOB semaphore without releasing it. See sown filed above for related information.

  xf
  Extra flags.

  The following flags are defined:

  ┌────────────────┬─────┬────────────────────────────────────────┐
  │name            │bit  │description                             │
  │                │mask │                                        │
  ├────────────────┼─────┼────────────────────────────────────────┤
  │VMOB_SLOCK_WAIT │0x01 │Waiting on short term locks to clear    │
  ├────────────────┼─────┼────────────────────────────────────────┤
  │VMOB_LLOCK_WAIT │0x02 │Waiting on long term locks to clear     │
  ├────────────────┼─────┼────────────────────────────────────────┤
  │VMOB_DISC_SEG   │0x04 │Object is part of a discardable seg     │
  ├────────────────┼─────┼────────────────────────────────────────┤
  │VMOB_HIGHMEM    │0x08 │Object was allocated via dh_vmalloc     │
  │                │     │using the VMDHA_USEHIGHMEM flag         │
  └────────────────┴─────┴────────────────────────────────────────┘
  

  Notes:

  The lock wait flags indicate that a thread is waiting for locked pages in the memory object to be unlocked, but not to resolve a conflicting lock request: that is indicated with the OB_LOCKWAIT flag.

  If a thread blocks waiting for long-term locks to clear then the address of the long-term lock count (VMOB + 0xd) is used as the Block-Id the thread blocks on. The thread blocks indefinitely.

  If a thread blocks waiting for short-term locks to clear then the address of the short-term lock count (VMOB + 0xe) is used as the Block-Id the thread blocks on. The thread will block for up to 10 seconds. If after that time the short-term lock has not been cleared then an error is returned and under the debug kernel the following message is sent to the debug console:

  VMLOCK: Short term lock for > 10 secs: hob=hob
  

  See .PB command for information on thread slots waiting on Block Ids.

  lt
  Count of active long-term lock holders. A non-zero value indicates one or more pages of the memory object have been long-term locked, that is prevented from being paged out from physical storage. Long-term locks are expected to be held for a relatively long period of time, in the order of seconds. See .MP command for information on displaying physical storage status. See also VM Lock Trace Kernel Debugger facility.
  st
  Count of active short-term lock holders. A non-zero value indicates one or more pages of the memory object have been short-term locked, that is prevented from being paged out from physical storage. Short-term locks are expected to be held for a relatively short period of time, in the order of mili-seconds. See .MP command for information on displaying physical storage status. See also VM Lock Trace Kernel Debugger facility.
  description
  The object description appears to the right of the tabular display. It is combines the interpretation of own and hmte fields. The following forms are possible:

  Process owned objects

  
  These appear as:
  priv pid process
  where:
  pid
  is the owning process id
  process
  is the executable running the owning process
  MTE Owned objects
  These appear as:
  shared module
  where:
  module
  is the name of the module that contains the object (hob) displayed.
  PTDA Pseudo-objects
  These appear as:
  ptda pid process
  where:
  pid
  is the process id in which the object is located.
  process
  is the executable running the owning process
  MTE Pseudo-objects
  These appear as:
  mte module
  where:
  module
  is the module name that corresponds to the MTE pointed to by the va
  LDT occupying storage
  This appears as:
  ldt pid process
  where:
  pid
  is the id of the process that owns the LDT related to the object
  process
  is the executable running the owning process
  Free objects
  These appear as:
  free
  System Owned Objects
  These appear as:
  owner user
  where:
  owner
  is the system object name corresponding to the own field.
  user
  is the system object name corresponding to the hmte field.

  Note: From fix pack 29 of Warp 3.0 and GA Warp 4.0 the hmte of all objects with a system owner id is also formatted in the user part of the description.

  ---

  [Back: System Object IDs]
  [Next: .MP - Format Memory Page Frame Structures (PFs)]