LabVIEW camera DLL load error: check the bitness first

You install the camera maker's SDK, open the example VI, and LabVIEW greets you with warnings that assemblies were loaded from a different path. Refresh the camera list and two errors stop you. The camera works in the vendor's own viewer, you followed every step in the manual, and nothing in the VI looks broken. In almost every case like this the VI is fine and the SDK is fine; the process and the DLLs are different widths, 32-bit and 64-bit mixed. This guide gives you the matching rule, two five-minute tests that name the bitness on each side, the installer step that puts files where the resolver looks, and the decision for an SDK that ships one width only.

Why does LabVIEW load the camera SDK DLL from the wrong path?

The warning means the .NET resolver did not find the assembly where your VI expects it, so it fell back to another copy on disk; that spare copy almost always belongs to the other bitness, and the exception on refresh is the bitness clash, not the path itself.

LabVIEW resolves a .NET assembly the way any Windows application does: global assembly cache first, then the folders next to the application. A full SDK install registers its assemblies in the GAC under C:\Windows\Microsoft.NET\assembly. A hand-copied DLL usually sits in a vendor folder under Program Files (x86), the 32-bit install tree by convention. When the registered copy and the loose copy are different builds, the probe order decides, and the VI ends up holding the wrong width.

Open the warning's details and read the two paths it prints: what LabVIEW expected and what it actually loaded. The loaded path alone names the bitness in most cases. Windows installs a 64-bit managed assembly under the GAC_64 folder, a 32-bit one under GAC_32, and a processor-neutral managed assembly under GAC_MSIL; a path under Program Files (x86) is a loose 32-bit copy.

Read both paths before you touch anything. The expected path tells you what the VI's .NET node wants; the loaded path tells you which build actually won. Everything after this is comparing those two values.

What are the likely causes, in order of probability?

Rank the causes: a bitness mismatch between the process and the DLL comes first, an SDK installed without its registration step comes second, a missing native dependency third, and a driver service that is not running last; test in that order and you usually stop at the first.

1. Bitness mismatch. The process is 64-bit and the loaded DLL is x86, or the reverse. Test: read the Platform column for LabVIEW.exe and the machine type of the loaded file, then compare. Fix: install the SDK support that matches.
2. Registration never happened. The SDK folder was copied, not installed, so the GAC has no entry and the resolver grabs a loose build. Test: the loaded path in the warning sits outside C:\Windows\Microsoft.NET\assembly. Fix: run the vendor's full installer. A camera that works in the vendor viewer but not in your own software fits here — when the camera works in the vendor viewer but not in MAX, the fault is in the integration layer, not the camera.
3. Missing native dependency. The managed assembly loads but its native helper does not, and the exception names a different file. Test: read the file name in the exception text. Fix: install the SDK runtime, following the missing-DLL diagnosis sequence.
4. Driver components absent. Loads succeed and enumeration returns nothing, with no exception at all. Test: the vendor viewer also shows zero devices. Fix: the driver install that ships with the camera.

Which bitness has to match, the DLL's or the application's?

The application's process bitness is what counts: a 64-bit LabVIEW process loads only 64-bit native and mixed-mode DLLs, a 32-bit process loads only 32-bit ones, and a pure managed AnyCPU assembly fits either.

Four combinations, two that load, two that throw. There is no partial load and no compatibility shim for native code behind a LabVIEW .NET node; the machine types must be equal.

Camera SDKs rarely stay purely managed. The .NET assembly is usually a thin wrapper over a native acquisition core, and a mixed-mode assembly is bound to one machine type exactly like a native DLL. Treat the table as the rule and AnyCPU as the exception you prove, not the default you assume.

What does BadImageFormatException tell you?

It tells you the file was found and read, but its machine type does not fit the process: the PE header says x86 while the process is x64, or the reverse. It is an architecture verdict, not a corruption or version verdict.

A 32-bit file read by a 64-bit process is intact and unreadable at the same time. FileNotFoundException means the file was never found; BadImageFormatException means it was found and rejected on format. The same mismatch reaches Python users as an ImportError about a DLL that failed to load — the Python fix guide runs the identical bitness check for that case.

How do you check the bitness your LabVIEW application runs as?

Open Task Manager, go to the Details tab, add the Platform column and read it next to LabVIEW.exe: 32-bit or 64-bit. That value, not the installer's folder name, decides which DLLs the process can load.

Run the VI once so LabVIEW.exe appears in the list; the column reads the live process, so an idle LabVIEW tells you nothing. When add-ons arrive as packages, the same discipline applies to them: a package link only resolves against a matching version and bitness — when LabVIEW package links must match version and bitness covers that variant.

