Resolving LabVIEW Network Stream Socket Error -1967390704

The signature is unmistakable: a network stream endpoint call returns -1967390704, the LabVIEW window stops repainting, the taskbar entry goes unresponsive, and the only way out is a force-quit followed by a restart of the NI PSP service. After the service comes back, everything runs normally again — which is exactly why the fault is hard to pin down. The recovery step erases the state that would have identified the cause.

Work the problem in commissioning order. Recover the machine, prove the transport, audit the endpoint code, remove the blocking call that turns a socket error into a hang, then instrument the machines so the next occurrence produces evidence instead of a shrug.

First Response: Clearing the Hung Session

Before anything else, capture state. Once the service restarts, the socket table is gone.

1. Open an administrative Command Prompt and dump the connection table for the PSP listener before touching anything: netstat -ano | findstr :3363 > C:\temp\psp_hang.txt. Add tasklist /svc > C:\temp\tasks_hang.txt.
2. Force-quit LabVIEW: taskkill /f /im LabVIEW.exe. If the built application is the client, kill that image instead.
3. Restart the variable/PSP services in dependency order — stop the variable engine, then start it, allowing the service locator to re-register: net stop "NI Variable Engine" then net start "NI Variable Engine". Confirm the exact display names on your install with sc query state= all | findstr /i "NI ".
4. Verify the listener is back: netstat -ano | findstr :3363 must show a LISTENING socket owned by the service PID.
5. Relaunch LabVIEW and re-open the stream. Do not move on until the reader and writer endpoints both create without error.

The reason the service restart works tells you where the fault lives. A network stream endpoint is not a raw TCP connection owned by your VI — the endpoint name is registered with the NI service locator, and the PSP process brokers the connection. When LabVIEW dies or a socket half-closes without a clean teardown, the registration and its associated socket can survive in the service. Re-creating an endpoint at the same URL then collides with the orphan, and the create call fails at the socket layer rather than reporting a clean "name in use" condition. Restarting the service flushes the registry and the orphaned sockets in one move.

Confirming the PSP Transport Is Reachable

Prove the transport on a healthy machine first so you know what "normal" looks like before the next failure.

Two environmental conditions produce intermittent socket-layer failures on machines that otherwise work for days: a profile change on the Windows firewall (a DHCP renewal or VPN attach moves the adapter from Private to Public and silently drops the inbound rule), and multi-homed hosts where the endpoint URL resolves to a different NIC than the one carrying traffic. If the affected computers have more than one active adapter, pin the URL to a literal IP address rather than a host name and re-test.

Do not move on until a remote TCP connect to port 3363 succeeds from the client while the fault-prone machine is idle.

Auditing Endpoint Names and Creation Code

Most recurring endpoint-creation failures trace to name reuse and missing teardown, not to the network.

1. Inventory every Create Network Stream Reader Endpoint and Create Network Stream Writer Endpoint call in the application. Each endpoint name must be unique per host — including names created inside reentrant VIs or inside loops that can run twice.
2. Write the URL explicitly as //<host>:<port>/<name> and keep the name free of spaces and path separators. Verify the string on the block diagram with a probe, not by inspection of the constant.
3. Confirm every created endpoint has a matching Destroy Stream Endpoint on all exit paths, including the error case. An abort from the toolbar bypasses shutdown code entirely — that path alone will leave the orphan that causes the next collision.
4. Wire the error cluster through the whole chain. An unwired error terminal on the create node lets the VI continue with an invalid reference and defers the failure to the first read or write.
5. Set the endpoint buffer size deliberately rather than accepting whatever the default resolves to, and use Flush Stream before destroying a writer so the reader is not left waiting on data that never arrives.

After the audit, launch two instances of the client on the same machine deliberately. If the second instance produces the same socket error on create, name collision is your mechanism and the fix is a per-instance unique name plus guaranteed teardown.

Removing the Blocking Call That Causes the Hang

The frozen taskbar entry is a separate defect from the error code. A socket error alone should return in milliseconds; a hang means a call is blocking with an effectively infinite timeout, and it is blocking in the UI thread.

1. Give every endpoint create call a finite timeout — a few seconds is enough for a LAN — and handle the timeout boolean instead of retrying immediately in a tight loop.
2. Give every Read Single Element from Stream and Write Single Element to Stream a finite timeout. Default-wired timeouts are the most common source of a permanently blocked LabVIEW UI.
3. Move stream creation and stream I/O out of the top-level event structure. An event case that blocks locks the front panel; that is the freeze you are seeing, not a LabVIEW crash.
4. On timeout or on a negative error code, destroy the endpoint, wait a bounded retry interval, and re-create with the same name. Do not leave the reference dangling.
5. Log the error code, timestamp, endpoint URL, and retry count to a text file on every failure so the next event is documented without a debugger attached.

Verify by disconnecting the network cable mid-run. The application must report an error and remain responsive. If the front panel still freezes, a blocking call remains unbounded.

Instrumenting the Machines to Catch the Next Occurrence

With the error now non-fatal, collect the data set that closes the support ticket:

• Packet capture — Wireshark on the client with filter tcp.port == 3363, ring buffer of small files so it can run for days. The capture shows whether the failure is a RST from the peer, a failed SYN, or a local socket error with no wire activity at all. That single fact splits the causes.
• Windows Event Log — System and Application logs around the failure timestamp. Look for adapter resets, DHCP renewals, sleep/resume transitions, and antivirus or endpoint-protection service events.
• Correlation table — record for each event: machine, timestamp, uptime, whether a VPN was connected, whether the session had been idle, and how many LabVIEW instances were running.

Third-party endpoint protection that inspects loopback and LAN sockets is a recurring cause of intermittent socket errors on LabVIEW hosts. Test by excluding LabVIEW.exe and the NI service executables from the scanner on one machine and running it against an unmodified machine for the same period.

End-to-End Verification

1. Deploy the hardened code to one machine that has shown the fault. Leave the packet capture and netstat sampler running.
2. Run a 72-hour soak with the stream active, including at least one deliberate abort of the client and one network cable pull. After each disturbance, the application must recover the stream on its own inside the retry interval.
3. After the soak, compare the first and last netstat samples. Socket counts for the LabVIEW PID must be within a few of each other — a monotonic climb means endpoints are still leaking.
4. Confirm the NI PSP service has not been restarted for the duration: Get-Service "NI Variable Engine" | Select-Object Name,Status plus the service start time in the System event log.
5. Open the error log the application now writes. Zero entries of -1967390704, or entries followed by a logged successful re-create, is the pass condition. If the code still appears and recovery fails, hand the packet capture and the correlated timestamps to NI support with the ticket.

Frequently Asked Questions