Install 32-bit and 64-bit vision libraries side by side on one PC

One Windows PC can run your 64-bit imaging application and your operator panel's 32-bit PLC toolkit at the same time: Windows loads DLLs per process, not per machine, so the fix is two installs in two directory trees, not one. A 32-bit process is capped near 2 GB of address space, so it never carries image data anyway — which is exactly why you keep the vision library 64-bit and let the 32-bit side talk only to the controller.

This how-to shows you how to map every program's bitness first, install the second runtime without stepping on the first, point each application at its own DLL folder, and prove the pair works before the line starts. It ends with the four clashes that do break mixed setups, and the buffer arithmetic that tells you why the imaging side should stay 64-bit.

The decision: install both, load per process

Windows fixes a process's bitness at start-up. A 64-bit process cannot load a 32-bit DLL, and a 32-bit process cannot load a 64-bit one — the loader rejects the mismatch outright. That rule binds each process, not the machine, which is why two complete installations coexist on one PC as long as they live in different directories.

So the decision is: keep the 64-bit vision library exactly as it is, and add the 32-bit runtime beside it. The 64-bit side keeps serving every application that touches images. The 32-bit side exists only to satisfy components that ship no 64-bit build, such as a PLC communication toolkit. Nothing is re-licensed, re-registered or rebuilt — the two trees share the disk, never the process.

How Windows keeps the two runtimes apart

On a 64-bit Windows installation, the WOW64 subsystem runs 32-bit programs, and the system directory itself is split in two: the 64-bit system DLLs sit in System32, the 32-bit ones in SysWOW64. The names look swapped — that is historical — and a 32-bit process that asks for System32 is silently redirected to the 32-bit copies. Your programs never manage this; the loader does.

Vendor runtimes follow the same shape. One versioned installation root usually holds one binary folder per bitness, with names in the x64 and win32 style. After a mixed install you should see two separate DLL trees under that root — not one shared folder. What the two installs genuinely share is machine-level state: PATH entries, installation-root environment variables, Windows services, COM registrations and license files. The second installer may edit that shared state, and that — never the DLL folders — is where mixed setups go wrong.

The pattern is not special to vision software. It is the same isolation that lets a controls engineer run several SCADA gateways on one PC: independent installs, each with its own directory and its own service entries, that never discover each other by accident.

What you need before you install

• The bitness of every EXE that must keep working: your imaging application, the 32-bit PLC tool, and any camera-side service. Check before installing, not after.
• The installer for the missing bitness, from the vendor's official distribution. Read the compatibility table while you are there: some vendors' older 32-bit runtimes cannot open cameras on a 64-bit OS at all, and no folder layout fixes that.
• Administrator rights: installers write to the installation root, machine environment variables and the service list.
• Disk space for a second full runtime install. Put runtimes on the SSD; keep installer archives on bulk storage.
• A record of the current PATH and environment variables, so you can diff them after the second install.

If the PC itself is on your order list, the vision controllers category filters by RAM, LAN port count and PoE, and your area scan camera choice sets the interface the 64-bit side must serve.

Either of these entry controllers hosts both runtimes for a single-camera station:

The MV-VC3301H-128G66 pairs an Intel Core i3 with 8 GB of RAM and a 128 GB SSD, and includes a vision software license.

The MV-VC2140-128G40-1T also carries 8 GB and a 128 GB SSD, and adds a 1 TB HDD that swallows installer archives and image dumps.

Install the second runtime step by step

1. Map the bitness of every program that must keep working. Task Manager's Details view flags 32-bit processes on a 64-bit OS; an unmarked process is 64-bit. For your own code, check the build: a .NET project left at the default any-CPU setting with 32-bit preference runs as a 32-bit process no matter what the OS offers.
2. Record the first install's footprint before you touch anything: its installation root, the PATH entries it added, and any environment variable pointing at it.
3. Run the second installer as administrator and give it its own installation root. Most vision installers default to per-bitness folders under one versioned root — keep that default. If the installer offers a single target folder, change it yourself; a merged install defeats the whole plan.
4. Read the service dialogs. When the installer offers to install or update a license or camera service, let it update rather than duplicating: both runtimes should call one service, not fight over two.
5. Re-open PATH and the environment variables after the install finishes. A new entry pointing at the 32-bit binary folder is expected; order the entries so the folder matching your main imaging application comes first.
6. Never copy a vendor DLL into System32 or SysWOW64 by hand. System folders belong to the OS and the installers; a hand-copied DLL there shadows correctly matched copies and survives every uninstall.

Point each application at its own runtime

