Experiencing CLR error on SQL Azure DB

While Azure SQL Database (not the new Managed Instance) does not support custom SQLCLR Assemblies (i.e. the "CLR enabled" server-level configuration option), CLR is still used internally for the following features:

1. CLR datatypes:
   • Geometry
   • Geography
   • Hierarchyid
2. Built-in functions:
   • introduced in SQL Server 2012:
     • FORMAT
     • PARSE
     • TRY_PARSE
   • introduced in SQL Server 2016:
     • AT TIME ZONE
     • COMPRESS
     • DECOMPRESS
     • sys.time_zone_info
   • maybe others
3. SSIS (Fuzzy Lookup / sp_FuzzyLookupTableMaintenanceInvoke, etc)
4. Change Data Capture (CDC)
5. Replication
6. Master Data Services
7. Policy Based Managemen (PBM; originally named "Dynamic Management Framework (DMF)" )
8. External Tables (including External Data Sources and possibly External File Formats): This functionality is new as of SQL Server 2016, and this functionality using CLR internally has been mentioned in other answers here by Joe and Henrik. Both Joe and Henrik indicate being told by Microsoft that External Tables rely upon CLR, and while I have not been able to confirm this directly (by seeing the system App Domain get created when using any of this functionality), I was at least able to confirm that when "Lightweight Pooling" mode is enabled, all 3 of these components fail with the following error:

   Msg 7432, Level 16, State 0, Line XXXXX
   Heterogeneous queries and use of OLEDB providers are not supported in fiber mode.

9. maybe others

Of course, this does not point to what would be hogging memory. But it should help identify the affected area(s).

Using Azure SQL DB (not managed instance) and it most definitely uses the CLR for things like geo-spatial and AT TIME ZONE

I have been having this same problem and could not find a solution. Working with MS support and this is what we came up with as a possible resolution - just did it 10 minutes ago, but seems legit:

The hypothesis is that the CLR errors we have been experiencing are due to the use of external tables which leverage the CLR (via elastic search). The external table implementation has been corrupting CLR threads and is under investigation by Microsoft.

I was only using external tables for some operational maintenance, so I was able to drop those. I then had to reset the databases to reset all the threads. There is an undocumented DBCC command to do this:

dbcc stackdump('')

This takes down your database and then it fails over to another redundant server. When I ran that, there was about a 5 second outage

As you can read on this documentation, CLR is not supported on Azure SQL Database. However, the new Azure Managed Instance does support CLR.