PLC access violation troubleshooting for sporadic runtime faults

Match the symptoms to evidence

Use the timing of the exception to choose your first checks. Treat these as leads, not conclusions:

• Fault during startup: inspect initialization order, retained values and references used before their targets are ready.
• Fault after an online change: investigate stored addresses and references whose targets may have moved or changed. Address handling depends on the development system and target.
• Fault during a recipe, mode or communication update: inspect indices, counts and offsets derived from the incoming data.
• Fault after hours of operation: look for rare branches, counters reaching a boundary, stale references and earlier memory corruption.
• Fault reported inside a library call: check the arguments, buffer lengths and object lifetime at the caller. The location where the exception appears may not be where the invalid value originated.
• Fault returns after a restart: the restart may have cleared the exception state without removing its cause. Repeated resets are not a diagnostic fix.

First confirm that the controller actually recorded an exception. If only a separate display has stopped updating, investigate factory screen update delay rather than assuming a controller memory fault.

Preserve evidence before restarting

Follow the machine's approved stop and isolation procedure before changing the application or reproducing the fault. A diagnostic stop, download or restart can change outputs and sequence state. Keep all required safety functions effective throughout the work.

Before clearing the exception, capture whatever the target makes available:

• Exact exception text and faulting task.
• Call stack, instruction location and source location, if available.
• Controller firmware, runtime and development-system versions.
• Application build identifier and matching project archive.
• Operating mode, active recipe and recent input changes.
• Recent downloads, online changes and library updates.
• Relevant index, count, pointer and initialization-state values.

Use the matching build when interpreting addresses or source locations. A newer project may not map correctly to the application that stopped.

Do not dismiss communication or hardware evidence simply because the exception concerns memory. Received data can feed an invalid index, and runtime or library defects remain possible. Start with the recorded evidence instead of ruling out whole categories prematurely.

Add the runtime's documented checks

Where supported, compiler-inserted runtime checks can expose an invalid operation closer to its source. Some development environments provide functions named CheckBounds for array access and CheckPointer for pointer access. Availability, coverage and behavior vary by target and implementation.

Use the procedure documented for your installed software and controller:

1. Save the matching project and establish a controlled test configuration.
2. Identify the documented checks for array bounds and pointer access. Add range or division checks only where they address relevant operations.
3. Review what each check actually does. It may report an error, stop execution, substitute a value or adjust an index. Do not assume that adding a check automatically produces a useful breakpoint.
4. Configure the documented diagnostic response. Avoid custom check code that silently conceals an invalid access.
5. Build and deploy through the approved change procedure. Check task execution time and timing margin because additional checks add work.
6. Reproduce the relevant operating sequence and capture the check arguments, caller and call stack when available.

An invalid write can damage data before a later instruction faults. Investigate the earliest recorded invalid operation, not just the last visible exception.

Check coverage also has limits. Initialization paths, compiled libraries and external components may not receive the same instrumentation as ordinary application code. A run without a check event is useful evidence, but it does not establish that every memory access was valid.

Audit array indices and pointer lifetime

Follow every index back to its source

For each suspect array, write down its declared lower and upper bounds. Then inspect every expression that selects an element, including accesses inside helper functions.

An array declared as ARRAY[1..N] does not contain element zero. Look for loops that start at zero, counters that wrap, unsuccessful searches that return a sentinel value, and received values used directly as indices. Also check each dimension of a multidimensional array.

An out-of-range access does not necessarily trigger an immediate exception. It may reach adjacent accessible memory and corrupt another value, leaving the visible fault until later.

Where another task can update an index, review synchronization. A bounds check followed by an access using a newly changed index can defeat the intended validation. Use the platform's documented task-safe approach, such as validating a suitable local snapshot, while also accounting for concurrent changes to the associated data.

Check more than a nonzero address

Search for pointer declarations, address-taking operations, references and interface calls. For each one, establish:

• Where the address or reference is assigned.
• Whether assignment occurs before every possible use.
• Whether the target still exists when accessed.
• Whether the target has the expected type, size and alignment.
• Whether another task can change the pointer or target.
• What the runtime documents about address validity after online changes.

A null check only rejects a null value. A nonzero pointer can still refer to expired storage, the wrong object or an undersized buffer. Do not treat pointer <> 0 as a complete validity check.

Pay particular attention to addresses retained beyond a function call and addresses stored across application changes. Their validity depends on the storage lifetime and the runtime's documented behavior.

Correct the source rather than hiding it

If an invalid index reaches zero, changing an array from [1..N] to [0..N] may stop that particular access from falling outside the declaration. It does not explain why zero appeared.

Determine the intended indexing convention first. Then correct the cause: initialize the index before use, repair the loop limits, validate received values or handle a failed lookup explicitly.

Clamping every invalid index to the nearest valid element is not automatically a safe fix. It can select the wrong recipe entry or apply data to the wrong destination. Define an appropriate invalid-data response from the machine requirements, and make the condition visible through the documented diagnostic mechanism.

For pointer faults, correct ownership, initialization and lifetime rather than merely skipping a dereference. Decide what the application must do when the required target is unavailable.

If online changes are implicated, follow the vendor's documented limitations and recommended deployment procedure. A full download may be appropriate, but it requires its own review of initialization, retained data and machine state. It is not a universal repair for incorrect pointer logic.

Validate the change in a controlled test

Recreate the conditions that previously preceded the fault. Include startup, relevant restart types, mode transitions, recipe changes and communication interruptions where they affect the suspect code.

Exercise boundary values in a simulator or suitably isolated test arrangement. For an array, include its lower and upper bounds and the application's response to invalid inputs outside them. For references, cover use before initialization and after the target's documented lifetime ends. Do not force unsafe values into a running production machine.

Keep useful diagnostics active during validation where supported. Run beyond the previous fault interval, but also exercise the suspected branch deliberately. Elapsed time alone provides weak evidence for a rare-path defect.

Compare task execution time and timing margin with the intended production configuration. Record the corrected expression, the diagnostic evidence and the conditions covered. If checks will be removed, validate that final build too. Do not present one fault-free run as proof that the problem cannot recur.

Escalate with a useful fault record

If the source project is unavailable, use the vendor's supported diagnostic collection procedure and contact the machine builder or authorized support channel. Do not attempt to defeat project protection.

Provide the exact software versions, matching build information, exception record, call stack and sequence needed to reproduce the fault. Include the checks already performed and any recent application changes. If diagnostics point into a runtime or library despite valid inputs, preserve that evidence rather than repeatedly modifying unrelated application code.

Questions