Frame grabber interface name mismatch: fix bad interface errors

You pulled a working PCI frame grabber out of a retired PC and fitted it into a new one. The inspection program that ran for years now stops at start-up with a missing entry point in the acquisition DLL, functions the software cannot find, and error -1074397163 in the cleanup module — which the driver also prints as hex 0xBFF60015, bad interface. Nothing is wrong with the board. The driver installation on the new PC assigns interface names that no longer match the name hard-coded in your program. This page decodes the two notations, shows where names such as img0 and img1 come from, walks the fix in the order that works, and helps you decide when to retire the board and rebuild the acquisition side on a current interface.

What the codes say: one fault, two notations

The two numbers are one status code. The application dialog shows the signed decimal form, -1074397163. The driver's own message shows the unsigned hex form, 0xBFF60015, tagged IMG_ERR_BINT, the driver's label for a bad interface. Both point at the same call: the acquisition init that opens a board by name.

The cleanup-module error is a symptom of the same failure. Init never opened a session, so the module that tears sessions down reported the outstanding error on the way out. Fix init and the cleanup error disappears with it.

The entry-point error is mechanically different, and you clear it first. The application asked a DLL for a function the loaded copy does not contain, which means the DLL and the code were built for different driver generations. Until the right DLL loads, init cannot run, let alone report a name problem honestly.

Worked example: converting 0xBFF60015 to -1074397163 in the moved-board PC

The inputs come from the failing PC itself: the driver pop-up prints 0xBFF60015, the application error list prints -1074397163, and status codes in this driver family are 32-bit integers. The question is whether these are two faults or one.

The rule, in words: read the hex digits as an unsigned 32-bit value. When that value reaches 2^31, which is 2,147,483,648 — hex at or above 0x80000000 — the signed decimal your software prints is the unsigned value minus 2^32, which is 4,294,967,296.

0xBFF60015
  = 11*16^7 + 15*16^6 + 15*16^5 + 6*16^4 + 0*16^3 + 0*16^2 + 1*16^1 + 5*16^0
  = 2,952,790,016 + 251,658,240 + 15,728,640 + 393,216 + 0 + 0 + 16 + 5
  = 3,220,570,133                               (unsigned 32-bit value)

3,220,570,133 - 4,294,967,296 = -1,074,397,163 (signed 32-bit value)

The result: one error, two notations. The leading hex digit B is binary 1011, so bit 31 is set, which is why the dialog shows a negative number.

The decision: the tag on the code is the bad-interface status, so the failing input is the interface-name string handed to init — not the camera cable, not the file writer, not the display call. That sets the repair order for the rest of this page: clear the DLL generation first, then make the name string match the driver's assignment.

Why the interface name changes when the board moves

The name is not stored on the board. The driver assigns it while being installed and configured on that PC: the first board installed becomes img0, the second img1, and so on. The mapping lives in the driver's configuration on the new PC, written at install time.

A move re-runs that assignment. Reinstalling the driver, choosing a different slot, or adding a second card later changes the order in which the driver sees the boards, and the names follow that order. A name can move from one physical card to the other.

Your program still asks for the name it was written with. Three ways to fail, all reported with the same bad-interface code: the code asks for a name no board has, it asks for img0 when your board now holds img1, or it asks under a driver generation that is not installed at all.

With several boards the mapping problem grows. The guide to fixing swapped camera channels across multiple frame grabbers covers that case in depth.

Likely causes in order of probability

Work top down; the first two cover most moves that go wrong.

1. Driver generation mismatch. The code was built against a driver generation the new PC never received, so the loaded DLL lacks the entry points your code calls. Test: the start-up error names the acquisition DLL and a missing procedure. Fix: install the release written for your software's generation, as after any vision-software upgrade — the driver mismatch fix — and clear a shadowing DLL copy with the missing entry point walkthrough.
2. Interface name mismatch. The driver on the new PC assigned different names. Test: open the driver's configuration utility and read the name listed beside your board. Fix: pass exactly that string; the steps follow.
3. Wrong run-time loaded. Several run-time versions, or a stale DLL sitting next to the executable, can make the application bind to a build without your functions. Test: record which run-time version loads with the application, and look for a local DLL copy shadowing the installed one. Fix: make the application load the generation it was built against.
4. The board is not in. No driver exists for the new operating system, or the board sits unrecognized in its slot. Test: the board is missing or flagged in Device Manager. Fix: a manual driver installation. If the board is present but the PC halts or no video flows, the fault family is different: cards competing for resources — the guide to resolving frame grabber resource conflicts walks that diagnosis. When the board is present and named yet init still fails, work the firmware and run-time checks in the initialization-failure guide.

