Revit crashing on specific IExternalCommand

[MartijnKalec]

Hi, good evening (from where I'm located at),

I've been dealing with a problem with an add-in we are developing for Revit. And it's an issue we've only seen from one user up until now. The problem is that when the user tries to execute a certain command, his Revit application crashes without any error or warning. We are currently pulling our hair out trying to figure out what's wrong.

So to explain what's happening:

Every button here is initialized to a class that implements the IExternalCommmand interface in Revit. So in this case, the "Start" button is calling a  MainCommmand class.

    class MainCommand : IExternalCommand
    {
        /// <summary>
        /// Opens the main menu dialog for the plugin. 
        /// WPF dialog with Bing maps to specify the project location.
        /// </summary>
        /// <param name="commandData"></param>
        /// <param name="message"></param>
        /// <param name="elements"></param>
        /// <returns></returns>
        public Result Execute(ExternalCommandData commandData, ref string message, ElementSet elements)
        {

The issue is however, that every button except for the "Start" button is working fine. But the moment the user presses the Start button, the cursor shows a loading animation for about 5-10 seconds, after which Revit crashes. No warning, error, or anything.

So to sum up some things we already know and tried:

- When initializing, our users put in a license key, where they already have to connect to our servers. So it doesn't seem that any kind of proxy is causing issues. The setup from this specific user is also quite straightforward, no setup with virtual machines or anything. Just a Windows 10 computer with a Revit installation.

- Besides initialization working fine, other buttons are still working correctly, so I think we can conclude that Revit can at least find our DLL. It just seems that this specific "MainCommand" is lost in the void or something.

- All of our entry points are immediately wrapped in a try-catch block, so that we should get any errors logged in Sentry.io (which we are using for error logging). As you can see in the code snippet down here, any code should be executed inside of the try-catch block.

 class MainCommand : IExternalCommand
    {
        /// <summary>
        /// Opens the main menu dialog for the plugin. 
        /// WPF dialog with Bing maps to specify the project location.
        /// </summary>
        /// <param name="commandData"></param>
        /// <param name="message"></param>
        /// <param name="elements"></param>
        /// <returns></returns>
        public Result Execute(ExternalCommandData commandData, ref string message, ElementSet elements)
        {
            //entry point
            try
            {
                #region
                #endregion
                return Result.Succeeded;
            }

            catch (Exception ex)
            {
                //Critical (or fatal) level breadcrumbs currently don't seem to get a color emphasis on the sentry.io dashboard
                SentrySdk.AddBreadcrumb(
                    message: "Unhandled exception at the MainCommand entry point.",
                    level: Sentry.Protocol.BreadcrumbLevel.Critical
                    );
                SentrySdk.CaptureException(ex);

                SentryHelpers.ShowGenericErrorMessage();

                return Result.Failed;
            }
        }

- Because we don't have our Sentry logs, we've taken a look at the journals/logs that we get from Revit. At first, we read this at the end, just before the crash. So we took a look at our DLL's with dotPeek, and saw that we indeed used the wrong API DLL's from Revit (2019 instead of 2021). So we created a new installer with the correct DLL's to try that.

 Jrn.MouseMove    0 ,    779 ,     51
 'E 10-Dec-2021 16:34:30.622;   0:< 
 Jrn.RibbonEvent "TabActivated:Add-Ins"
 'E 10-Dec-2021 16:34:32.150;   0:< 
 Jrn.RibbonEvent "Execute external command:CustomCtrl_%CustomCtrl_%Add-Ins%Enveo%Start:Kalec.Enveo.MainCommand"
' 1:< API_ERROR { : Assembly version conflict in some references in Kalec.Enveo.dll assembly
'Addin's module RevitAPIUI of version 19.0.0.0 conflicts with same preloaded module of version 21.0.0.0
'Addin's module RevitAPI of version 19.0.0.0 conflicts with same preloaded module of version 21.0.0.0 } 

- This wasn't really successful unfortunately. It made the last API_ERROR go away for sure, but we ended up with this in our logs. So the error is gone, it shows that our MainCommand is called, but after that the logging just stops.

' 0:< ::66:: Delta VM: Avail -81 -> 134209916 MB, Used +83 -> 1289 MB, Peak +106 -> 1312 MB; RAM: Avail -2 -> 19371 MB, Used +2 -> 1173 MB, Peak +28 -> 1199 MB 
' 0:< GUI Resource Usage GDI: Avail 9145, Used 855, User: Used 476 
'  0.173514   1:<<<;PERF;MISC;drawing 
'C 16-Dec-2021 17:03:44.730;   0:< idle0_doc 
 'E 16-Dec-2021 17:03:46.256;   0:< 
 Jrn.RibbonEvent "Execute external command:CustomCtrl_%CustomCtrl_%Add-Ins%Enveo%Start:Kalec.Enveo.MainCommand"

- If I look at the logging at initialization, everything looks fine from what I can tell:

' 0:< GUI Resource Usage GDI: Avail 9809, Used 191, User: Used 172 
' 0:< API_SUCCESS { Added pushbutton Id: 6430, name: Start, text: Start, class: Kalec.Enveo.MainCommand, assembly: C:\Program Files (x86)\Kalec Software\Enveo2021\Kalec.Enveo.dll, parentId: CustomCtrl_%Add-Ins%Enveo } 
' 0:< API_SUCCESS { Added pushbutton Id: 6431, name: Verwijder omgeving, text: Verwijder omgeving, class: Kalec.Enveo.src.Tools.DeleteEnveo, assembly: C:\Program Files (x86)\Kalec Software\Enveo2021\Kalec.Enveo.dll, parentId: CustomCtrl_%Add-Ins%Enveo } 
' 0:< API_SUCCESS { Added pushbutton Id: 6432, name: Verplaats omgeving, text: Verplaats omgeving, class: Kalec.Enveo.src.Tools.MoveEnveoLocation, assembly: C:\Program Files (x86)\Kalec Software\Enveo2021\Kalec.Enveo.dll, parentId: CustomCtrl_%Add-Ins%Enveo } 
' 0:< API_SUCCESS { Added pushbutton Id: 6433, name: Handleiding, text: Handleiding, class: Kalec.Enveo.src.Tools.FrequentlyAskedQuestions, assembly: C:\Program Files (x86)\Kalec Software\Enveo2021\Kalec.Enveo.dll, parentId: CustomCtrl_%Add-Ins%Enveo } 
' 0:< API_SUCCESS { Added pushbutton Id: 6434, name: Over Enveo, text: Over Enveo, class: Kalec.Enveo.src.Tools.AboutEnveo, assembly: C:\Program Files (x86)\Kalec Software\Enveo2021\Kalec.Enveo.dll, parentId: CustomCtrl_%Add-Ins%Enveo } 
' 0:< API_SUCCESS { Registering DocumentOpened event by application Enveo (07571c28-b980-476c-a31f-0a30579f0ab2). } 
' 0:< API_SUCCESS { Registering DocumentCreated event by application Enveo (07571c28-b980-476c-a31f-0a30579f0ab2). } 
' 0:< API_SUCCESS { Registering DocumentClosing event by application Enveo (07571c28-b980-476c-a31f-0a30579f0ab2). } 
' 0:< API_SUCCESS { Starting External Application: Enveo, Class: Kalec.Enveo.Init, Vendor : KLC(Kalec Software, www.enveo.io), Assembly: C:\Program Files (x86)\Kalec Software\Enveo2021\Kalec.Enveo.dll } 

So our current plan:

- We have created an installer that is not obfuscated, to see if that is causing any issues.

- And we have also created an installer that is including every single DLL we referenced in our project (all the .NET framework DLL's for example).

- And of course an installer that is both unobfuscated and includes every DLL.

Is there something else anyone here thinks we can try to solve this? We been back-and-forth with this user for the past week, without any success. Any help would be greatly appreciated.

[RPTHOMAS108]

Can only really guess at what could cause the exception from the documentation comments above the IExternalCommand. Opens a WPF dialogue that shows a Bing map to locate the project. Your licensing server and the server for this are not the same. So the user being able to see the outside world is not an indication of them being able to see everything in it.

From your lack of logging I assume the exception is not being caught. Not all exceptions are dealt with by the CLR. So called corrupted state exceptions are not passed onto it by default anymore. These often result in the application being terminated as you describe (to protect resources the application deals with).

This article notes how the HandleProcessCorruptedStateExceptions can be used with SecurityCritical to handle such exceptions. It may give you more context but I would look at the what if's associated with the code you are not showing. For example what is the result of an application making a web request and getting blocked. Also would overzealous anti virus even terminate such a process? 

CLR Inside Out - Handling Corrupted State Exceptions | Microsoft Docs

Is in interesting article that highlights how (catch exception e) is bad practice although everyone seems to do this.

Noted also that the documentation for WPF Bing maps control is no longer being updated and seems can't download the SDK referred to by it (typical Microsoft obsoletion).

[MartijnKalec]

Okay so a small update on this issue. We were able to figure out what was crashing our command for this specific client. For some reason it was the combination of the client running the Enscape plugin, and also our plugin using Sentry for logging. So once we removed our Sentry code from our plugin, everything was working fine.

So for some reason it seems that the Sentry version we are using, and the perhaps the Sentry version that Enscape is using, are colliding with each other?

Now here is the other issue. We also found out that the IFC-exporter tool in Revit is crashing when our plugin is installed, Exact same crashing behavior as with the other issue. Revit just freezes for a few seconds, and then crashes. I'm not sure yet, but I'm guessing it might be the same type of issue. Are there maybe some best practices about including references to Nuget packages or DLL's we aren't aware of? Or how do you even deal with these types of issues as a developer, when you can't even find out what's crashing the other command/plugin?