BadObjectDeleted
BadModel change
BadObjectDeleted means the node you are addressing existed and has since been removed. Address spaces are not static: job, result, file and alarm objects come and go, and reconfiguration deletes nodes wholesale. Stop caching NodeIds indefinitely - subscribe to GeneralModelChangeEvent and re-resolve from a stable anchor.
What you actually see
A subset of nodes that worked a moment ago starts failing while the rest of the address space is untouched, often after a job finished, a file was closed, or a configuration was activated.
Why it happens
- The node was a transient instanceSeveral information models create objects for the lifetime of something real and delete them afterwards: result objects in the Machinery Result model, job objects in Machinery Jobs, file objects opened through Part 20 file transfer, and alarm branches. Holding their NodeIds past their lifetime is a client design error, not a server fault.
- A reconfiguration or download removed the nodeDeleting a program block, removing an optional object, unloading a companion model or removing a device from a gateway deletes its nodes. Clients that cached NodeIds at commissioning keep asking for something that no longer exists.
- An aggregating server lost its upstream sourceWhere an aggregator mirrors a downstream server, removing that server removes the mirrored subtree. The aggregator is behaving correctly; the change originated a layer down and is invisible from the client's own logs.
- A session-scoped or dynamically created node endedSession diagnostics objects, temporary views and nodes created by AddNodes for a specific purpose disappear with their owner. A client that browsed them once and stored the result will fail on the next use.
- Monitored items outliving their targetA monitored item on a deleted node keeps reporting a Bad status rather than silently stopping. Clients that never inspect the per-item status keep a dead item forever and see a value frozen at its last good reading in downstream systems.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Subscribe to model change eventsCreate an event monitored item on the Server object and take GeneralModelChangeEvent seriously: when the server reports that nodes were added, deleted or their references changed, invalidate the affected part of your cache and re-resolve. This is the mechanism the specification provides precisely for this problem.
- Re-resolve from a stable anchor instead of cachingKeep a stable parent - a machine object, or the Objects folder at i=85 - and use TranslateBrowsePathsToNodeIds to obtain the current NodeId of the thing you need. Cache the anchor, not the leaf.
- Treat transient objects as transientFor results, jobs and files, read what you need while the object exists and store the data, not the NodeId. If you must follow them, drive from the event or the list node the model provides rather than from a stored identifier.
- Check per-item status on every monitored itemHandle a Bad status on a monitored item by removing and re-creating the item against a re-resolved NodeId. A collector that ignores per-item statuses will report stale values as if they were live.
- Correlate with change managementLine the first occurrence up against downloads, configuration activations and model updates. A deletion that matches a planned change needs a configuration fix; one that does not needs the server log.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | The reference server raises model change events when nodes are added or removed. On the client side, handle the event and drop cached NodeIds rather than relying on read failures to discover the change. |
| asyncua (Python) | Subscribe with a Subscription for events on the Server object to receive model change notifications, and re-run your browse-path resolution when one arrives instead of retrying the stored NodeId. |
| node-opcua | Monitored items on deleted nodes deliver a Bad status in the data change notification. Handle it in the same callback that handles values so a deletion is not mistaken for a stalled value. |
| Ignition | Tags pointed at deleted nodes go bad while their siblings stay good. Rebrowsing the server connection after a controller change refreshes the tag references and is the standard remedy. |
| OPC Publisher | Published nodes that disappear stop producing telemetry with an error per node rather than an overall failure. Re-validate published-nodes configuration after any address-space change. |
| UaExpert | Refreshing the browse tree after a reported change shows immediately whether the node is gone or simply moved. A node missing from a fresh browse settles the question. |
What it looks like in the log
BadObjectDeleted for ns=5;i=41207 - node no longer present in the address space
GeneralModelChangeEvent: 1 node deleted under ns=5;s=ResultManagement
MonitoredItem 118 reporting BadObjectDeleted; removing and re-resolvingConfirm the fix
Re-resolve the browse path from your anchor, confirm you receive a current NodeId, and check that the recreated monitored item reports Good values with fresh SourceTimestamps.
Stop it happening again
Cache anchors and browse paths rather than leaf NodeIds, subscribe to model change events on every long-lived connection, and treat result, job and file objects as short-lived by design.
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.