Common NXOpen Runtime Errors and Their Real Causes

A collection of specific, resolved error cases from developer forums that go beyond what the exception documentation says, focused on why these errors actually happen in practice.

"Attempt to use an object that is not alive" / invalid tag errors

This exception (and its cousin, "invalid solid object tag" reported on Eng-Tips) shows up when code holds a reference — a tag or a TaggedObject — to something that has since been deleted or invalidated, often after an update, undo, or a feature edit that replaced the underlying object. One Eng-Tips thread traced a specific "invalid solid object tag" case back to a bug involving a bad component array in an assembly (identified as a bug in NX 5.0.0.25 at the time). More generally, this class of error is also associated with parts that came in via IGES/STEP import from other CAD systems — running File → Utilities → Part Cleanup is the recommended first troubleshooting step for import-related object corruption before assuming it's a code bug.

Practical implication for NXOpen code: don't cache tags/object references across operations that might invalidate them (updates, undo, replace/edit operations). Re-fetch objects from the model after any operation that could have changed the feature/body tree, rather than trusting a tag captured earlier in the same script.

"Incorrect Object for this Operation" with builder Commit()

A concrete, resolved case from NX Journaling: calling .Commit() on a SketchPolygonBuilder threw "Incorrect Object for this Operation." The cause was a missing required property that the journal recorder simply hadn't captured — specifically the Size property:

sketchPolygonBuilder1.Size = NXOpen.SketchPolygonBuilder.SizeType.CircumscribedRadius;

The person who hit this noted the property "wasn't added when I recorded the journal." This is a broader, generalizable lesson about journal recording: the recorder does not necessarily capture every property a builder needs for Commit() to succeed — it records what changed from the default during the interactive session, and if a value happened to already be at its default when recorded, that assignment simply doesn't appear in the generated code, yet may still be strictly required depending on other property combinations. When adapting recorded code into a reusable tool, explicitly set builder properties that affect validity rather than assuming the recorded subset is complete.

Session.Execute() "silently" not working

An Eng-Tips thread describes a case where a MainDll, launched from an NX menu, tried to invoke a separate OpenPartDll via:

theSession.Execute("C:\Demo\OpenPartDll.dll", "OpenPart", "Main", cmdArgs);

with no exception thrown and no visible effect. The thread's discussion didn't converge on a single documented root cause, but the practical advice that came out of it was to consider NX Remoting as a more robust alternative for cross-DLL / cross-process invocation scenarios instead of relying on Session.Execute() chaining — several developers in similar threads reported more predictable behavior building on NXOpen Remoting for scenarios where one component needs to drive another instead of runtime DLL execution.

Practical takeaway

• Never hold onto object tags across update/undo boundaries — re-resolve them.
• Treat recorded-journal builder property lists as a starting point, not a guaranteed-complete set — validate against the API reference for properties required at Commit() time.
• If Session.Execute() silently no-ops when chaining custom DLLs, consider NX Remoting as the more reliable pattern rather than continuing to debug the Execute call.