How do you check the bitness of the SDK DLLs?

Let Windows tell you: an assembly installed for 64-bit sits under C:\Windows\Microsoft.NET\assembly\GAC_64, a 32-bit one under GAC_32, and a processor-neutral managed one under GAC_MSIL; native DLLs keep the machine type x86 or x64 in their file header.

For a managed assembly, read the install layout: one folder per assembly name inside the GAC parent, a version subfolder inside that, and the GAC_32, GAC_64 or GAC_MSIL parent naming the width it was installed for. For a native DLL, open the file in any PE inspection tool and read the machine field: x86 is 32-bit, x64 is 64-bit. The SDK's download page and release notes usually state the width of each package too, so read that before installing rather than after.

What does the SDK installer fix that a file copy does not?

Three things a file copy cannot do: place each bitness of the managed assembly in the GAC folder for that bitness, install the native runtime and driver components the enumeration calls, and register the components so Windows finds them.

Most support threads on this error trace back to a machine where the DLL folder was copied instead of installed. The copy skips registration, so the first error hides a second one, and every repair that adds more files makes the trail longer. After any fix, close and reopen LabVIEW: a process keeps the assemblies it has already loaded, so a clean start is part of the fix, not a formality.

What does a worked diagnosis look like?

Call the SDK's managed assembly CameraSdk.dll here — a stand-in name, not a real product — and walk a case end to end: two load warnings at open, two exceptions at refresh, one decision.

Task Manager, Details tab: LabVIEW.exe reads 64-bit in the Platform column. Show Details on the warning: LabVIEW expected the assembly in the GAC and loaded C:\Program Files (x86)\CameraSdk\CameraSdk.dll instead. The loaded path sits outside C:\Windows\Microsoft.NET\assembly, and GAC_64 holds no entry for the assembly, so the only copy on disk is the 32-bit build. By the table above, a 64-bit process loading an x86 machine type fails with BadImageFormatException at the first call. You refresh the camera list; the exception appears, exactly as the rule predicts. Fix: run the SDK installer and select the 64-bit support option, which writes the assembly under C:\Windows\Microsoft.NET\assembly\GAC_64, in the folder named for the assembly with its version subfolder inside. Reopen LabVIEW and refresh: one camera in the list, zero exceptions.

With the assembly loading cleanly, the next step is the call pattern — callbacks, buffers and the snap model — covered in calling a camera SDK DLL from LabVIEW.

What if the camera SDK ships 32-bit support only?

Then run the camera station on 32-bit LabVIEW: a 32-bit process loads 32-bit DLLs natively, and 2 GB of user address space by default — up to 4 GB with a large-address-aware executable — holds camera buffers easily, since an 8-bit mono 12 MP frame is about 12 MB of pixels.

Keep 64-bit LabVIEW for projects that have no SDK attached, and give the camera station its own 32-bit install with its own matched SDK support. If the project must run 64-bit — large stitched images, many simultaneous cameras — the options are a vendor 64-bit runtime if one exists, or hardware whose SDK ships 64-bit from the start. Check that before you choose the camera, not after: the area scan cameras and board-level cameras pages group what is sold here, the camera finder filters by interface and resolution, and you can confirm an SDK's bitness with us before ordering through the contact page.

If the vendor exposes a plain C API instead of .NET assemblies, a wrapper DLL compiled for the width you need is the clean route; building one for LabVIEW is its own project with its own pitfalls.

How do you keep the error from coming back?

Record the pair as one setting: LabVIEW 64-bit with 64-bit SDK support installed, or 32-bit with 32-bit, and re-check it after every LabVIEW update, every move to a new PC, and every build, because each of those can change the width the VI meets.

• Install with the vendor's full installer on every PC that runs the VI, development and runtime machines alike. A deployment without the SDK installed is possible for some SDKs; copying DLL folders never is.
• Treat a built EXE as its own process. Run the same Platform-column and GAC checks on the runtime machine before you ship it.
• A real-time target is a third case: the DLL deploys to the target itself, not the host PC, and fixing a failed-to-load DLL on a LabVIEW Real-Time target walks that variant.
• Write the pair into the project notes — LabVIEW width, SDK width, installer date. The next engineer should not have to rediscover it at commissioning.

The decision in one line: read the Platform column, read the loaded path, make the two widths equal, and do it with the installer. When an SDK's bitness ends up deciding which camera you can drive, pick hardware whose software matches both your development and deployment machines; the camera configurator builds that chain from sensor to cable, and more integration fixes sit on the systems topic page.