Vision application startup error: diagnose missing DLLs

A native vision program can compile successfully yet stop before displaying a window or loading an image. That usually sends debugging toward the wrong place: image paths, decoding functions, or camera settings. This troubleshooting procedure helps you separate a Windows loader failure from an application bug, identify the missing dependency, and deploy a compatible runtime package. Start with the executable and its dependencies, not with replacement hardware or changes to image-processing code.

Confirm whether application code actually starts

Windows status 0xC0000135 means STATUS_DLL_NOT_FOUND. A launcher may display the same value as the signed decimal exit code -1073741515. These are different representations of the same status, not separate faults.

For an executable with an unresolved startup dependency, the loader can stop the process before main() runs. Changing an image filename cannot fix that failure because the image-loading statement has not executed.

However, a missing library can also surface later through a plugin or explicit loading operation. The exit code alone does not establish exactly when the failure happened.

Use a debugger to set a breakpoint at the application's entry function. Also capture the launcher's complete diagnostic message. If the breakpoint is never reached, inspect startup dependencies first. If it is reached, identify which initialization or library-loading operation precedes the failure.

A missing log message is weaker evidence. Output can remain buffered, and logging itself may depend on a component that failed to initialize.

If the executable never finishes linking, use the separate procedure for C++ camera SDK linking errors. That is an earlier build stage than the startup failure addressed here.

Check the most likely causes in order

Start with deployment differences before changing the compiler or rebuilding every dependency. The development machine often supplies libraries through an installed toolchain or an IDE-specific environment.

Investigate these causes in order:

1. A directly imported DLL was not deployed. Inspect the executable's import list, then check whether each required runtime component is installed or packaged through its documented deployment method.
2. A dependency of that DLL is missing. The named library may exist while one of its own imports cannot be resolved.
3. The launcher supplies a different environment. Compare an IDE launch with a launch from the intended installation directory.
4. An incompatible library is found first. Check the actual loaded path, architecture, and package version rather than trusting the filename.
5. A plugin or optional backend needs additional components. Investigate this branch when the failure occurs only after a particular feature is enabled.

Record the executable path, working directory, build configuration, target architecture, and launch method before testing. Otherwise, a successful launch may simply mean that you accidentally ran a different executable.

Separate compile, link, and runtime requirements

Three different mechanisms are involved in building and starting a native application. Configuring one does not automatically configure the others.

An import library tells the linker how an executable refers to a DLL. It does not necessarily contain that DLL's implementation. Adding another include directory or repeating an import-library entry therefore does not deploy the runtime component.

Library filename extensions also need interpretation. An archive can contain static code or import information, depending on the toolchain and package. Check the package documentation rather than assuming an archive eliminates runtime dependencies.

Create a small deployment manifest with separate columns for build inputs and runtime requirements. For each runtime component, record its approved source, architecture, configuration, and installation method.

If the application uses a language wrapper as well as native libraries, camera SDK bitness troubleshooting explains that additional boundary. Keep the native executable test independent until its startup succeeds.

Inspect transitive dependencies, not just the executable

Use an import-inspection tool supplied or recommended by your compiler or software package. Start with the executable, list its direct dependencies, and then inspect each non-system library recursively.

Consider this illustrative dependency chain:

vision_app.exe
  -> processing.dll
       -> compiler_runtime.dll
  -> display.dll
       -> platform_backend.dll

Finding processing.dll does not establish that the application can load it. The loader must also resolve that library's dependencies. The first missing component may be several levels below the executable.

For every unresolved entry, ask:

• Is it a real redistributable file, an operating-system component, or a logical dependency name?
• Does its architecture match the process that will load it?
• Is it supplied by the same compatible package as the importing library?
• Does the documented deployment procedure require an installer rather than a file copy?

Older dependency inspectors can misinterpret modern operating-system dependency mechanisms. Some logical system names are resolved through operating-system mappings rather than ordinary files beside the executable. Confirm suspicious findings with a current debugger or loader diagnostic before declaring them missing.

Static inspection also has limits. Libraries loaded by filename at runtime, including optional plugins, may not appear in the executable's ordinary import list.

When the import tree looks complete, capture a launch trace with an operating-system diagnostic tool. Look for attempted library paths and the paths of successfully loaded modules. An unsuccessful file probe alone is not proof of failure: loaders commonly try several locations before finding a file.

