July 17, 2026July 17, 2026| Soni YorkSoni York|
Categories:

Question:

When I try to run certain Spitfire functions, I get the following error:

An error occurred in the Microsoft .NET Framework while trying to load assembly id 12345. The server may be running out of resources, or the assembly may not be trusted. Run the query again, or check documentation to see how to solve the assembly trust issues. System.IO.FileLoadException: Could not load file or assembly ‘spitfire.clrsqltools’.

My server is not running out of resources. What does this mean?

Answer:

The message lists two possible causes and in almost every case, it is the second one: the assembly is not trusted. Despite the wording, this is not a resource problem, and running the query again will not clear it.

Spitfire installs a SQL CLR assembly named spitfire.clrsqltools. SQL Server will only load that assembly if it has been given a reason to trust it. Certain changes to your SQL Server–most often a change to which login owns the Spitfire databases–can remove the trust the assembly had been relying on, at which point it stops loading and this error appears.

Please contact Spitfire Support, who can confirm the cause and apply the fix for you. If your organization administers its own SQL Server, your database administrator may instead follow the procedure below.

Solution:

  1. Connect to the SQL Server instance with SQL Management Studio, using a login that is a member of the sysadmin server role.
  2. In a query window against your Spitfire database, run the following to retrieve the assembly’s hash:
    SELECT a.name, a.permission_set_desc, af.name AS file_name,       HASHBYTES(‘SHA2_512‘, af.content) AS hash

    FROM sys.assemblies a

        JOIN sys.assembly_files af ON af.assembly_id = a.assembly_id

    WHERE a.name = ‘spitfire.clrsqltools’;

    –

  3. Copy the value returned in the hash column, and run the following against the master database, substituting that value:
    EXEC sys.sp_add_trusted_assembly     @hash = 0x48E5A0F06FC52E04855E194EFD19A519DB612C1AF26DC187173B488C206633C55888EB8FD7FB1B9DD48362B8EC0B6AD68C6ABB8D59C55A77AF118137F2090A66,

         @description = N’spitfire.clrsqltools ‘;

  4. Retry the Spitfire function that produced the error.

Additional Comments:

The hash shown in step 2 above is an example. Use the hash returned by the query in step 1 on your own server. Do not copy the example value!

The hash identifies one specific build of the assembly file. It is registered per SQL Server instance, not per database, so a single sp_add_trusted_assembly covers every Spitfire database on that instance. If you run Spitfire on more than one SQL Server instance, run the procedure on each.

If the error names an assembly other than spitfire.clrsqltools, repeat step 1 with that assembly’s name in the WHERE clause and register the hash the same way.

If the error persists immediately after step 2, SQL Server may still be holding the earlier result in cache. A sysadmin can clear it with DBCC FREESYSTEMCACHE(‘ALL’), or it will clear on the next restart of the SQL Server service.

Because the hash identifies one specific build, a future Spitfire update that replaces this assembly will require the procedure to be repeated with the new hash. If you see this error shortly after an update. that is the reason.

KBA-01946; Last updated: July 17, 2026 at 11:54 am

Tags: ,

Related Post