The dialog reads like a verdict on your vision software: ...is either not designed to run on Windows or it contains an error..., naming a path such as C:\Windows\System32\itss.dll the moment you select the camera. Before you reinstall the capture stack a third time, read what the message actually names: a Windows system file. This error class means the operating system's own file is damaged or was replaced, and the vision application is simply the first program in your workflow to load it. This guide shows how to read the path, decide in one minute who owns the file, repair it in the documented order — DISM, then System File Checker — and prove the result with the file version and digital signature before anything is reinstalled.
Read the error before you touch anything
The message carries three facts: a full path with the file name, a verdict from the Windows loader, and on many builds the dialog title Bad Image. The loader refuses a module when its internal structure is damaged or when it is built for the wrong architecture, a 32-bit copy dropped into a 64-bit path for example. None of that implicates your application's logic.
The path is the diagnosis. C:\Windows\System32\itss.dll names a Windows-owned component — itss.dll is part of the Windows help system — so the operating system owns the repair. The vision software's installer cannot rewrite that file, which is exactly why a repair-and-reinstall loop changes nothing: the software you keep reinstalling is not the software that is broken.
The path decides who owns the problem
- C:\Windows... (System32, SysWOW64, WinSxS): Windows owns the file. Use the OS repair path in this guide.
- Program Files... or an SDK runtime folder: the vision product owns the file. Reinstall that product from its original installer. A stale application copy shadowing a current library is the vision software missing entry point case, not this one.
- File not found at all: a different failure, closer to missing DLLs at application startup.
One minute of path reading decides which layer gets your afternoon.
Likely causes, most probable first
Work down the list and stop at the first test that matches.
- Damaged bytes after an interrupted update or power cut. An update that fails mid-write, or a PC that loses power during one, leaves a protected file half-written. Test: the file's Properties show an empty or broken Digital Signatures tab.
- A hand-copied replacement. Someone copied the file from another machine or dropped in a fix from the internet, and the build or architecture mismatches. Test: the version differs from a twin station, or a 32-bit copy sits in System32 — on 64-bit Windows the 64-bit system files live in System32 and the 32-bit ones in SysWOW64.
- Antivirus quarantine. A scan removed or altered the file. Test: the quarantine log names it.
- Corrupt Visual C++ runtime. The named file is a runtime module such as vcomp140.dll. Fix: repair or reinstall that redistributable from Microsoft first.
- Registry hive damage. The path ends in ...\system32\config\system. That is OS-level failure; skip to the escalation section below.
Host-side failures cluster in this OS layer, the same ground as frame grabber camera configuration not responding.
The repair, in the documented order
The documented procedure for damaged system files runs the component-store repair before System File Checker, because the checker draws its replacement files from that store. Work from an elevated Command Prompt:
- Record the evidence. Write down the full path from the dialog. On the named file, note the version on the Details tab of Properties and the file date.
- Repair the component store. Run the DISM cleanup-and-restore step online, so it can pull clean components from Windows Update, and let it finish.
-
Run System File Checker. Type
sfc /scannowand let it complete. It checks every protected Windows file against the store and rewrites the damaged ones. Expect 5-20 minutes on a solid-state boot drive; a spinning disk can run past half an hour. - Reboot and retest. Launch the vision application that failed. If it opens cleanly, go to the verification section.
-
If violations remain, repeat the DISM step, then run
sfc /scannowonce more. Two passes clear most remaining cases. - If corruption still stands after two passes, stop repairing and rebuild: an in-place repair upgrade from official Windows media replaces the OS files while keeping your programs and settings.
- Only now reinstall the vision stack, in this order: frame grabber driver, SDK runtime, then the application. The order matters — a frame grabber driver mismatch after a vision software upgrade is its own failure mode, and the runtime files the SDK registers live in the paths covered by GenTL producer not listed: check Windows DLL paths.
Prove the file is fixed: version versus signature
The version number is a text block stored inside the file, so damaged bytes elsewhere leave it readable. A correct version string is a screening check, not proof of a healthy file. The digital signature is the proof: Windows signs its protected files, and the signature covers the actual bytes.
Note the file's state before the repair, then compare after sfc /scannow completes:
- Details tab: version and file date present, matching your notes.
- Digital Signatures tab: the OS publisher listed, and the signature details read as OK.
- Behaviour check: the vision application launches, survives a reboot, and launches again.
What not to do
- Do not download the named file from a DLL site. Those copies are unsigned and unverifiable. The component store on your own disk is the only source System File Checker uses, and it checks what it restores.
- Do not copy the file from another PC as the permanent fix. From a machine running the identical build it can work, and on a line that must run today it is a defensible stopgap — but treat it as a diagnostic and run the System File Checker repair the same day so a verified copy replaces it.
- Do not lead with re-registration. Registering a DLL writes registry entries; it cannot repair damaged bytes, so the same error returns and the time is spent anyway.
When the damage is bigger than one DLL
Three findings move you from repair to rebuild:
- The error names the registry hive (...\system32\config\system) instead of a DLL — that is registry hive corruption on an industrial station, a heavier procedure with its own recovery order.
- Two System File Checker passes report unresolved corruption.
- The corruption returns within days of a clean repair.
Recurring corruption has two usual root causes: failing storage and dirty power. Check the drive's SMART health — a reallocated-sector count that grows between reads means replace the disk — and put vision stations on a UPS. If a restore checkpoint exists from just before the first failure, rolling back beats repairing for speed; keeping System Restore checkpoints on legacy HMI stations is a habit worth copying on every vision PC. Decide it this way: two failed passes means rebuild, because a rebuild takes a known number of hours and a third pass takes an unknown number.
Rebuilding the capture host cleanly
When the OS goes back, rebuild in a fixed order so the next station is reproducible: Windows image, chipset and network drivers, frame grabber driver, SDK runtime, application, then your exported camera configuration. Pause automatic Windows Update on production stations and fold OS changes into change control, taking a restore checkpoint before every software change. If a viewer stops finding cameras after the rebuild, SDK compatibility is usually the reason — see why one viewer works and another fails.
Stations at the line usually run on an industrial panel PC. Image one, verify it, then clone that image to every twin station, so a damaged file becomes a restore instead of a project.
If the rebuild doubles as a hardware refresh, match the capture card to the camera interface you actually run — the frame grabbers range covers the common families:
- Interface
- GigE
- Ports
- 2 ports
- Interface
- 10GigE
- Ports
- 4 ports
A Camera Link host takes a Camera Link frame grabber:
- Interface
- Camera Link
Pick the card with the frame grabber finder and pressure-test the whole build in the accessories step of the configurator.
Checklist before you call it fixed
- Path read and ownership decided: C:\Windows means OS repair, a vendor folder means product reinstall.
- DISM completed, then
sfc /scannow, with no unresolved violations on the final pass. - Named file: version noted before and after; Digital Signatures tab lists the OS publisher and reads OK.
- Vision application launched three times across one reboot with no error.
- Restore checkpoint taken and Windows Update paused on the production image.
- Vision stack reinstalled in order: driver, SDK runtime, application.
More host-side fixes sit on the systems guides topic page. If a rebuild stalls on an error this guide does not cover, send the exact message text through the contact page — the path and the file version are the two facts that speed up any answer.
Questions
Can I copy a system DLL from another PC with the same Windows build?
Only as a diagnostic, never as the fix. A copy from a machine running the identical Windows build can prove the problem is the file, but you cannot confirm the copy is unmodified, the right architecture, or free of malware. System File Checker pulls the file from the local component store and checks what it restores, so make that your repair path the same day.
How long does sfc /scannow take on a vision PC?
Expect roughly 5-20 minutes: the tool checks every protected Windows file against the component store. A solid-state boot drive finishes at the low end; an older spinning disk can run past 20 minutes. Run the DISM component-store repair first, because System File Checker draws replacement files from that store — repairing the store first stops the tool finishing with unresolved violations.
Should I reinstall the vision software first?
No. If the named path is under C:\Windows, repair the OS files first. The vision installer itself loads Windows components and can fail midway, leaving the driver stack half-registered. Repair with DISM and System File Checker, confirm the file's digital signature, then reinstall the frame grabber driver, the SDK runtime and the application, in that order.
The error names a file inside the camera software's own folder — is it the same problem?
No. A damaged file under C:\Windows\System32 belongs to Windows and needs an operating system repair. A bad file in the vision vendor's own folder is that product's file: reinstall it from the vendor's original installer, or replace the stale copy shadowing a current library. Run the OS repair anyway if System File Checker reports violations, so the installer runs on a healthy base.
How do I check a DLL's digital signature?
Right-click the file in File Explorer, choose Properties, and open the Digital Signatures tab. A Windows system file should list the OS publisher as signer; select the signature and read the details, which should report it as OK. Compare the version on the Details tab with a twin machine too. An empty signature list on a system file is evidence the copy is damaged or was replaced.
Why does the error appear only when I open the camera in the vision application?
The damaged file sits quietly until something loads it. The vision application is simply the first program in your workflow that pulls that Windows component, so it takes the blame. Anything else loading the same file would fail the same way. Repairing the file fixes every program at once, which is why the repair belongs to the operating system rather than to the vision software.