Trace instruction execution within a single procedure. This command is very similar to the T command, except that CALL, loop and string repeat instructions are traced as single instructions (even though allowed to execute correctly).

Syntax:

ÄÄÄÄÄÄ P ÄÄÄÄÂÄÄÄÄÄÄÄÂÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÂÄÄÄÄÄÄÄÄÄÂÄÄ
               ÃÄ  N  Ä´  ÀÄ = ÄÄ start-addr ÄÄÙ   ÀÄ count ÄÙ
               ÀÄ  T  ÄÙ

Parameters:

• Default)
  Trace instruction execution by single-stepping, treating CALL loop and string repeat instructions as single events.

  Note:

  Certain areas of the system are known to cause problems if traced. Attempts to trace these areas are intercepted by the Kernel Debugger. See below for further information.

  N
  Trace instructions but suppress the register display after each instruction is executed.
  T
  This option causes the Kernel Debugger's trap vector handlers to be removed temporarily from the IDT and the system's re-instated until after then next instruction has executed. After execution of the next instruction the the Kernel Debugger's V commands are re-instated.

  This is a convenience option that saves manually unhooking a Kernel Debugger trap vector handlers from the IDT. using a command sequence similar to:

  VC n
  P
  VS n
  

  start-addr
  The address from which execution is to continue. This must be a valid address for the current context. If start-addr is omitted then execution continues from the current CS:EIP, as shown by the R command.
  count
  The number of instructions to trace before re-entering the Kernel Debugger unless one of the following conditions is encountered:
  A fatal exception occurs
  An Internal Processing Error (IPE) occurs.
  A 'sticky' breakpoint fires
  A non-maskable interrupt occurs
  An INT 3 instruction is executed
  The user enters Ctrl-C from the debugging console.

  If omitted then count defaults to 1 instruction.

  Results & Notes:

  The Ptrace commands trace the execution of machine instructions, and by default, display the current registers and next instruction to execute at each step. For the purposes of the displayed trace, the CALL instruction does not have the called routine traced, but tracing resumes on return. Loop and string repeat instructions are also treated as atomic entities with the instruction following the loop or repeat shown as the next to execute. INT 3 instructions are stepped over to avoid a double breakpoint at the same address even though they appear as the next instruction to execute.

  The following system routines are known to causes inconsistency or even system failure if traced. Consequently Ptrace will suspend tracing until after execution leaves these routines.

          _Debug_CtrlC32   through _EndCtrlC32
          _DebugLoadSymMTE through EndDebugLoadSymMTE
          _PGSwitchContext through pgSwitchRet
  
  

  See the TX command for information on tracing these routines.

  PN suppresses the register display from the automatic R command, but still displays an unassembled next instruction for each traced instruction. If the ZS command has been used to specify a different default command then PN behaves exactly as P.

  An example of the output from PN is as follows:

  ##PN 5
  0170:fff4521f 803d9e53e0ffff cmp     byte ptr [InterruptLevel (ffe0539e)],ff
  0170:fff45226 75b4           jnz     fff451dc
  0170:fff45228 803d9643e0ff00 cmp     byte ptr [_cTKNoBlock (ffe04396)],00
  0170:fff4522f 75be           jnz     fff451ef
  0170:fff45231 0f01e1         smsw    cx
  ##
  

  Note: The last traced instruction is the next to be executed.

  Warning:

  If any of the PTrace commands is interrupted, the Kernel Debugger may leave a temporary break-point active. This will result in a Trap 1 when the system is next given control. If this occurs then either of the PT or GT commands will clear this condition.

  ---

  [Back] [Next]