topic Re: Revit crash when IUpdater calls AnalyticalToPhysicalAssociationManager in Revit API Forum

Revit crash when IUpdater calls AnalyticalToPhysicalAssociationManager

sroswurm4GJQU — Mon, 09 Sep 2024 16:37:10 GMT

Morning All,

I have a reproducible test case demonstrating a Revit crash which appears to be deep in the guts of the Revit API. The crash manifests in a very specific use case where we try to use AnalyticalToPhysicalAssociationManager behavior inside an IUpdater. Specifically, the crash only occurs when the IUpdater.Execute() is triggered by a "reset beam system" action by the user.

The big-picture purpose of the logic in question is as follows:

Element.GetChangeTypeElementAddition()

When the IUpdater.Execute() method is raised, get the new ElementId list via

ICollection<ElementId> allAddedIDs = data.GetAddedElementIds();

If the list is NOT null or empty then iterate it

During the iteration, if the current new element has BuiltInCategory == BuiltInCategory.OST_StructuralFraming then create a new AnalyticalMember at a dummy location. Yes, I know we could do this with filters on the trigger - I just didn't for this demo test case.

If the new AnalyticalMember was created successfully, then instantiate an AnalyticalToPhysicalAssociationManager

Use the new AnalyticalToPhysicalAssociationManager to associate the new analytical ID to the current newly created physical element obtained in the UpdaterData

The above sequence of steps performs perfectly in a wide variety of use cases, including singular copy/past of existing structural framing elements, bulk copy/paste of many existing structural framing elements, and hand modeling of new framing elements. But it fails spectacularly when the IUpdater is triggered by a Beam System "reset" action. When this occurs, I see a complete crash of Revit itself and no amount of error handling or try/catch can capture the issue or prevent crash.

The attached test case is isolated using a simplified stripped-down macro inside the test .rvt file. But I have also tested using a similar program as an ExternalApplication and used Visual Studio 2022 debugger to attach to the Revit process. When VS22 breaks at the exception, it does not point to the addin source, but instead points into RevtiDBAPI.dll

Please see attached for a Revit 2024 project file containing both the macro and the structural geometry needed to observe the crash. To replicate the crash, simply unregister and then re-register the updater to make sure the IUpdater is active in the Document.

Then reset the beam system found in the model:

You will observe after a brief hang that the Revit crashes and closes.

To observe the IUpdater working as expected with no crash, simply hand-model a new beam, or copy/paste one or more existing beams. You'll see that no errors are thrown and the new analytical elements are created at the hard-coded dummy location and associated correctly.

The full source of the IUpdater is found in the Macro Manager:

You should also be able to observe that there is no crash if you comment out line 153 in the macro:

myManager.AddAssociation(newAnalyticalMember.Id, newlyCreatedId);

I'm hoping we can get some resolution for this API bug, as it's causing considerable issues for our customers.

Thanks,

Seth

@jeremytammik

Re: Revit crash when IUpdater calls AnalyticalToPhysicalAssociationManager

jeremy_tammik — Tue, 10 Sep 2024 07:58:33 GMT

Dear Seth,

Thank you for your report, description and sample material. Sorry to hear about this.

I logged the issue REVIT-226399 [IUpdater using AnalyticalToPhysicalAssociationManager crashes Revit] with our development team for this on your behalf as it requires further exploration and possibly a modification to our software. Please make a note of this number for future reference.

You are welcome to request an update on the status of this issue or to provide additional information on it at any time quoting this change request number.

This issue is important to me. What can I do to help?

This issue needs to be assessed by our engineering team and prioritised against all other outstanding change requests. Any information that you can provide to influence this assessment will help. Please provide the following where possible:

Impact on your application and/or your development.
The number of users affected.
The potential revenue impact to you.
The potential revenue impact to Autodesk.
Realistic timescale over which a fix would help you.
In the case of a request for a new feature or a feature enhancement, please also provide detailed Use cases for the workflows that this change would address.

This information is crucial. Our engineering team has limited resources and must focus their efforts on the highest impact items. We do understand that this will cause you delays and affect your development planning, and we appreciate your cooperation and patience.

Best regards,

Jeremy

Re: Revit crash when IUpdater calls AnalyticalToPhysicalAssociationManager

sroswurm4GJQU — Tue, 10 Sep 2024 15:23:43 GMT

Hi Jeremy,

As always, thanks for your effort in helping authenticate the issue. Please see below for a few thoughts on each of the topics you listed:

Impact on your application and/or your development.

This one is definitely a big deal for us and our customers. The specific customer who reported the issue works a lot with beam systems, and they actually ended up deciding to temporarily uninstall our product while we were tracing the crash. So clearly the problem has a serious impact for all parties involved - impact on revenue for us and on productivity for the customer.

The crash also has a tangible impact on our development efforts moving forward. We will be forced to divert resources ASAP to search for a workaround which protects our customers from this flaw in the Revit API. That means less manpower moving us forward on new features our customers are excited to see while we try to find a way to mitigate the crash problem. The solution will most likely involve attempting to pre-detect whether a Beam System is involved each and every time the IUpdater is called. This means we'll be stuck with:

Extra logic we never wanted to have

Extra overhead during runtime to execute more protective logic

