ArcGIS Pro 3.3 Crashes when with various GP Tools or map interaction

Justin_ODell

My ArcGIS Pro 3.3 (in Windows 11) crashes when running the Delete GP Tool and specifying a path, while a custom Add-In is running.  It works without the Add-In.  I attempted to replicate the behavior with an Esri Sample Add-In, and was able to cause a somewhat similar crash behavior with WorkingWithQueryDefinitionFilters adding a layer to the map.

Does this happen for anyone else?  Any idea what causes it?  Are there any related known bugs? 
My current guess is maybe it relates to the ArcGIS.Desktop.Mapping.Events subscriptions.

Step to replicate:

1. Build the WorkingWithQueryDefinitionFilters Add-In (I'm using Visual Studio Professional 2022)
   https://github.com/Esri/arcgis-pro-sdk-community-samples/tree/master/Map-Exploration/WorkingWithQueryDefinitionFilters
2. Open ArcGIS Pro 3.3 with the WorkingWithQueryDefinitionFilters Add-In ‘installed’
3. Add a geodatabase feature class to a new map
4. Right click the layer in the Contents dockpane > Click Definition Query Filters
5. Drag and drop a layer onto the map (from Catalog dockpane)
   (or create a new feature class that gets automatically added to the map)
6. Pro crashes

For reference, I haven't had any problems with the custom Add-In in ArcGIS Pro 3.2.  I've had similar problems with shapefiles in 3.3. The crash doesn't happen before the Definition Query Filters dockpane is opened, but will happen if it's opened then closed.

The following error was in the .dmp file after the custom Add-In crash: "FrameworkApplication.CreateInstance error": Missing class or assembly name: esri_mapping_snapChipToggleButton

 

One related side question: I noticed that specifying a path in the Delete GP Tool no longer removes map layers from the map that have that path as a data source. Is that expected behavior?  Does anyone know when (which version) that change occurred? 

Thanks much!

Wolf

I tried the sample snippet you referred to above and did notice an issue with the sample.  If you look at the "private void GetMapMembers(MapView mapView)" method, you can see that this method is always running on the thread it is called from.  Unfortunately, when the 'query definition' custom dockpane is open and a new featureclass or table is added to the current map, this method is called from a background thread which in turn is throwing an exception.   So to correct this i made the following changes to the sample:

    private void GetMapMembers(MapView mapView)
    {
      RunOnUiThread(() =>
      {
        MapMembers.Clear();
        if (mapView != null)
        {
          var tocLayers = mapView.Map.GetLayersAsFlattenedList().OfType<BasicFeatureLayer>().ToList();
          var tocTables = mapView.Map.StandaloneTables.ToList();
          if (tocLayers.Count > 0 || tocTables.Count > 0)
          {
            tocLayers.ForEach(x => _mapMembers.Add(x));
            tocTables.ForEach(t => _mapMembers.Add(t));
            var selectedMapMember = GetSelectedMapMemberInTOC();
            if (selectedMapMember != null) //mapmember has been selected
              SelectedMapMember = selectedMapMember; //Show that map member's filters
            else
              SelectedMapMember = MapMembers[0]; //default. Nothing selected in TOC
          }
          //If no feature layers, show empty dockpanes(DockpaneVisibility)
          DockpaneVisibility = MapMembers.Count == 0 ? Visibility.Hidden : Visibility.Visible;
        }
      });
    }

And here are the supporting functions:

    #region Threading Utilities

    /// <summary>
    /// utility function to enable an action to run on the UI thread (if not already)
    /// </summary>
    /// <param name="action">the action to execute</param>
    /// <returns></returns>
    internal static Task RunOnUiThread(Action action)
    {
      if (OnUIThread)
      {
        action();
        return Task.FromResult(0);
      }
      else
        return Task.Factory.StartNew(action, System.Threading.CancellationToken.None, TaskCreationOptions.None, QueuedTask.UIScheduler);
    }

    /// <summary>
    /// determines if the application is currently on the UI thread
    /// </summary>
    private static bool OnUIThread
    {
      get
      {
        if (FrameworkApplication.TestMode)
          return QueuedTask.OnWorker;
        else
          return System.Windows.Application.Current.Dispatcher.CheckAccess();
      }
    }

    #endregion

I will try drag and drop and some other test cases next, but in general I would recommend embedding all custom code in try {} catch {} to prevent crashes that are caused by uncaught exceptions with no error message.