An Ignition gateway that loses its OPC-DA connection and crashes every one or two days, with a restart as the only recovery, usually has a split-architecture stack. In the case behind this note, the Ignition 64-bit build ran on a 32-bit Java runtime with 32-bit OPC Core Components on 64-bit Windows, polling a local 32-bit OPC DA 2 server. The gateway worked some of the time and crashed the rest. Replacing Java and the Core Components with 64-bit versions stopped the crashes. The OPC server stayed 32-bit.
The rule: the Ignition build, the JVM, and the OPC Core Components on the Ignition machine must all share one bitness. The OPC-DA server's bitness only matters on the machine that hosts the server.
Which hops does an OPC-DA request cross between Ignition and the server?
Follow the packet. OPC-DA is not a network protocol in its own right. It is a set of COM interfaces. When a request crosses a process boundary, COM marshals it through proxy/stub components. When it crosses a machine boundary, DCOM carries it over RPC.
| Hop | Where it runs | Bitness constraint |
|---|---|---|
| Ignition OPC-DA client driver | Inside the gateway JVM process | Matches the Ignition build and JVM |
| OPC Core Components (proxy/stub marshaling, server enumeration) | Loaded in-process by the client | Must match the client process. A 64-bit process cannot load 32-bit DLLs, and a 32-bit process cannot load 64-bit DLLs. |
| Local RPC between processes | Windows COM runtime | None. Marshaled calls cross the 32/64 boundary cleanly. |
| DCOM over the network (remote server only) | RPC endpoint mapper on TCP 135 plus dynamic ports | None on the wire |
| Server-side stub and Core Components | Server machine | Match the OPC server's architecture |
| OPC-DA server executable | Its own process | 32-bit or 64-bit, independent of the client |
This table explains why a 32-bit OPC DA server works fine under a 64-bit gateway. The server runs out of process, so the only component that has to match the gateway is the in-process marshaling layer. On 64-bit Windows, 32-bit COM registrations live in a separate registry view (WOW6432Node). A 64-bit client therefore resolves the 64-bit registrations and ignores the 32-bit ones. If only the 32-bit Core Components are installed, a 64-bit client cannot find the marshaling components it needs.
Check 1: What bitness is the gateway process actually running?
Layer one first: identify the process before you touch COM settings. The Ignition installer's bitness does not guarantee the JVM's bitness. The gateway runs whatever Java executable its configuration in data\conf points to.
- Open Task Manager, go to the Details tab, and add the Platform column. Find the gateway's Java process.
- Run
java -versionagainst the exact executable path the gateway configuration references. A 64-bit runtime reports a 64-Bit Server VM. - Confirm the Ignition build architecture from its installer or install path.
| Ignition build | JVM | Meaning | Next |
|---|---|---|---|
| 64-bit | 64-bit | Process layer aligned | Check 2 |
| 64-bit | 32-bit | Split stack. This is the configuration that crashed every 1-2 days. | Go to the fix procedure |
| 32-bit | 32-bit | Consistent but constrained. The heap is capped by 32-bit address space. | Check 2 (local Core Components must be 32-bit) |
A 32-bit JVM limits the usable heap to well below 4 GB. A gateway running many tags and subscriptions can exhaust that heap and fail on a periodic cycle, which looks exactly like the one-to-two-day pattern. Check the gateway wrapper log and look for a JVM fatal error log in the install directory. Either one tells you whether the process died from a native crash or from memory exhaustion.
Check 2: Do the local OPC Core Components match the gateway process?
Open Programs and Features and read the installed OPC Core Components redistributable entry. It names the architecture.
- Components match the JVM: the marshaling layer is correct. Go to Check 3.
- 32-bit components with a 64-bit gateway: the client cannot load them. Connections fail outright, or they partially work and are unstable. Reinstall with the version that matches Ignition/Java.
- 64-bit components with a 64-bit gateway and a local 32-bit server: correct. Match the Ignition side, even when the local OPC-DA server is 32-bit. The final working configuration used exactly this layout.
Check 3: Is the OPC-DA server local or remote, and what is its bitness?
This check decides where each copy of Core Components goes. When the servers are remote, a mixed 32/64-bit fleet needs no special handling on the Ignition side.
| Topology | Ignition machine | Server machine |
|---|---|---|
| Local 32-bit server, 64-bit Ignition | 64-bit Core Components | (same machine) No extra install needed. The local 32-bit server kept running after the 32-bit package was replaced with the 64-bit one. |
| Remote 32-bit server | Core Components matching Ignition | 32-bit Core Components |
| Remote 64-bit server | Core Components matching Ignition | 64-bit Core Components |
| Two remote servers, one 32-bit and one 64-bit | One install only, matching Ignition. Do not install both. | Each machine gets the version matching its own OPC server |
A local/remote architecture mismatch is expected and harmless. DCOM serializes calls into RPC, and the wire format carries no bitness. Each end only needs marshaling components its own process can load.
For remote servers, the packet then has to clear the network. The endpoint mapper needs TCP 135, and the dynamic RPC range must also be open. Both machines need DCOM launch/access permissions for the account the gateway service runs under. The server machine needs the enumeration service from Core Components running, or browsing the server list returns nothing.
Which symptoms point to bitness rather than DCOM or the server?
| Symptom | Likely layer | Reading that decides it |
|---|---|---|
| Gateway crashes on a cycle of a day or two and needs a restart | Split JVM/Core Components bitness, or 32-bit heap exhaustion | Task Manager Platform column; wrapper log; JVM fatal error log |
| Connection works intermittently on a local server | Mismatched local Core Components | Installed redistributable architecture vs. JVM |
| Local server works, remote server fails with access denied | DCOM security | DCOM permissions on both ends; service account |
| Remote server list is empty when browsing | Enumeration service or firewall on the server machine | Service state; TCP 135 reachability |
| Server connects but items go bad quality | OPC server or item configuration | Server's own diagnostics |
How do I realign the stack to 64-bit and prove it is stable?
- Stop the Ignition gateway service.
- Install a 64-bit Java runtime from Oracle.
- Edit the gateway configuration file in
data\confso the Java executable path points to the 64-bit runtime. Leave the old path commented out in case you need to roll back. - Uninstall the 32-bit OPC Core Components.
- Install the 64-bit OPC Core Components from the OPC Foundation.
- Leave the 32-bit OPC DA server untouched.
- For remote servers, install Core Components on each server machine to match that server's architecture, and leave the Ignition side at 64-bit.
- Start the gateway. In Task Manager, confirm the Java process now shows 64-bit.
- Open the OPC-DA connection status in the gateway and confirm it reports connected. Browse the server and subscribe a sample of tags. Confirm they return good quality and live values.
- Run the gateway through at least several multiples of the old crash interval, meaning several days. Then confirm the wrapper log shows no restarts or fatal errors and the JVM memory trend stays flat.
FAQ
Can I use 64-bit Ignition with a 32-bit OPC DA server?
Yes. The server runs in its own process, so COM marshals calls across the 32/64 boundary. Install the 64-bit OPC Core Components on the Ignition machine to match the 64-bit gateway and Java.
Does Ignition need both 32-bit and 64-bit OPC Core Components for mixed remote servers?
No. Install one version on the Ignition machine, the one matching Ignition/Java. On each remote server machine, install the version matching that server's architecture.
Does the Core Components bitness have to match between the Ignition and remote server machines?
No. DCOM carries calls over RPC with no bitness on the wire, so a 64-bit Ignition side talking to a 32-bit server side is a normal configuration. Only each machine's local match matters.
Can a 32-bit Java runtime cause Ignition gateway crashes every day or two?
Yes. A 32-bit JVM under a 64-bit Ignition build splits the stack and caps heap well below 4 GB. Install 64-bit Java, point the gateway configuration in data\conf to it, and confirm the Java process shows 64-bit in Task Manager.