OBJECTS_OBJREF_NOT_ASSIGNED — Dereferencing an Unbound Object Reference
OBJECTS_OBJREF_NOT_ASSIGNED fires when ABAP code calls a method, reads an attribute, or otherwise dereferences an object reference variable that has never been bound to an instance, meaning it still holds its initial value. The runtime exception is CX_SY_REF_IS_INITIAL. It is almost always a missing CREATE OBJECT, a factory method that returned nothing, or a skipped branch, not a data or memory problem.
This page covers the OBJECTS_OBJREF_NOT_ASSIGNED short dump, which occurs when a program tries to use an object reference that has not been instantiated. It focuses on the practical causes ranked by frequency, how to read the dump and stack to find the responsible line, and the branching resolution path depending on whether the gap is a coding defect or a missing customizing dependency.
Published 16 Sept 2026· 1,265 words
What the dump means
An object reference variable in ABAP starts life as initial, the equivalent of a null pointer, until something assigns an instance to it with CREATE OBJECT, a factory method, a cast, or an assignment from another reference. OBJECTS_OBJREF_NOT_ASSIGNED is raised the moment code tries to use that still-initial reference: calling obj->method( ), reading obj->attribute, or passing it where an instance is required. The kernel throws exception class CX_SY_REF_IS_INITIAL, which is caught nowhere in the call stack, so it escalates to a short dump. It is not a syntax error and the ABAP compiler cannot catch it, because whether a reference is bound depends on runtime flow, not on the type definition. The line pointed to in the dump is the dereferencing statement, not necessarily the place where the instantiation should have happened.
Root causes that actually produce it
- Missing CREATE OBJECT: the reference is declared, used directly afterwards, and no CREATE OBJECT statement ever ran for it in that code path. Common after refactoring where an instantiation line was deleted or moved into a branch that does not always execute.
- Conditional instantiation: an IF, CASE, or LOOP creates the object only under certain conditions, and later code assumes the object always exists regardless of which branch ran. The dump only appears for the input combination that skips the CREATE OBJECT, which is why it often surfaces late in a transport's life, not in initial testing.
- Factory or getter method returning unbound: a method meant to hand back an instance (a singleton getter, a BAdI handler lookup, a strategy factory) returns without setting the reference, typically because no active implementation, no customizing entry, or no matching case was found. The caller does not check IS BOUND before use.
- Reading a reference from a table or structure that was never populated: an internal table of object references is empty, or a structure component holding a reference was never filled, and the code reads it with READ TABLE or table[ ] and uses the result without checking sy-subrc or CX_SY_ITAB_LINE_NOT_FOUND first.
- Reference passed in as an importing or changing parameter that the caller left unbound, especially in interfaces implemented differently across custom and standard code, or in test doubles that do not fully mimic production wiring.
- Downcast (?=) failure swallowed by a broad TRY...CATCH around CX_SY_MOVE_CAST_ERROR, where the catch block continues execution instead of exiting, leaving the target reference initial for the next statement.
- BAdI or enhancement spot with no active implementation: generated proxy code assumes an implementing instance always exists and dereferences it directly instead of checking the returned handle list.
What to inspect in ST22
- Short text and error analysis: confirms the exception class is CX_SY_REF_IS_INITIAL and states the name of the offending reference variable.
- Source code section: the highlighted line shows the exact dereferencing statement (-> or the method call). Note the enclosing method, function module, or event block from the call stack, not just this line.
- Active calls/events: read upward through the stack to identify where the reference was supposed to be set. The dump line is the symptom location, the missing CREATE OBJECT is usually several frames or several statements earlier.
- Variables at the time of the dump: display the reference variable in the debugger-style variable list, it will show as blank or all zeroes, confirming it never received an instance.
- Trigger condition: check what input, customizing, or master data record led to the branch that skipped instantiation, since the dump is usually data-dependent, not universal.
- Follow-on transactions: SE80 or SE24 to inspect the method's full source and signature, a breakpoint at the suspected CREATE OBJECT or factory call to confirm it is bypassed, and SAT or SE30 if the skip only happens under load or in a background variant that is hard to reproduce interactively.
Resolution path
If the cause is a straightforward missing or misplaced CREATE OBJECT, add it before first use, or move it out of the conditional branch so it always runs, and cover the fix with a unit test for the previously-skipped path. This is a code correction requiring a transport. If the cause is a factory or getter that legitimately returns nothing under some conditions, do not force it to always instantiate; instead add an explicit IS BOUND or IS INITIAL check at every call site and handle the empty case with a defined business outcome, such as an error message or a skip with logging, rather than assuming success. This is also a code change. If the cause is a missing BAdI implementation or missing customizing entry that the factory depends on, the code fix is the defensive check above, but the underlying gap needs a functional or configuration fix, filed as a separate customizing change request, since correcting the ABAP alone will only produce a clean error message instead of a dump, not restore the missing behavior. If the cause is an interface mismatch across custom exits, align the custom implementation's contract with what the caller expects and retest both sides together.
The fix people try first (and why it fails)
The near-universal first reflex is wrapping the dereferencing line in TRY...CATCH cx_root or catching CX_SY_REF_IS_INITIAL specifically and letting execution fall through silently. This stops the dump but does not create the missing instance, so the intended method call or attribute read simply never happens. Downstream logic that depended on that call's side effect, a posting, a status update, a validation, silently does not run, and the process looks like it completed successfully. This trades a visible, traceable dump for a silent data or process gap that surfaces much later and is far harder to diagnose.
Prevention
Treat any factory method, getter, or BAdI handler lookup that can plausibly return nothing as requiring a mandatory IS BOUND check at the call site, and enforce this through code review or an ABAP Test Cockpit check on unchecked reference use after known factory patterns. Favor constructor-based instantiation over conditional CREATE OBJECT scattered through branches. Add unit tests that specifically exercise the branch where instantiation is skipped, since that is exactly the path production testing tends to miss.
Whose problem this is
This is an ABAP development problem in nearly all cases, since the fix is either an instantiation correction or a defensive check in code. Functional involvement is needed only when the unbound reference traces back to missing customizing or an inactive BAdI implementation that a business process owner controls. The handover note should state the reference variable name, the enclosing method, the input or customizing condition that triggers the skip, and whether the gap is coding or configuration.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-abap-dumps/objects-objref-not-assignedERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.