- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
For last years I've faced several different cases of "Error 0x80004005" issue occur ONLY on the 1st run of some iLogic Rules* (I'm primarily focused on external rules), and I like to discuss here those cases and try to determine what unifies them and probably develop some common solution for this behavior.
"The most obvious" (easier to reproduce) Case #1 I'd like to start with was documented by MD_ about a year ago here - https://forums.autodesk.com/t5/inventor-ilogic-and-vb-net-forum/error-0x80004005-on-first-run/m-p/10...
I've tried to reanimate that thread without much success thus created this one (believe this is not any sort of forum rules violation).
I've created my own sample IPT (see attached) and modified original rule a bit in order to nail the issue to moment of processing the second Face:
Sub Main()
Dim oFaces As Faces
Dim oFace As Face
oFaces = ThisDoc.Document.ComponentDefinition.SurfaceBodies(1).Faces
' '[ Variant #1:
' For Each oFace In oFaces
' ThreadBuild(oFace)
' Next
' ']
'[ Variant #2:
For i=1 to 2
oFace = oFaces(i)
ThreadBuild(oFace)
Next
']
' '[ Variant #3:
' oFace = oFaces(1)
' ThreadBuild(oFace)
' oFace2 = oFaces(2)
' ThreadBuild(oFace) ' No Error on 2nd run but doesn't create feature either
' ']
End Sub
Sub ThreadBuild(oFace as Face)
logger.debug(oFace.SurfaceType.ToString)
Dim oTFs As ThreadFeatures = ThisDoc.Document.ComponentDefinition.Features.ThreadFeatures
Dim oTF As ThreadFeature
Dim oEdge As Edge
Dim oThreadInfo As ThreadInfo
Dim sThreadType As String
If oFace.SurfaceType = kCylinderSurface ' Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL))
If oFace.ThreadInfos Is Nothing
sThreadType = GetThreadTypeFromRadius(oFace.Geometry.Radius)
If sThreadType<>String.Empty
oEdge = oFace.Edges(1)
oThreadInfo = oTFs.CreateStandardThreadInfo(True, True, "ISO Metric Profile", sThreadType, "6H")
oTF = oTFs.Add(oFace, oEdge, oThreadInfo, False, True)
End If
End If
End If
End Sub
Function GetThreadTypeFromRadius(dRadius As Double) As String
Dim sThreadType As String
logger.debug(Round(dRadius, 3))
Select Round(dRadius, 3)
Case 0.078
sThreadType = "M2x0.4"
Case 0.123
sThreadType = "M3x0.5"
Case 0.162
sThreadType = "M4x0.7"
Case 0.207
sThreadType = "M5x0.8"
Case 0.246
sThreadType = "M6x1"
Case 0.354
sThreadType = "M8x1.25"
Case 0.419
sThreadType = "M10x1.5"
Case 0.505
sThreadType = "M12x1.75"
Case 0.592
sThreadType = "M14x2"
Case 0.692
sThreadType = "M16x2"
' Case Else
' Nothing
End Select
Return sThreadType
End Function
Pay attention there are three different ways to execute the things (feel free to have any one uncommented while playing around).
Any ideas of possible workaround?
* Whether you undo changes made by 1st run or just delete those changes manually, after you run the rule one more time - things goes as smooth as expected to (except for Variant#3 which is a sub-issue to be explored).
But if you close the Inventor Document and reopen it - the issue become reproducible again.
I also found that "the rule" can run smoothly even on its 1st run if some other (relative) rule was run before it.
Please vote for Inventor-Idea Text Search within Option Names
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
While waiting for some new inspiring* info I managed to create an inelegant workaround for the Case#1 based on assumption that all I need is the 2nd code run.
Now I run the Core-code (an external iLogic rule) with another "Wrapper" iLogic rule TWICE.
1-st run processes the 1-st FOR-cycle iteration and returns index of the item it failed on.
2-nd run starts from the point of the fail.
Thus at least I get things done with running code (wrapper-rule) just once.
Those interested can find result of my coding together with a sample part (Inventor 2022 and STP export for earlier versions) in the ZIP attached.
Yet I don't feel happy - I still need some official comment on this issue from some competent Autodesk person .. because it looks like ... an Inventor API defect, right?
* I was told that the issue (apart from iLogic) is reproducible in VBA and updating to Inventor 2023 doesn't solve it either.
I have no plans to re-check those statements myself yet I'm going to try to reproduce it in C#.
Please vote for Inventor-Idea Text Search within Option Names
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
Hi @Maxim-CADman77 , the error happens because when you add a feature the body is recalculated. After it's recalculated, the face references you got before are now stale. You have to get the body and faces again. This happens even though the thread feature doesn't add or remove faces. The body is still recalculated.
Since the number and order of the faces doesn't change, you can just use the face index as a "persistent identifier". See the attached rule. If you were adding a feature that affected the number of faces, then you would need to use ReferenceKeys or Attributes to get a persistent ID.

Mike Deck
Software Developer
Autodesk, Inc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
Almost clear now.
The only question remained:
Why 2nd run used in my workaround did the trick for the given sample?
I would expect it to process correctly just 2nd face ... then 3rd run needed for 3rd face etc...
PS: I've marked the thread solved. I'll reopen it if I'll find that your explanation doesn't solve any other case I've mentioned earlier.
Please vote for Inventor-Idea Text Search within Option Names
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
@Maxim-CADman77 , looks like I was wrong. The body is not recomputed every time. Something is done to it the first time, but I'm not sure what. In any case it looks like a defect.
It seems like creating the first feature initializes something in the body (or associated data). After that initialization, you have to get the body and faces again. After you get them again, it will succeed.
And the first feature does not have to remain in the part. I found that this works:
- open your 10-hole part
- Run a version of the rule with no error handling and no refresh of the faces collection. It will create one thread feature and then error out.
- Manually delete the new thread feature.
- Run the rule again. This time it will succeed and create features on all holes.
Here's a version of the rule that refreshes the faces collection only once: after it has created the first feature. This works.
I will look at this in more detail and probably create a bug for it. Please let me know if you find other cases like this.

Mike Deck
Software Developer
Autodesk, Inc.