DOS/4G and DOS/4GW FAQ:
Interpreting Error 2002

1. I'm getting an error 2002 (transfer stack overflow). What shoud I do?

1. I'm getting an error 2002 (transfer stack overflow). What shoud I do?

Your program has overflowed the kernel's internal transfer stack. The transfer stack is an internal stack that the kernel uses when you signal an interrupt, or when a hardware interrupt occurs in protected mode. The kernel prints a register dump of the transfer stack frame after it prints error 2002. If the CrashVerbose option is set to ON, you'll also see register dumps for two previous transfer stack frames.

This sample shows the kind of information provided when a stack overflow occurs and the kernel output when the CrashVerbose option is set to ON.

1->DOS/4G error (2002): transfer stack overflow on interrupt 70h at 170:0042C002
   TSF32: prev_tsf32 48C8
   SS        C8 DS       170 ES        28 FS         0 GS       20
   EAX AAAAAAAA EBX BBBBBBBB ECX CCCCCCCC EDX DDDDDDDD
   ESI 51515151 EDI DIDIDIDI EBP B1B1B1B1 ESP     4884
   CS:IP  170:0042C002 ID 70 COD        0 FLG        2
   ...
2->Previous TSF:
   TSF32: prev_tsf32 498C
   SS        C8 DS       170 ES        28 FS         0 GS       20
   EAX AAAAAAAA EBX BBBBBBBB ECX CCCCCCCC EDX DDDDDDDD
   ESI 51515151 EDI DIDIDIDI EBP B1B1B1B1 ESP     4690
3->CS:IP  170:0042C002 ID 70 COD        0 FLG        2
   ...
   TSF32: prev_tsf32 67E4
   SS       178 DS       170 ES        28 FS         0 GS       20
   EAX AAAAAAAA EBX BBBBBBBB ECX CCCCCCCC EDX DDDDDDDD
   ESI 51515151 EDI DIDIDIDI EBP B1B1B1B1 ESP   42FFE0
4->CS:IP  170:0042C039 ID 70 COD        0 FLG      202
5->Opcode Stream: CF 66 B8 62 25 66 8C CB 66 8E DB BA 00 C0 42 00
   Last 4 ints: 70 @ 170:42C002/70 @ 170:42C002/70 @ 170:42C002/70 @ 170:42C002/

1. This program overflowed the transfer stack when it tried to process an Interrupt 70h at 170:0042C002.

2. The kernel displays the entire interrupt history from the transfer stack, from most recent interrupt to least recent interrupt. The prev_tfs32 numbers increase with each listed interrupt. All of these interrupts are still pending - this is why the program ran out of transfer stack.

3. Before the program overflowed the stack, it got the same interrupt at the same address. This is typical of a recursive interrupt.

4. The oldest frame on the transfer stack shows that the recursion was touched off at a slightly different address (170:42C030). Looking at this address may help you understand the recursion.

5. The opcode stream and last four interrupt information comes from the newest stack frame.