CTI file loads but no devices appear: fix missing DLL dependencies

You point a GenTL consumer at a producer CTI, it accepts the file, and the device list stays empty. The console offers nothing useful — at most a stylesheet complaint such as QCssParser::parseColorValue objecting to a color given without an alpha value, which is GUI noise with no connection to the camera stack. In most of these cases the producer never loaded at all: one of the DLLs it imports is off the loader's search path, the load call failed, and the consumer caught the failure and moved on with zero producers. This guide shows how to prove that in minutes, fix it without touching System32, and what to check once the producer loads cleanly.

The symptom, exactly

The CTI sits where you pointed the consumer — the Harvester GUI, a vendor viewer, or your own GenTL code. The file exists, enumeration returns an empty list, and no exception reaches the face of the application. Dig through the log and you may find what was swallowed: Harvester records a GenTL exception for the failed load with ID: -10001, carrying the Windows text "The specified module could not be found".

That OS text is the tell. Error 126, ERROR_MOD_NOT_FOUND, is what Windows returns when a module cannot be resolved during a load call — and "a module" covers the CTI itself or any DLL it imports. Your CTI file plainly exists, so the missing module is a dependency.

The same empty list also appears when the CTI loads but is the wrong producer for the hardware in front of you, so settle that first: GenTL producer shows an empty camera list: match the CTI covers the pairing, and GenTL CTI file added but no error: validate before you enumerate covers the file-level checks. What follows is the third case: a silent load failure hiding behind a healthy-looking file.

Why the loader stays silent

A .cti file is an ordinary Windows DLL with a different extension — on Linux, an ELF shared object. Loading it forces the OS to resolve every import, and the default search order never mentions the folder the CTI came from: dependencies are sought in the loading program's own folder, then the Windows system folders, then, last, the folders listed in PATH. Unless the consumer goes out of its way to alter that order, a DLL sitting beside the CTI is invisible to the loader. That one detail explains most empty device lists.

Consumers differ in how loudly they report the failure. Some surface the exception when you force the load; others try the next producer and leave you staring at nothing. The fix is identical either way. Two neighbouring failures are worth telling apart: GenTL producer not listed: check Windows DLL paths covers where a consumer looks for producers at all, and vision application startup error: diagnose missing DLLs covers the case where the whole application refuses to start. Windows has applied this dependency discipline across every version; the same rules bite when moving legacy applications between machines.

Step 1: confirm the CTI is the right producer

1. Match the transport. A GigE producer enumerates GigE cameras, a USB3 producer enumerates USB3 cameras, and a grabber-side producer enumerates whatever its card driver exposes. Nothing enumerates a camera on a transport it was not built for.
2. Know what the simulator is. The genicam Python package ships TLSimu.cti, which creates virtual devices and imports VirtualFG.dll. A reported packaging regression around genicam 1.5.1 left that DLL out of the wheel, so even the virtual device vanishes after an upgrade. Reinstall genicam 1.5.0 or restore VirtualFG.dll from that version's wheel.
3. Install the runtime whole. The CTI, its DLLs and the transport driver arrive as one package; a CTI copied out of that package on its own is exactly the orphan that cannot load.

Step 2: prove which module is missing

The fastest probe needs nothing beyond Python, which you already have when a GUI like Harvester is doing the enumerating. From any console:

import ctypes
producer_path = r"C:\camera\gtl\producer.cti"  # illustrative path, type str
ctypes.WinDLL(producer_path)

ctypes.WinDLL is the standard-library binding for the OS load call, so this exercises exactly what the consumer does. Read the result like this:

Now name the dependency. From a Visual Studio developer prompt, dumpbin /dependents producer.cti prints the DLLs the producer imports; skip the Windows system names and note the vendor-named one. On Linux a single line does it: ldd producer.cti marks every unresolved library "not found". No Visual Studio on the machine? The probe plus the producer's install folder is enough — every DLL in that folder is a candidate. The same failure pattern reaches beyond vision into any engineering tool that hosts native plug-ins, as this PLC IDE DLL dependency troubleshooting guide records.