The useful evidence is a required component that never resolves, or a component that resolves to an unintended location.

Verify architecture, configuration, and compiler compatibility

Match dependencies to the application process, not merely to the operating system. A 32-bit application needs compatible 32-bit native dependencies even when it runs on a 64-bit operating system.

Architecture mismatches can produce a different loader status, so preserve the exact error rather than treating every startup failure as a missing file.

Check these compatibility dimensions separately:

Matching filenames are not sufficient evidence of compatibility. Different builds can use the same names while requiring different exports or runtime components.

C++ interfaces deserve particular care when objects, exceptions, or memory ownership cross library boundaries. Follow the package's documented compiler and ABI requirements. Do not assume every library must use an identical compiler, but do not assume arbitrary combinations are interchangeable either.

For a worked deployment example, suppose an application imports 3 package DLLs. Inspection finds 2 additional non-system dependencies below them. The candidate dependency set is 3 + 2 = 5 unique components, before checking their own imports. Deduplicate shared dependencies, then classify each component by its documented deployment method. Five files in a folder would not, by itself, prove that installation is complete.

Reproduce the launch outside the development environment

Test the intended deployment, not an environment that silently provides missing components.

1. Create a clean release build. Use a fresh output directory so stale debug files cannot conceal packaging errors.
2. Assemble the documented runtime package. Use the software package's deployment utility or approved installer where provided.
3. Launch from the intended installation directory. Record the executable path and working directory.
4. Repeat without IDE-specific environment changes. Keep a record of any process-level search-path configuration.
5. Inspect loaded module paths. Confirm that application libraries come from the expected installation or approved runtime locations.
6. Repeat on a representative test machine. Install declared prerequisites, but do not install a development toolchain merely to make the application start.

Windows library search behavior depends on the application, loading flags, and operating-system configuration. Do not assume the working directory is always searched, or that it has the same priority in every process.

Prefer the manufacturer's documented application-local deployment or runtime installer. If documentation requires a search-path entry, scope it as narrowly as practical and record why it exists.

If startup succeeds but a transport producer remains unavailable, continue with GenTL producer loading and DLL paths. A running application and an available acquisition producer are separate acceptance checks.

Restore image processing and camera acquisition in stages

Once the application reaches its entry function reliably, add functionality back in a controlled sequence: basic initialization, offline image loading, processing, display, and finally camera acquisition.

Use a known-readable image at a verified absolute path for the first offline test. Check the image-loading return value before accessing pixels. If encoded file contents are being confused with an image array, use the explanation of image bytes versus pixel data.

A camera is not needed to prove that the native executable can start. For deployment onto vision controllers, repeat the same software acceptance checks on the actual target rather than relying on the development workstation.

If you are also selecting area scan cameras for a new station, choose the acquisition interface independently of the loader diagnosis. The camera finder helps narrow hardware choices, but changing a camera does not install a missing application runtime.

The LS-CMR-0053 is a GigE camera.

The LS-CMR-0166 is a USB3 camera.

These are acquisition options, not remedies for a missing DLL. For either interface, verify the chosen camera software package's host requirements and deployment instructions before integration.

If discovery succeeds but opening the camera fails, move to camera open failures after discovery rather than reopening a resolved executable-startup investigation.

Verify the fix and prevent recurrence

A fix is demonstrated when the intended executable starts under the intended deployment conditions without borrowing undeclared components from the development environment.

Before accepting the installation, check:

• Entry function reached: the debugger confirms execution proceeds beyond native startup.
• Loaded paths recorded: application DLLs resolve to approved locations, not leftover build directories.
• Offline test passed: a known image loads, processes, and closes without invalid memory access.
• Feature-specific loads tested: optional display, codec, and acquisition components are exercised where used.
• Deployment repeated: a clean installation works using only the declared prerequisites and application package.
• Manifest retained: architecture, configuration, package versions, installers, and test outcomes are documented.

Avoid changing several variables together. Copying libraries, rebuilding the executable, editing search paths, and changing image code in one attempt may hide the cause even if the application starts.

The usual missing-DLL answer is wrong when the loader completes and the application then rejects an image, accesses invalid memory, or fails to discover a camera. Keep those failures in their own diagnostic branches.

For a new station, continue with the camera configuration workflow after the software baseline passes. For help selecting compatible acquisition hardware, use application support and include the exact status, target architecture, dependency findings, and launch conditions.