SQL Server 2022: Memory Leak with context connection=true in SQLCLR vs Stable Behavior Using External SqlConnection

Hi Microsoft team and community,

I've been stress testing a SQL Server 2022 Developer Edition installation on Windows Server 2025 Datacenter using SQLCLR UDFs that interact with an unmanaged C DLL via DllImport. The workload involves 400+ concurrent sessions using sqlcmd, and over a 10+ hour period, I consistently observe aggressive memory growth in MEMOBJ_GLOBALPMO under MEMORYCLERK_SQLGENERAL, eventually leading to AppDomain unloads and “insufficient memory in default domain pool” errors.

Here’s where it gets interesting:

• My SQLCLR code uses new SqlConnection("context connection=true") to run queries like SELECT SUSER_NAME(); and retrieve the caller’s login.
• This connection works as expected in terms of identity — SUSER_NAME() returns the actual SQL login.
• However, it appears to be causing unmanaged memory buildup. The same workload on SQL Server 2019 with Windows Server 2019 does not exhibit this issue.
• As a test, I replaced the context connection with new SqlConnection("Server=localhost;Integrated Security=true"), and memory usage remained stable over time - no leaks.
• But in this external connection case, SUSER_NAME() returns NT Service\MSSQLSERVER, not the actual user identity.

I reviewed GitHub Issue #2348, which appears to describe the same issue. The proposed workaround there is to switch to an external connection, which stops the leak, but this sacrifices access to the true caller login.

My Questions:

1. Is there an official Microsoft explanation for the memory accumulation behavior in context connections under SQL Server 2022?
2. Is there a recommended way to avoid the leak while still retrieving the accurate SQL login identity inside SQLCLR code?
3. Is this behavior new to SQL Server 2022 or influenced by changes in Windows Server 2025?
4. Are there any patches, trace flags, or configuration options that mitigate this issue?

Thanks for any insights or suggestions — we’re trying to balance stability and security context in a production-grade workload and would love guidance on best practices.

Updates (30-07-2025):

• We’ve conducted further testing on the scenario using SQL Server 2025 Enterprise Evaluation (Preview) edition and did not encounter the issue.
• Additionally, we installed Cumulative Update 20 (link) on SQL Server 2022 Developer Edition and retested the scenario. The issue was no longer observed there as well.
• Based on these findings, it appears that Microsoft may have addressed this behavior in one of the recent cumulative updates for SQL Server 2022.