SAP Dump analysis
ABAP short dumps are the detailed records of programs that terminated abnormally. Analysing them in ST22 is a fundamental SAP troubleshooting skill.
When a program or job crashes, open ST22, find the short dump by time and user, and read the runtime error name, the source line, the variables and the call stack. The usual causes, in order: a logic error such as a null reference, a TIME_OUT on a long online run, memory exhaustion from inefficient code, then data or configuration.
- Watch out: the runtime error name is the diagnosis; the source line only says where the program gave up.
Symptom
A user or job reports an error/crash; ST22 shows a short dump (runtime error) at that time.
Start here: read the evidence
Open ST22, find the dump by time/user, and read it: the runtime error name, the error text, the exact source line, the variable values and the call stack. The dump usually names the cause precisely.
Likely causes, in order
- Program/logic errors (e.g. null reference, MESSAGE_TYPE_X).
- TIME_OUT, a long-running online program (run in background).
- Memory errors (TSV_TNEW_PAGE_ALLOC_FAILED) from inefficient code.
- Configuration/data issues surfacing as exceptions.
How to fix it
- Read the runtime error name and source position.
- Search SAP Notes for the runtime error + program.
- Fix custom code, or apply the Note for standard code.
- Re-test and confirm no new dump.
Preventing recurrence
Most dumps in custom code trace to inefficient or unguarded logic (memory, timeouts, null access). Coding best practices (null checks, no SELECT-in-loop, background for long jobs) prevent the majority.
Common pitfalls
- Guessing instead of reading the log/dump.
- Fixing the symptom, not the root cause.
- Changing several things at once.