| Record # |
Length |
Function / Map Type |
Return Code |
Handle |
PID |
TID |
Summary Interpretation |
Notes |
| 1 |
72 |
- |
- |
- |
- |
- |
GIS OS/2 2.45A |
This record appears in every Kernel Trace file.
It records some basic data about the system being traced, including OS/2
version, system date/time, boot drive and more. |
| 2 |
15 |
File |
- |
79 |
- |
- |
MAP File \DEV\CON to 79 |
File map records associate a file or device name with
a "System File Number" or SFN. This SFN can be found in the "Handle" column
of any file oriented tracepoint. For example: the "Write(Pre)" tracepoint
in record # 4 is operating on the SFN 79. This is known to refer to \DEV\CON
based on this map current record. \DEV\CON is the console or STDOUT
to the CMD.EXE. |
| 3 |
2963 |
Process |
- |
54 |
54 |
1 |
MAP Process C:\OS2\CMD.EXE to 54 |
Process map records associate a specific process name
with a "process ID" or PID. This PID can be found in the "PID" column
of virtually all tracepoints (except MAP records and the GIS record at
the beginning of the trace. For example: the "Write (Pre)" tracepoint in
record # 4 was generated by PID 54 which is known to be C:\OS2\CMD.EXE
based on this current map record. CMD.EXE is also known as the "OS/2
Window" or OS/2 command prompt. |
| 4 |
22 |
Write (Pre) |
- |
79 |
54 |
1 |
WRITE SFN=79 CBBUF=2 |
The CMD.EXE is writing 2 bytes to the \DEV\CON device.
The actual bytes being written can be seen in the hexdump as "uninterpreted
payload data". In this case one can see a 0x0D0A. This is the ASCII carraige
return/line feed combination. This is due to the user's pressing of the
enter key after typing the REXX program name to execute. |
| 5 |
27 |
Write (Post) |
VIOKBD Req |
79 |
54 |
1 |
WRITE SFN=79 CBBUF=2 VIOKBD Req |
Don't be fooled by the error being returned in the
Write (Post). All writes to the \DEV\CON by CMD.EXE do seem to work,
even though they always get this same "VIOKBD Req" error. This is probably
an ancient (yet harmless) defect in the CMD.EXE, which will probably never
be fixed. |
| 6 |
369 |
Find First |
OK |
2 |
54 |
1 |
FIND D:\tutorial\hello\hello.CMD OK |
CMD.EXE is searching (DosFind*) for this specific
file (our example REXX program). The "OK" return code signifies that the
file has been found successfully. The "Handle" of 2 is the handle
identifying the search in progress. For searches that require multiple
calls to DosFind*, this handle is used to tell OS/2 that the subsequent
call is related to a specific original search. |
| 7 |
15 |
Find Close |
- |
- |
54 |
1 |
FIND CLOSE 2 |
This shows that CMD.EXE is done looking for HELLO.CMD.
Note that the FIND CLOSE is for search handle 2. This is how we knew that
this was the end of the search for that specific filename. |
| 8 |
38 |
Open (Pre) |
- |
257 |
54 |
1 |
OPEN C:\OS2\CMD.EXE |
CMD.EXE PID 54 is using DosOpen() to request
that the CMD.EXE program's file be opened. Note that this will also show
the details of how a file is opened. For example, if a file is opened
read-only. |
| 9 |
21 |
File |
- |
257 |
- |
- |
MAP File C:\OS2\CMD.EXE to 257 |
Until this file is closed, all SFN references to 257
will refer to HELLO.CMD. |
| 10 |
46 |
Open (Post) |
OK |
257 |
54 |
1 |
OPEN C:\OS2\CMD.EXE OK |
OS/2 reports that the file has been opened successfully. |
| 11 |
30 |
Loader Open |
- |
257 |
54 |
1 |
LOADEROPEN C:\OS2\CMD.EXE |
The loader now officially opens this DLL on behalf
of the CMD.EXE which executed the "start" command. |
| 12 |
31 |
Change File Pointer |
- |
257 |
54 |
1 |
CHGFILEPTR SFN=257 OFF=0 |
- |
| 13 |
19 |
Read (Pre) |
- |
257 |
54 |
1 |
READ SFN=257 64 bytes |
The following records (through record 16) are the
reading of the CMD.EXE loader tables in the executible's header.
This information is used to by the loader to load the executible code of
the EXE into memory on behalf of the requesting process (CMD.EXE PID 54).
In this frame, the first 64 bytes of the EXE are requested to be read. |
| 14 |
88 |
Read (Post) |
OK |
257 |
54 |
1 |
READ SFN=257 64 bytes OK |
The first 64 bytes are read successfully. This is
the loader reading the EXE's DOS 2.0 compatible EXE header . All
Linear Executible (LX) files have this header. It allows the EXE/DLL
to gracefully fail to load in DOS environments. At offset 0x3C of the executible
file, one can see the offset of the "real" 32-bit LX header itself. This
can be seen in the hexdump at offset 0x54 in the record, as the hexidecimal
number 0xF0 or decimal 240 |
| 15 |
31 |
Change File Pointer |
- |
257 |
54 |
1 |
CHGFILEPTR SFN=257 OFF=240 |
The current seek position is set to byte 240 (0xF0). |
| 16 |
19 |
Read (Pre) |
- |
257 |
54 |
1 |
READ SFN=257 196 bytes |
196 bytes are requested to be read. |
| 17 |
220 |
Read (Post) |
OK |
257 |
54 |
1 |
READ SFN=257 196 bytes OK |
196 bytes are read successfully. This is the
32-bit LX header itself. |
| 18 |
15 |
Close |
- |
257 |
54 |
1 |
CLOSE SFN=257 |
CMD.EXE is closed. Note that after this record, the
SFN of 257 is no longer valid. |
| 19 |
26 |
Get Module |
- |
- |
54 |
1 |
GETMODULE C:\OS2\CMD.EXE |
This record shows that the loader is about to load
the CMD.EXE process. |
| 20 |
75 |
Execute Program |
- |
- |
54 |
1 |
EXECPGM C:\OS2\CMD.EXE |
The loader is starting this process using the command
line and program defined in this record. Using the details window one can
see that the arguments are /C D:\tutorial\hello\hello.cmd. |
| 21 |
79 |
Execute Program (Post) |
- |
91 |
54 |
1 |
EXECPGM C:\OS2\CMD.EXE |
This is the post record for the same EXECPGM event.
No errors have occured in the loader's start of this process. |
| 22 |
22 |
Write (Pre) |
- |
79 |
54 |
1 |
WRITE SFN=79 CBBUF=2 |
The records 22 through 27 are
generated by the original CMD.EXE process displaying its command prompt.
This can be seen from the hexdump window. |
| 23 |
27 |
Write (Post) |
VIOKBD Req |
79 |
54 |
1 |
WRITE SFN=79 CBBUF=2 VIOKBD Req |
- |
| 24 |
37 |
Write (Pre) |
- |
79 |
54 |
1 |
WRITE SFN=79 CBBUF=17 |
- |
| 25 |
27 |
Write (Post) |
VIOKBD Req |
79 |
54 |
1 |
WRITE SFN=79 CBBUF=17 VIOKBD Req |
- |
| 26 |
21 |
Write (Pre) |
- |
79 |
54 |
1 |
WRITE SFN=79 CBBUF=1 |
- |
| 27 |
27 |
Write (Post) |
VIOKBD Req |
79 |
54 |
1 |
WRITE SFN=79 CBBUF=1 VIOKBD Req |
- |
| 28 |
30 |
File |
- |
76 |
- |
- |
MAP File C:\OS2\DLL\DOSCALL1.DLL to 76 |
SFN 76 refers to DOSCALL1.DLL.
This is the core OS/2 kernel API as accessed from ring 3 applications.
This is the same thing as the control program API. |
| 29 |
2963 |
Process |
- |
91 |
91 |
1 |
MAP Process C:\OS2\CMD.EXE to 91 |
For the first time we actually
see our new process. This record not only shows this mapping to a PID (91)
but it more importantly shows the "Local Information Segment" and the process'
environment. This contains a great deal of data such as the parent's PID,
the process' module handle, stack size, process type as well as enviornment
information like the PATH, CLASSPATH and other environment variables. |
| 30 |
31 |
Change File Pointer |
- |
76 |
91 |
1 |
CHGFILEPTR SFN=76 OFF=16044 |
The next 5 records show some
code and/or data being read from the DOSCALL1.DLL. This is presumably being
done by the loader on behalf of the new process, since we haven't seen
a GETMODULE record for DOSCALL1.DLL. |
| 31 |
19 |
Read (Pre) |
- |
76 |
91 |
1 |
READ SFN=76 381 bytes |
- |
| 32 |
405 |
Read (Post) |
OK |
76 |
91 |
1 |
READ SFN=76 381 bytes OK |
- |
| 33 |
31 |
Change File Pointer |
- |
76 |
91 |
1 |
CHGFILEPTR SFN=76 OFF=16426 |
- |
| 34 |
19 |
Read (Pre) |
- |
76 |
91 |
1 |
READ SFN=76 139 bytes |
- |
| 35 |
163 |
Read (Post) |
OK |
76 |
91 |
1 |
READ SFN=76 139 bytes OK |
- |
| 36 |
18 |
Get Module |
- |
- |
91 |
1 |
GETMODULE PMVIOP |
The loader is "attaching" the
PMVIOP.DLL to the new CMD.EXE process. Note: nothing has to be opened in
this case, presumably because this DLL is already loaded by some other
process (like the original CMD.EXE). Since DLLs are loaded into shared
memory, once loaded by one process they are available to all. |
| 37 |
29 |
File |
- |
34 |
- |
- |
MAP File C:\OS2\DLL\PMMERGE.DLL to 34 |
The next 4 records show some
code and/or data being read from the PMSPL.DLL. This is presumably being
done by the loader on behalf of the new process, since we haven't seen
a GETMODULE record for PMSPL.DLL. |
| 38 |
31 |
Change File Pointer |
- |
34 |
91 |
1 |
CHGFILEPTR SFN=34 OFF=122510 |
- |
| 39 |
19 |
Read (Pre) |
- |
34 |
91 |
1 |
READ SFN=34 152 bytes |
- |
| 40 |
176 |
Read (Post) |
OK |
34 |
91 |
1 |
READ SFN=34 152 bytes OK |
- |
| 41 |
20 |
Get Module |
- |
- |
91 |
1 |
GETMODULE PMMRGRES |
The next 4 records show some
code and/or data being read from the PMMERGE.DLL. PMMERGE is the
DLL that provides the core PM API. This is presumably being done
by the loader on behalf of the new process, since we haven't seen a GETMODULE
record for PMMERGE.DLL. |
| 42 |
32 |
Get Module |
- |
- |
91 |
1 |
GETMODULE C:\OS2\DLL\PMATM.DLL |
The next 3 records show the
loader attaching the font handling DLLs to the new process. |
| 43 |
33 |
Get Module |
- |
- |
91 |
1 |
GETMODULE C:\OS2\DLL\PMUNIF.DLL |
- |
| 44 |
28 |
File |
- |
122 |
- |
- |
MAP File C:\OS2\DLL\PMUNIF.DLL to 122 |
- |
| 45 |
31 |
Change File Pointer |
- |
122 |
91 |
1 |
CHGFILEPTR SFN=122 OFF=43072 |
- |
| 46 |
19 |
Read (Pre) |
- |
122 |
91 |
1 |
READ SFN=122 720 bytes |
- |
| 47 |
744 |
Read (Post) |
OK |
122 |
91 |
1 |
READ SFN=122 720 bytes OK |
- |
| 48 |
35 |
Get Module |
- |
- |
91 |
1 |
GETMODULE C:\OS2\DLL\TRUETYPE.DLL |
- |
| 49 |
19 |
Get Module |
- |
- |
91 |
1 |
GETMODULE DISPLAY |
The next 21 records show the
video support being attached to the process and some code/data being read
from the DISPLAY.DLL. |
| 50 |
29 |
File |
- |
124 |
- |
- |
MAP File C:\OS2\DLL\DISPLAY.DLL to 124 |
- |