High Memory Usage in SolarWinds.BusinessLayerHostx64.exe caused by Data Processing Engine startup failure in Solarwinds Self-Hosted Platform

5/11/2026 5:59 PM

5/11/2026 5:59 PM

The SolarWinds Platform Server is experiencing high Memory usage with SolarWinds.BusinessLayerHostx64.exe processes until services had to be restarted.

SolarWinds.Orion.DataProcessingEngine.BusinessLayer plugin was not loading in BusinessLayerHost. Instead, it entered a continuous crash loop with a System.TypeLoadException, and the DPE BusinessLayer log remained empty because the plugin never successfully started or re-registered with Service Directory.

 

From  BusinessLayerHost-SOLARWINDS.ORION.DATAPROCESSINGENGINE.BUSINESSLAYER.DLL.log:

[Scheduler] ERROR SolarWinds.BusinessLayerHost.PluginManager - Plugin "SolarWinds.Orion.DataProcessingEngine.BusinessLayer, Version=2026.1.0.0, Culture=neutral, PublicKeyToken=null" creation failed.

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeLoadException: Method 'GetAllCurrentShortTasks' in type 'SolarWinds.Orion.DataProcessingEngine.DAL.DataProcessorQueueDal' from assembly 'SolarWinds.Orion.DataProcessingEngine.DAL, Version=2026.1.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.

  at SolarWinds.Orion.DataProcessingEngine.DAL.DataAccessLayerInstaller.InstallDalForMain(IContainer container)

  at SolarWinds.Orion.DataProcessingEngine.BusinessLayer.BusinessLayerIocBootstrapper.CreateMainPoolerContainer()

  at SolarWinds.Orion.DataProcessingEngine.BusinessLayer.DpeBusinessLayerPlugin..ctor(IServiceDirectoryClient serviceDirectoryClient)

  --- End of inner exception stack trace ---

 

Network Configuration Manager

The root cause was a stale standalone System.ValueTuple.dll version 4.0.3.0 left in the Windows GAC from an earlier SolarWinds Platform installation.

That stale GAC assembly broke CLR type unification between DPE components using mixed framework dependencies. On the affected server, binding resolved System.ValueTuple 4.0.3.0 from the GAC instead of using the expected type-forwarded behavior, which caused the runtime to treat System.ValueTuple and mscorlib ValueTuple types as different identities. 

Before making the GAC change, consider taking a VM snapshot or equivalent system backup if the customer’s change-control policy allows it. This is a reasonable precaution because the GAC is system-wide, although the targeted action in this case is only the removal of the stale System.ValueTuple 4.0.3.0 entry identified as the conflict.

 

a. Run the attached PowerShell fix script as Administrator on the affected server 

# Verify the stale GAC entry exists first
Get-ChildItem "$env:SystemRoot\Microsoft.NET\assembly\GAC_MSIL\System.ValueTuple" | Select-Object Name


# Expected: you should see BOTH v4.0_4.0.0.0__cc7b13ffcd2ddd51  AND  v4.0_4.0.3.0__cc7b13ffcd2ddd51
# Fix: remove the stale 4.0.3.0 entry (requires .NET SDK gacutil or manual directory deletion as admin)

gacutil /u "System.ValueTuple,Version=4.0.3.0,Culture=neutral,PublicKeyToken=cc7b13ffcd2ddd51"

 

 Manual steps if gacutil is not available:

   Temporarily Disable HA pool if there's any. https://documentation.solarwinds.com/en/success_center/orionplatform/content/ha-manage-pools.htm

1. Stop SolarWinds services (Orion Module Engine + Information Service)

2. Delete folder: C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.ValueTuple\v4.0_4.0.3.0__cc7b13ffcd2ddd51\

3. Restart SolarWinds services

    Re-enable HA pool.

b. Re-run the query to confirm removal:

Get-ChildItem "$env:SystemRoot\Microsoft.NET\assembly\GAC_MSIL\System.ValueTuple" | Select-Object Name

 

Temporary Mitigation (while arranging fix)

To stop the Out of memory accumulation, exclude the DPE plugin from loading by adding it to ExcludedPlugins.xml in the Orion directory:

<plugin name="SolarWinds.Orion.DataProcessingEngine.BusinessLayer" />

Note: this will disable DPE functionality (data processing engine features) but will stop the memory leak immediately.