Status code · Address space
BadNoContinuationPoints
BadLarge browse
BadNoContinuationPoints means the server's pool of continuation points is exhausted, usually because clients hold points they never finished or released. Release abandoned points, page one traversal at a time per session, and reduce how much paging you need by filtering the browse.
Defined behaviour: The server has no continuation points left to allocate for this request. (our description of the condition this code reports)
What you actually see
Browse or HistoryRead starts failing for every client on a busy server, and the failures clear after clients are restarted rather than after any server change.
Why it happens
- Clients leaking continuation pointsA traversal abandoned without releasing its point leaves server state behind until it times out. A client that starts many traversals and abandons them - because of an exception, a user cancelling, or a shutdown path that does not clean up - accumulates points quickly. The pool is shared, so one badly behaved client breaks browsing for everyone.
- Too many concurrent traversalsServers cap concurrent continuation points per session and in total. A client that parallelises a whole-model browse across many workers can exhaust its own allowance immediately, which looks like a server limitation but is a client design choice.
- Many clients browsing at onceCommissioning and discovery activity concentrates browsing: several engineers with browser tools, a collector building its configuration, and an HMI resolving tags all at the same moment. The pool is a shared resource and this is when it runs out.
- Small pool on an embedded serverPLC and device servers allocate very few continuation points because each one is memory they cannot spare. What is comfortable on a PC-based server exhausts a controller. The design consequence is that whole-model browsing is not appropriate against such devices.
- Points held by sessions that are gone but not yet cleaned upSessions abandoned rather than closed hold their points until the session times out. A client that reconnects repeatedly without closing leaves a trail of sessions each holding state, and the pool drains over time rather than all at once.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Release every continuation point you abandonAdd a release path to your traversal code: on exception, on cancellation and on shutdown, call BrowseNext with releaseContinuationPoints set for any point you hold. This is the single highest-value fix and it is usually a few lines.
- Serialise traversals within a sessionPage one browse at a time per session rather than parallelising. Paging is fast when you do not block between pages, so serial traversal is rarely slower in practice and it keeps your point usage at one.
- Ask for fewer references so you need fewer pagesSet MaxReferencesPerNode to a value the server can return comfortably and filter by ReferenceTypeId, IncludeSubtypes, NodeClassMask and ResultMask. A browse that completes in one call needs no continuation point at all.
- Prefer path translation and type-driven traversalWhere you know the model, TranslateBrowsePathsToNodeIds resolves what you need without paging. Type-driven traversal - browse the ObjectType, then find its instances - also visits far fewer nodes than a blind walk of the whole address space.
- Close sessions properlyCall CloseSession on shutdown so the server releases the session's points and other state immediately rather than at timeout. Check the server's session diagnostics for sessions belonging to clients that are no longer running.
- Export the address space once for large or embedded serversFor a device with a small pool, or a model with tens of thousands of nodes, export a NodeSet and work from it offline. Repeated whole-model browsing against a controller is not a sustainable pattern regardless of how the paging is written.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | The managed browse helpers release points as they complete, but a cancelled or faulted traversal in your own code will not unless you add it. Wrap the traversal so the release runs on every exit path. |
| asyncua (Python) | Cancelled coroutines are a common source of leaked points. Put the release in a finally block so cancellation cannot skip it. |
| node-opcua | browseNext with releaseContinuationPoints frees server state. Add it to the error and abort paths of your traversal helper, not only to the success path. |
| open62541 (C) | Both the client and the server cap continuation points, and the server's limit is a configuration parameter. On a constrained target, reducing what you browse is more effective than raising the limit. |
| Siemens S7-1500 | The integrated server allocates few continuation points, so whole-model browsing from several clients at once is likely to exhaust them. Confirm the limits for your CPU and firmware with the vendor and design for path translation instead. |
| OPC Publisher | Its streaming and fast browse features exist for large address spaces and reduce the paging burden. A NodeSet export is the recommended approach for repeated whole-model work. |
What it looks like in the log
Browse failed: BadNoContinuationPoints (server pool exhausted)
Session holds 8 continuation points; server maximum per session reached
Releasing 12 continuation points on traversal abortConfirm the fix
Confirm browsing succeeds again for all clients without a server restart, and confirm your client holds at most one continuation point per session at any moment by logging acquisition and release.
Stop it happening again
Make continuation point release unconditional on every exit path, serialise traversals per session, filter browses so most complete in one call, close sessions on shutdown, and use NodeSet exports for large or embedded address spaces.
Verify before you rely on this: Continuation point pool sizes on embedded servers vary by model and firmware; confirm the limits for your hardware with the vendor rather than relying on a general figure.
Related status codes
Concepts on this page
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.