Fix the bad interface error step by step

Assume cause 1 is cleared, then work down this list.

1. Install the driver version that matches the generation your code was built against, for the new PC's operating system. If the old PC still boots, read the driver version it runs and match that generation rather than picking the newest release.
2. Reboot and confirm the board appears in Device Manager with no warning icon. A board that is not in cannot be named; clear any flag first.
3. Open the driver's configuration utility and read the interface name assigned to your board: img0 for the first installed board, img1 for the next. With a single board, expect img0 — read it anyway rather than assuming it.
4. Paste that string into the acquisition init call in your program. Copy it from the utility instead of retyping: a trailing space or a capital letter is a different string and fails with the same code.
5. With two or more boards, initialize each name in turn and grab one frame from the camera you expect. If images arrive from the wrong board, swap the assignments in the configuration utility, not in the code.
6. Run the application end to end. When init succeeds there is no failed session to report, so the cleanup-module error and the bad-interface code both disappear. If the entry-point error returns, a second DLL copy is shadowing the installed one; go back to cause 1.

When the board cannot come back: rebuild the acquisition side

Replacement is the honest fix when the old board has no driver for a 64-bit operating system, the new PC lacks the legacy slot, or the product line has ended. Two paths keep the project alive.

Keep the camera, replace the board. If the camera is Camera Link, a current frame grabber such as the MV-GC1102IOL speaks the same camera-side standard and fits a modern host PC. The acquisition concepts carry over from your old code; the Camera Link and CoaXPress acquisition guide maps them onto the current cards. Check the host PC before ordering: free slots, lanes and chipset decide whether the card performs at rate, as the PCIe slots and chipset guide lays out.

Move to GigE Vision instead. A GigE Vision camera needs no frame grabber: a PoE network card feeds power and image data down one cable per camera, and the SDK finds cameras by IP address at run time, so no install-order name exists to break. Fit the MV-GE2002P dual-port PoE NIC, or the LS-FGB-0004 PCIe x4 4-port PoE card.

If the rebuilt line needs more bandwidth than GigE, move to 10GigE cameras, which run on the same found-by-IP model. The MV-GT2104 quad-port copper 10GbE NIC carries four of those links.

Pick the camera side deliberately: browse area scan cameras by resolution, sensor format and interface in the camera finder, and match them against frame grabbers filtered by interface and port count in the accessories finder. For a planned swap rather than an emergency, the interface migration plan gives the order of operations. If the camera itself is analog-era and must stay that way for now, the guide to selecting an analog frame grabber for older vision software walks the like-for-like decision.

Prevention: make the next PC move boring

Three habits keep this failure from returning:

• Read names, never hard-code them. At start-up, ask the driver for its assigned interfaces and open a valid one, or take the name from a configuration file instead of a constant in the source.
• Log the assignment. Write the board name, driver version and camera identity to the run log at init. When a PC is replaced in two years' time, the log shows what the working system actually used.
• Treat the driver version as part of the program. Record the generation the code was built against, next to the source, and install it before the first test on any new PC.

In mixed multi-camera racks, lock the camera-to-port mapping explicitly rather than trusting order, as covered in assigning cameras to ports reliably.

Checks before you order parts

Run this list before spending anything on hardware:

• The board appears in Device Manager with no warning icon.
• The installed driver generation matches the one the code was built against.
• The driver's configuration utility lists your board under a name you have read, not guessed.
• The init call receives that exact string, pasted, same case, no spaces.
• With several boards, each camera maps to the board you expect.
• If replacement is the path, the host PC's free slots and lanes match the card, and the camera interface — Camera Link, GigE or 10GigE — is chosen for the inspection, not by habit.

If every line reads yes and the error still fires, the fault sits downstream of init: camera power, cabling or camera configuration, not the interface name.

To price a rebuild rather than a repair, start at the configurator; it walks interface, port count and host PC in order.