BadTcpNotEnoughResources
BadServer limits
BadTcpNotEnoughResources means the peer could not allocate the memory or buffers needed for your connection or message. It is a capacity failure at the transport layer, common on embedded servers and on clients asking for very large chunk sizes. Reduce buffer demands and concurrent load, or give the host more memory.
What you actually see
Connections or large requests fail on a server that has been running for a while, often alongside subscription and browse failures, and often clearing after a server restart.
Why it happens
- Buffer sizes negotiated in Hello are too largeThe Hello and Acknowledge exchange negotiates ReceiveBufferSize, SendBufferSize, MaxMessageSize and MaxChunkCount. A client asking for very large buffers against a small embedded server can exhaust its allocator before a channel is even open.
- Too many concurrent connections or channelsEach transport connection and secure channel needs buffers and cryptographic state. A device rated for a handful of clients will run out of memory rather than politely refusing if the connection cap is set higher than the hardware supports.
- Memory pressure from subscriptions and queuesLarge monitored-item queue sizes multiply across items and subscriptions. Memory consumed by notification queues is not available for transport buffers, so an over-subscribed server starts failing connections.
- A leak or fragmentation over long uptimeIf the failure appears only after days or weeks of uptime and clears on restart, suspect a leak or heap fragmentation in the server. This is worth reporting to the vendor with the uptime and load profile.
- Very large requests or responsesA browse of a huge address space, a read of thousands of nodes, or a large structured value needs contiguous buffers. Related codes on the same path are BadTcpMessageTooLarge, BadResponseTooLarge and BadEncodingLimitsExceeded.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Lower the buffer sizes your client requestsReduce ReceiveBufferSize and SendBufferSize in the client transport configuration to values the server can serve, and lower MaxMessageSize accordingly. Confirm the negotiated values in the Acknowledge frame with a capture.
- Reduce the operation sizeSplit large Reads and Writes into batches, use MaxReferencesPerNode with BrowseNext for browsing, and prefer TranslateBrowsePathsToNodeIds over recursive browsing when you know the model.
- Cut queue sizes and item countsReview QueueSize on monitored items and the total item count against MaxMonitoredItemsPerSubscription from ServerCapabilities. Oversized queues are the most common hidden consumer of server memory.
- Count clients against the device's real capacityReduce concurrent clients and sessions on embedded servers rather than raising limits. One collector aggregating for several consumers is easier on the device than several consumers each holding a session.
- Check host memory and uptimeOn a software server, watch the process resident memory across a load cycle. If it climbs monotonically and never returns, gather the evidence and raise it with the vendor; schedule a restart as an interim measure.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | TransportQuotas in the configuration control buffer sizes, MaxMessageSize and MaxChunkCount on both client and server. Aligning client quotas with the server's is the fix in most cases. |
| open62541 (C) | UA_ServerConfig_setDefaultWithBufferSize and the connection config expose buffer sizes directly, which matters on microcontroller targets where memory is measured in kilobytes. |
| Siemens S7-1500 | Memory for the OPC UA server is bounded and shared with the control application. Large subscriptions and wide browses are the usual triggers; reduce item counts and queue sizes first. |
| node-opcua | The client accepts receiveBufferSize, sendBufferSize, maxMessageSize and maxChunkCount options. Defaults are generous and worth lowering when talking to embedded devices. |
| asyncua (Python) | Client.set_transport_limits and the server-side equivalents let you cap negotiated sizes. Batch large reads with read_values on chunks of nodes rather than one enormous call. |
What it looks like in the log
BadTcpNotEnoughResources while opening secure channel
Failed to allocate receive buffer of 16777216 bytes for connection from 10.20.3.15
Acknowledge negotiated receiveBufferSize=8192 maxMessageSize=2097152 maxChunkCount=64Confirm the fix
Reconnect with reduced transport quotas and confirm the negotiated Acknowledge values, then run the previously failing browse or read and watch server memory stay flat.
Stop it happening again
Set client transport quotas per server class rather than using one generous default everywhere, cap monitored-item queue sizes in configuration standards, and monitor server memory alongside connection counts.
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.