Loss of desired behavior any time Beam Systems are involved. Our new safety checks (if we're able to implement them) will completely preclude the intended behavior of the IUpdater, so there will be a measurable loss of functionality in order to prevent the risk of Revit crashes.

The number of users affected.

The customer base for our particular addin is a subset of our broader base of structural engineers who use our standalone analysis and design tools. That broader base from which we're seeking to grow Revit-integrated users is about 20,000 active monthly users. So we're serving a large and influential market and we'd very much love to see that entire group become aggressively Revit-integrated, but the API has to be rock-solid for us to maintain trust with the customer.

Beyond our particular customer base, I can easily see this crash being a big problem for any other structural software vendor who uses the Revit API in Revit 2023 or newer to take advantage of the newly overhauled Revit analytical framework. Essentially any Revit addin in the world which attempts to call AnalyticalToPhysicalAssociationManager in response to a user action in the model is at risk of this same crash.

The potential revenue impact to you.

This is tightly coupled with the discussion above regarding growing the customer base via trust and reliable performance.

The potential revenue impact to Autodesk.

If the crash persists, it could easily start to erode customer trust in many aspects of Revit analytical workflows. The Revit structures team at Autodesk has been working very hard for a long time to build buy-in, trust, and higher comfort level among structural engineers regarding Revit-based analytical modeling, so I think it's very important to get a timely solution for anything that could harm that trust.

Realistic timescale over which a fix would help you.

It stands to reason that faster is certainly better for receiving a Revit API fix from Autodesk. In the long-term, we and other vendors will have no choice but to attempt a workaround which protects our customers from catastrophic data loss due to a Revit crash. If a Revit patch was available VERY soon, that extra would be unnecessary. But as that time horizon stretches, we'll be stuck with progressively less ideal solutions which rob customers of convenience and desired behaviors.

In the case of a request for a new feature or a feature enhancement, please also provide detailed Use cases for the workflows that this change would address.

Not applicable in this case, since we are actually discussing the malfunction of an existing feature.

Thanks,

Seth

Re: Revit crash when IUpdater calls AnalyticalToPhysicalAssociationManager

jeremy_tammik — Tue, 10 Sep 2024 15:39:47 GMT

Dear Seth,

Thank you for your update, appreciation and business case.

I added it to the issue REVIT-226399 [IUpdater using AnalyticalToPhysicalAssociationManager crashes Revit].

The development team has already scheduled it for an upcoming sprint.

Best regards,

Jeremy

Re: Revit crash when IUpdater calls AnalyticalToPhysicalAssociationManager

sroswurm4GJQU — Tue, 10 Sep 2024 16:18:10 GMT

That's great to hear!! Thanks again!

Seth

Re: Revit crash when IUpdater calls AnalyticalToPhysicalAssociationManager

jeremy_tammik — Mon, 23 Sep 2024 13:42:31 GMT

So, simple it is not. The problem seems to be related to the fact that we have 2 updaters which are modifying the same unique element: AnalyticalToPhysicalAssociationManager. When we reset a beam system, several things happen:

Some beams are created which will trigger the new updater to create new AM elements and add association with the added physical element; this will mark atoms touched for AnalyticalToPhysicalAssociationManager, because we are modify association repo
Some beams are deleted: this will trigger AssociationsDynamicUpdater to execute, which will remove the association for the deleted elements, marking atoms touched for the same AnalyticalToPhysicalAssociationManager, because we are modify association repo
An exception is raised, because we have 2 updaters that are modifying the same element: Updater c788ec8b-59af-482e-a20a-08274fbbd20d (LightBox updater: AssociationsDynamicUpdater) is changing the same data in an element as updater 9d15d63d-a21a-4ba4-ae00-0797ca0fa4e7 (the new updater).

Re: Revit crash when IUpdater calls AnalyticalToPhysicalAssociationManager

jeremy_tammik — Fri, 27 Sep 2024 15:06:52 GMT

Dear Seth,

Thank you again for your report and sample material. The development team analysed the ticket REVIT-226399 [IUpdater using AnalyticalToPhysicalAssociationManager crashes Revit] and say:

The issue could be reproduced in the customer case (custom addin that is using Revit Updater mechanism to add associations between physical and analytical elements) when pressing the "Reset System" button from "Modify | Structural beam Systems > Edit Boundary" contextual ribbon when editing a beam system. Currently, there is no workaround for this.

They closed the original ticket and submitted a new one REVIT-227102 [IUpdater using AnalyticalToPhysicalAssociationManager crashes Revit] for the code fix. Please make a note of this number for future reference.

Best regards,

Jeremy

Re: Revit crash when IUpdater calls AnalyticalToPhysicalAssociationManager

jeremy_tammik — Tue, 01 Oct 2024 08:18:00 GMT

Dear Seth,

Thank you for your patience and congratulations on eliciting a message from the development team that I have never seen before. Bad news, I'm afraid. They say:

It has been determined that this request involves refactoring (or rewriting) the existing mechanism to support the user's workflow. The current mechanism did not account for this scenario when it was originally implemented. Addressing this request might require significant effort and introduces risks to the existing capabilities that have been developed on top of the current mechanism.

So, please don't hold your breath waiting for this to be fixed. Is there any other way to achieve the BIM result that you need, that avoids generating the problematic scenario? Sorry for the bother!

Best regards,

Jeremy