SEHException on CheckoutElements?

[Anonymous]

Why might WorksharingUtils.CheckOutElements() throw System.Runtime.InteropServices.SEHException: {"External component has thrown an exception."}  I think this has something to do with going back and forth between managed and non-managed so this may be a foolish thought but the documentation doesn't mention this exception as possibly being thrown from CheckoutElements().  (I confess that SEH isn't a strong suit in my .NET knowledge)

Background:

I've run right up against the fact that updaters are called on modified elements BEFORE Revit determines that the element cannot be edited because it is updated in the central model.  So my updaters are firing and updating my lists but the change never actually happens so things go haywire and my lists are off by an element count.

In an attempt to work around this issue, I thought it might be smart to check to see if the element could be checked out and if so, was its model update status suitable for editing.  However, when I try to check this element out, CheckoutElements() is throwing a structured exception handler exception

System.Runtime.InteropServices.SEHException occurred
  HResult=-2147467259
  Message=External component has thrown an exception.
  Source=RevitDBAPI
  ErrorCode=-2147467259
  StackTrace:
       at WorksharingUtils.checkoutElements(SetReturn<ElementId\,std::less<ElementId>\,tnallc<ElementId> >* , ADocument* , Set<ElementId\,std::less<ElementId>\,tnallc<ElementId> >* )
       at Autodesk.Revit.Proxy.DB.WorksharingUtilsProxy.CheckoutElements(DocumentProxy document, ICollection`1 elementsToCheckout)
  InnerException:

I think this could be related to running two users in one Revit session, or could be related to attempting to checkout elements in an updater?  Just need some ideas on where to start figuring this out.

I'm catching the exception but don't know what else to do other than determine that it can't be edited so I'm sometimes updating my internal lists and sometimes not...

If there are no ideas, I'll work on setting up a minimally reproducible case.

Thanks,

-Ken

[Anonymous]

Update:
Calling Checkout Elements seems to be throwing this if the element no longer exists in the model.

[Anonymous]

Update 2: put in a check to see that I can get the element from the model prior to attempting to check it out and the element does actually still exist in the model.

I'm going to work on putting together a minimally reproducible case and see what I can figure out. Will keep this updated.

[arnostlobel]

Ken,

SEHExceptions are always indications of a bug in Revit. Ir may not be Revit self (but an external app) causing the problem, but Revit should be able recover from it and should not let any exception to be re-thrown as an SEHExceptions. Please connect with Jeremy and ask him to file a bug report. A reproducible sample would help tremendously, of course. If you can, add you code as macro into the document (simplified as much as possible) you test it on and upload the document to us. That always speeds up the process of us investigating it.

Thanks

and sorry for the inconvenience. 

[Anonymous]

Top of the morning to you!

Unfortunately I tried the most simple reproduction and it didn't work so
I'm working on the next step up in complexity to see if I can reproduce it.


Thanks for the information and I'll do my best to make a minimally
reproducible case.

Thanks also for reading through these.

-Ken

[Anonymous]

Got it. 

Attached is the minimal reproducible case.  The app consists of two updaters, each updater targets a different change priority but both target the same change type.  The second updater (changePriority.Annotations as opposed to updater 1 with change priority.Structure) attempts to checkout the elements again and throws.

Reproduction (assuming test application is installed/setup):

1. Create new revit file from Structural Template (most likley any template. will work)

2. Create an element (I used a Beam)

3. make this file a workshared file, save it, then sync with central relinquising all, then close central

4. change user name, open central with "create new local" option checked

5. Attempt to change the length of the beam -> Second updater throws

[jeremytammik]

Dear Ken,

Thank you for your report and reproducible case.

I logged the issue REVIT-86309 [SEHException on CheckoutElements -- 11536135] 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.

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 of the 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 extremely important. Our engineering team have limited resources, and so 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

[MattKincaid]

Has there been fix to this?  Or a workaround discovered?  We have a customer experiencing a similar error, using Revit 2024, when our Addin calls Autodesk.Revit.DB.Definitions.Create().  But no luck reproducing internally so far.  API version 24.1.10.25.

[jeremy_tammik]

Tricky to say what "this" exactly refers to. The issue REVIT-87154 [SEHException on CheckoutElements -- 11536135] was closed as fixed in 2016, and the issue described there thus resolved from Revit 2018 onwards. Maybe it is time to submit a completely new thread, with a new issue, preferably with a complete minimal reproducible case to analyse.

[MattKincaid]

I was wondering whether there was a way to prevent the Revit API from re-throwing SEHException.  Will open a new thread if I discover a way to reproduce the error minimally.  Appreciate the update.

[MattKincaid]

Update: It turned out to be an Anti-Virus program causing interference.  Disabling AV solved it.

[jeremy_tammik]

Cool! Congratulations on solving!