1. Native code: link against the import library in the binary folder that matches your platform setting, and ship the matching runtime DLLs next to your EXE. The application directory is searched before everything else, which locks the match in.
2. .NET code: the managed wrapper is often bitness-neutral, but the native DLL it calls is not. Set the platform target to match, and keep separate output folders per platform so each build carries its own native copies.
3. The 32-bit PLC tool needs nothing from the vision library. It loads its own components, and WOW64 redirection serves it the 32-bit system DLLs automatically.
4. COM components: one registered to run inside your process must match your bitness; one that runs as its own process can serve both widths. In mixed setups, prefer the out-of-process variant whenever the vendor offers one.
5. When one program must reach another, cross the process boundary deliberately — TCP, shared memory, a message queue. For cameras, a second application can read the parameter tree over TCP while the first owns the device, exactly as in accessing a camera parameter tree over TCP from a second app.
6. Long-running 64-bit services that call vendor libraries through wrappers still owe the usual hygiene: release every buffer the library hands back. The C# memory-leak checklist for vision library calls covers the pattern.

The four clashes that break mixed installs

Four shared-state items cause nearly every failure you will see in a mixed setup.

The runtime symptom behind most rows is a load error, not a crash mid-algorithm. When one shows up, the stale-DLL hunt for a missing entry point is the same procedure, and it ends at the same culprit: a file of the wrong width or vintage found first.

Why the imaging side stays 64-bit: the buffer arithmetic

Keeping the 64-bit runtime is not sentiment; it is address space. A 32-bit process on Windows gets 2 GB of user address space by default, or 4 GB with the large-address-aware flag on a 64-bit OS. A 64-bit process is bounded by physical memory instead. The difference decides how many frames you may queue.

Worked example. The 12 MP USB3 camera delivers 4000 × 3000 pixels. Take the 8-bit case: one byte per pixel, so one frame is 4000 × 3000 × 1 B = 12,000,000 B ≈ 12 MB. Give the pipeline five buffers per frame — live, working copy, result, display copy, archive — and each frame in flight costs 5 × 12 = 60 MB. A ten-frame queue costs 600 MB.

In the 32-bit process: 2,048 MB of address space minus roughly 500 MB for runtimes, system copies and the application leaves 1,548 MB, so 1,548 ÷ 60 ≈ 25 frames before an allocation fails. With the 4 GB flag: 4,096 − 500 = 3,596 MB, about 59 frames. The same pipeline as a 64-bit process on an 8 GB machine is bounded by RAM: 8,192 − 2,000 for Windows and services − 600 for application and libraries ≈ 5,592 MB, about 93 frames — and allocations never fail for address reasons.

When that queue is your daily load, this is the host that carries it with room to grow:

The MV-VC5525-256G70-NN pairs a 12th-generation Intel Core i5 with 32 GB of RAM and a 256 GB SSD, and adds eight built-in light channels and PoE camera ports for the rest of the station.

Verify the setup before you call it done

Verification is two applications, one boot, no reboots between:

• Both installation trees exist under the versioned root, each with its own binary folder.
• The 64-bit imaging application starts, opens the camera and grabs one image.
• The 32-bit PLC tool starts, connects to the controller and exchanges one table of registers.
• Task Manager's Details view confirms the widths: imaging 64-bit, PLC tool 32-bit.
• The imaging process's memory climbs only as queues fill; a 32-bit process pushing past about 1.8 GB is approaching its ceiling and will fail allocations near 2 GB.

Run both sides for a full shift before you sign the station off. The clash that surfaces in mixed setups is rarely the first image; it is the first batch, when both processes touch the shared service at once.

When side-by-side is the wrong answer

Some products refuse the arrangement by design. Suites that keep one shared installation — some office software works this way — require you to uninstall one bitness before installing the other. If a vision vendor's installer offers a single target folder and no per-bitness subfolders, expect the same behavior and plan a second machine or a virtual machine instead of fighting it.

If the blocker is one legacy 32-bit component inside your own application, do not install a whole second runtime for it. Put that component in a small 32-bit helper process and let the 64-bit main process talk to it over IPC; the heavy side keeps its address space.

And when two applications must share one camera rather than share a PC, the pattern is device ownership plus a protocol, as in one camera per process.

If the clean answer is one controller per bitness, the shelf below splits by RAM, LAN count and PoE:

Pre-flight checklist

Run this list top to bottom and the mixed install holds.

Before installing

• Bitness map of every EXE that must keep working.
• Vendor compatibility table checked for 32-bit support on a 64-bit OS.
• PATH and environment variables recorded.
• Disk space confirmed on the SSD.

During

• Second install goes to its own root, never the first's folder.
• Service dialogs read: one license service, one camera service.
• No hand-copied DLLs into System32 or SysWOW64.

After

• PATH reordered so the imaging application's runtime leads.
• Both applications smoke-tested in one boot, widths confirmed.
• Memory watched for one shift; the 32-bit side stays under its 2 GB ceiling.

More PC-side guides live on the systems topic page. If you are speccing the machine that carries both stacks, the contact page reaches the applications team with your camera count and frame sizes.