BadInternalError
BadServer fault
BadInternalError means the server hit a fault of its own while handling your request. It is a server-side defect or misconfiguration, not a client error. Capture the exact request that triggers it, get the server log for that timestamp, and give both to the vendor.
What you actually see
One reproducible request fails while everything else on the same session works, and the server log contains an exception or stack trace at the same instant.
Why it happens
- A defect on an unusual code pathRequests that are legal but rare, for example an empty IndexRange, an unusual browse mask, or a filter combination nobody tested, hit paths with weak error handling. The server converts its own exception into this code rather than crashing.
- A broken configuration or a corrupt address spaceA NodeSet2 imported with a dangling reference, a type without its encoding node, or a tag mapped to an address that no longer exists in the controller can make specific nodes fail while the rest of the server is healthy.
- A failure inside a vendor extension or driverWhere the server delegates a read or a method call to plug-in code, an exception there commonly surfaces as an internal error at the OPC UA boundary. The pattern is that all failing nodes belong to one driver, channel or device.
- A partially applied configuration changeOnline edits, program downloads and model changes that are applied while clients are connected can leave the server inconsistent until a restart. The failure appears at the moment of the change and persists.
- Resource exhaustion reported impreciselySome servers report allocation, handle and thread-pool failures as an internal error instead of a specific resource code. If the failure correlates with load rather than with a particular node, treat it as a resource problem.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Reduce the request to a minimal reproducerCut nodes, parameters and options until you have the smallest request that still fails. A one-node reproducer is worth far more to a vendor than a description of your application, and it often reveals the offending parameter to you first.
- Correlate with the server log by timestampNote the exact UTC time of a failing request and pull the server log around it. The exception text or configuration warning there usually names the real cause in one line.
- Test the same request against a reference serverRun it against opc.tcp://opcua.umati.app:4840 or a local reference server. If it succeeds there, your request is valid and the defect is in the target product.
- Check for a recent configuration or program changeAsk what changed at the time failures started: a NodeSet2 import, a PLC download, a firmware update, an online edit. Restarting the server after a partially applied change is a legitimate diagnostic step here.
- Escalate with the reproducer, the log and the versionSend the vendor the minimal request, the server log extract, and the BuildInfo product name, software version and build number. Also ask whether the affected functionality is covered by a certified facet.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | Reproducing the failure in UaExpert makes it independent of your client code, which is usually the first thing a vendor will ask you to do. |
| opcua-commander | Reproducing the failing read or call from a second, independent client confirms the defect is server-side before you open a vendor ticket. |
| UA-.NETStandard (C#) | The server maps unhandled exceptions in node managers to this code. Enabling verbose server tracing around the failing operation usually produces the stack trace directly. |
| node-opcua | On the server side, an exception thrown in a getter or a method binding becomes this code. Wrap bindings so they return a meaningful StatusCode instead of throwing. |
| KEPServerEX | Driver and plug-in faults appear in the event log on the server host. Match the timestamp of the failing request against that log rather than reading the OPC UA response alone. |
| Beckhoff TwinCAT | A symbol mapped to a variable that no longer exists after a program download can fail this way. Re-export the symbol configuration and reconnect after any download. |
What it looks like in the log
Read ns=4;s=Line1.Recipe returned BadInternalError
Unhandled exception in node manager while servicing Read; request failed
Configuration warning: encoding node missing for DataType RecipeTypeConfirm the fix
After the fix or restart, run the minimal reproducer repeatedly and confirm it succeeds every time, then re-run the full application workload for a shift with no recurrence in the server log.
Stop it happening again
Keep server versions current and consistent, validate NodeSet2 imports before deployment, restart after configuration changes that cannot be applied online, and alarm on this code specifically since it always indicates a server-side defect.
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.