The worked sequence as it typically runs: 64-bit Python 3.6, consumer pointed at ...\site-packages\genicam\TLSimu.cti, enumeration returns 0 devices. The probe raises OSError with WinError 126. The package folder holds the CTI but no VirtualFG.dll, while a machine still on genicam 1.5.0 shows both files side by side. Restoring that one DLL and reopening the viewer returns 1 virtual device. Elapsed time: minutes.

Step 3: fix the search path the clean way

Windows, in order:

1. Open the Environment Variables dialog (System Properties, Advanced) and edit Path — system-wide under System variables, or per user under User variables. If the editor refuses the change, that elevation problem is the one covered in the admin-rights fix for a Windows vision tool error.
2. Add one entry: the full path of the folder holding the producer's CTI and its DLLs — the folder the missing import came from.
3. Close every viewer and every console, then open a fresh one. A process reads its environment once, at start, so a running Harvester never sees the edit.
4. Re-run the ctypes probe in that new console before touching the GUI. A silent return proves the loader resolves every import now.

For a single-session test, set the path in PowerShell and launch the viewer from that same shell:

$env:Path = "C:\camera\gtl;" + $env:Path

Set GENICAM_GENTL64_PATH as well. Point it at the folder that holds your .cti files and consumers that scan it enumerate every producer found there; each directory you list must contain a .cti that exports the standard GenTL C entry points, so a folder of plain DLLs is skipped. Producers add their own variables on top of this one, but GENICAM_GENTL64_PATH is the name most consumers honor.

On Linux:

export LD_LIBRARY_PATH=/opt/vendor/lib:$LD_LIBRARY_PATH

Run that in the shell which launches the viewer, or make it permanent with a file under /etc/ld.so.conf.d/ followed by ldconfig. Inside a Python venv the interpreter's own libraries join the chain and order matters — see install order for a GenTL producer in a Python venv on Linux. If the consumer runs in a container, the libraries and the device nodes must both be visible; diagnosing missing devices in GenTL container discovery covers that layer. The error messages themselves are covered in diagnosing Linux vision shared library errors.

Step 4: restart, then check the hardware

With the path fixed and a new process started, the producer should enumerate. If it enumerates in the vendor's own tool but not in your consumer, the producer is healthy and the problem sits on the consumer side — a first-read I/O failure looks like a dead camera but is not; see the initial camera I/O error on the first GenTL read.

Move to the physical layer only after the producer loads cleanly and still finds nothing: install the full driver package for the interface card before judging its producer, put a GigE camera on the NIC's subnet, respect the 100 m category-cable limit, and keep USB3 runs short. On the interface side, a quad-port copper 10GigE NIC suits a multi-camera line, a dual-port PoE NIC carries power on the data run, and an XoF frame grabber with an SFP+ slot takes the link off copper.

Cable length and connector choices land in camera data cables, and these two round out the interface end of a station:

When the empty list is not a missing DLL

• Bitness. WinError 193 from the probe means the producer build does not match the process; a 64-bit Python needs the 64-bit producer, and no PATH entry cures a mismatch.
• Version skew. A producer expecting a newer transport library than the one installed can enumerate nothing while logging almost nothing; that pattern and its missing-function errors are covered in GenTL producer version compatibility.
• Quarantine. Security software that silently removes a DLL produces this exact picture. Check the quarantine log before reinstalling anything.
• Simulator expectations. TLSimu.cti makes virtual devices only; it will never list a physical camera, no matter how clean the load.

The five-minute checklist

• The CTI matches your transport — or is deliberately the simulator.
• The ctypes probe loads the CTI silently in a fresh console.
• The producer's folder is on PATH on Windows, on LD_LIBRARY_PATH on Linux.
• GENICAM_GENTL64_PATH names the folder holding your .cti files.
• Every viewer and console was restarted after the environment change.
• The vendor's own enumeration tool sees the device before you blame the consumer.

If the station is still on paper, the configurator walks camera, lens, light, controller and accessories in order and finishes at the interface parts this failure lives on:

If the producer still refuses to enumerate after this pass, send the log lines and the producer name through the contact page and we will work it with you.