Question:

I've been getting some kernel traps lately. I don't have room to set up a dump partition. Is there a way to record the trap screen data other than writing it down?

Answer:

Some folks have reported that they can use the PrintScreen key. Mr. KIA has never been able to get the PrintScreen key to operate while the trap data is on the screen. However, there is an alternative. Get a copy of DumpTrapScreen. This utility can extract the traps screens from a dump image.

Add the command:

     TRAPDUMP=R0

to CONFIG.SYS and reboot.

When a trap occurs:

• Insert a formatted floppy when prompted.
• Wait for the dump tool write the first diskette.
• When the dump tool prompts for the second diskette, remove the first diskette and reboot.

      DumpTrapScreen a:\pdump.001 >trapscreen.txt

This will write the trap screen images found in the dump to the file trapscreen.txt.

There will usually be 3 trap screen images. corresponding the ring 3, 2 and 0. The kernel trap screen is usually the last screen and can be identified because it reports a CS value other that 5B. Selector 5B is reserved for ring 3 applications code.

Question:

How do I interpret a kernel trap dump screen?

Answer:

This is not a question with a simple answer. With just the trap dump screen, usually the best you can do is identity the failing component. To do this you are going to need Theseus (a system information tool available from IBM), some basic knowledge and a little luck. The Warp 4.5 version of Theseus is at ftp://service.boulder.ibm.com/ps/products/os2/fixes/v4.5warp/theseus4; the Warp 4 versions are at ftp://service.boulder.ibm.com/ps/products/os2/fixes/v4warp/theseus3.

Often just knowing where the trap is occurring is enough to know which driver or component to replace. The 3 most important numbers on the trap dump screen are labeled CS, EIP and CSLIM. Sometimes, DS will also be useful.

• CS is the Selector of the Code Segment and identifies the area of memory that contains the failing code.
• EIP is the Extended Instruction Pointer and identifies the location of the failing instruction within this area.
• CSLIM is the size of the memory segment identified by CS.
• DS is the Selector of the Data Segment and identifies the one of the areas of memory that failing code can access to read and write data.

If CSLIM is FFFFFFFF, this indicates the trap is in the kernel or in a 32-bit device driver. If CSLIM is anything else, the trap is either in a 16-bit device driver or in some part of the kernel that is still 16-bit code.

If the trap is in the 32-bit kernel code, run Theseus and select System -> Kernel Information -> System Arena Table. Scan the Linear Address column for largest address that is smaller than the EIP value. RMB on the address and select Describe. If you are lucky, you will recognize the owner of the memory object and this may give you some insight into what caused the trap.

If the trap is in a driver, run Theseus and select System -> General System -> Device Drivers and inspect the list. Scan the Header, Strategy and Limit columns for the driver with a matching CS or CSLIM value. In the Header and Strategy column the number to the left of the colon is the selector. The number to the right is the offset of the item within the memory segment. If you can't find an exact match, look for the values close to CS. A large driver my occupy several segments so the CS value may be one or two counts larger than that shown by Theseus in the Strategy column. If this doesn't provide a good match, check the Header column for a match with DS.

Good luck and happy hunting.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.