LabVIEW Iuse.cpp Crash: Broken vi.lib Link, Not a Bug

A polymorphic VI that breaks the run arrow the moment it lands on the diagram is almost never a defect in the shipping code. It is a linkage problem: one member instance inside Acquire Input Data.vi no longer resolves to the file the polymorphic wrapper expects. The wrapper stores a path plus a connector-pane map for every instance. Break one entry and the whole wrapper goes broken, even though every other instance is intact and the offending member opens and runs perfectly on its own.

The crash is the same fault seen from the other side. Turning the polymorphic selector forces LabVIEW to swap the subVI node's link in place. That swap works on the in-memory instance record, not on the file. When the record points at a member that loaded partially or whose connector pane no longer matches the stored map, the swap dereferences garbage and LabVIEW dies with an internal file and line number instead of a clean error dialog. Iuse.cpp line 1841 is the symptom of the bad link, not the cause.

Get it running, then fix it properly: relink or restore the single member VI. Do not reinstall LabVIEW yet.

Skip the Three Fixes That Waste the Shift

• Dragging a fresh copy off the palette. The palette points at the same vi.lib file. The new copy breaks identically.
• Restarting LabVIEW. Clears memory, changes nothing on disk. If the bad link is a duplicate file in the search path, it reloads on the next open.
• Full uninstall and reinstall. Two to four hours, and it will not remove a stray duplicate VI sitting in user.lib or a project folder, because the installer never put it there.

Check 1: Read the Error List Before Touching Anything

1. Open the broken caller and click the broken run arrow. The Error List names the offending node and the reason.
2. Open Acquire Input Data.vi itself from vi.lib, then use the polymorphic VI's instance list to see which member carries the broken arrow.
3. Record the exact wording. It routes the rest of the job.

Error List text	What it means	Go to
SubVI is not executable	The member itself is broken, or a subVI below it is	Check 2
Connector pane of the subVI has changed	The loaded member's terminal map no longer matches the wrapper's stored map	Check 2
SubVI not found / node appears grayed	The instance never loaded; every caller holding that refnum shows a placeholder node	Check 3
Member opens standalone and runs clean	Classic cross-link: two files with the same name on disk	Check 2

The last row is the one that trips people. A member VI that runs by itself but breaks its parent is the signature of cross-linking, not corruption.

Check 2: Hunt the Cross-Linked Duplicate

LabVIEW resolves subVIs by name against a search path list, and the first match wins. Any second file with the member's name — dropped into user.lib, left behind by a toolkit or VI Package, sitting in the project directory, or buried in an LLB on the search path — will be loaded in place of the vi.lib original. Its connector pane will not match, and the wrapper breaks.

1. With the polymorphic VI open, select View > This VI's SubVIs (or check the title bar of the opened member) and confirm the full path each instance resolved to.
2. If any instance resolved outside vi.lib, you found it. Move the duplicate out of the search path — rename the folder, do not delete until the fix verifies.
3. Search the whole LabVIEW directory tree plus your project folders for the member VI's filename. Expect exactly one hit under vi.lib.
4. Check Tools > Options > Paths > VI Search Path for entries added by an installer or by hand that point at a stale code archive.
5. Close all VIs, restart LabVIEW, reopen the caller.

Stop here if the run arrow comes back solid. Save nothing in vi.lib. You are done.

Check 3: Force a Recompile and Clear the Cache

If the paths are clean and the member still breaks in context, the compiled code is stale rather than the source.

1. Open the broken member and press Ctrl+Shift+Run arrow to force a recompile of that VI and its hierarchy, then save it.
2. On LabVIEW versions that keep compiled code out of the VI file, run Tools > Advanced > Clear Compiled Object Cache, close LabVIEW, and reopen.
3. Mass compile the Input Device Control directory under vi.lib with Tools > Advanced > Mass Compile. Watch the log window: it lists every VI that fails to load and the reason, which is often more specific than the Error List.
4. If LabVIEW is installed under Program Files, launch it as administrator first. Without write permission, relinked VIs cannot save and the fix evaporates on the next launch.

Mass compile only after Check 2. Compiling with a cross-linked duplicate in the search path bakes the wrong link into every caller in the tree.

Restore the Member VI: Repair Install, Not CAB Archaeology

Pulling one VI out of the distribution media is possible — the payload lives inside compressed archives, and a file manager that can browse and search inside .cab files will get you there if you already know the internal path. It is slow, easy to get wrong, and gives you no guarantee the extracted file matches the service pack level currently installed.

Use the installer's own repair path instead:

1. Close LabVIEW.
2. Open the Windows program list, select the LabVIEW development system entry, and choose Repair (or run the distribution media's installer and pick Repair when prompted).
3. Point it at the same media the machine was installed from. Repair replaces mismatched or missing files without touching your projects, and it is a fraction of the time of an uninstall.
4. Reapply any service pack or patch that was installed after the base version. Repair rolls files back to the media's revision.
5. Relaunch and reopen the caller.

Copying the file from another machine works only if the LabVIEW version and bitness match exactly. A VI saved by a newer version will not open in an older one, and if a newer LabVIEW ever opened your vi.lib and saved it, that is your root cause.

Verify, Then Watch for These

1. Place a fresh Acquire Input Data.vi from the palette on a blank diagram. Run arrow must be solid before you wire anything.
2. Cycle the polymorphic selector through every instance. No crash, no broken arrow at any position.
3. Open a shipping example that wires a keyboard refnum and run it. The node must render normally — no gray placeholder.
4. Close LabVIEW completely, reopen, and load the same example. Relinks only persist if the callers were saved; a fix that survives a restart is a real fix.
5. Confirm the Error List is empty on the top-level VI, not just on the member.

Recurring traps on this class of failure:

• Editing a polymorphic member's connector pane invalidates the wrapper's instance map. Never resave a vi.lib member after opening it to "check" it.
• Toolkits and VI Packages that install into user.lib with generic filenames are the usual source of cross-links. Audit that folder after any add-on install.
• Opening a project with a mixed-version LabVIEW installation silently upgrades vi.lib files. Keep versions on separate machines or separate installs.
• A read-only vi.lib produces a fix that works until you close LabVIEW, then reverts.

FAQ

If a Repair install completes cleanly, the search path holds one copy of the member VI, and the polymorphic selector still crashes at Iuse.cpp, stop working the file. Capture the crash dialog text and the log written to your LabVIEW Data folder, note the LabVIEW version and service pack, and open a case with NI technical support. Repeated internal-file crashes after a verified repair point at the installation or the OS-level file state, not at anything you can fix from the diagram.