Mapeamento de usuário SSMS lento para carregar ou não responde

Tenho enfrentado um problema nas versões 14, 18 e 19 do SSMS, em que o carregamento do mapeamento de usuário de qualquer login demora muito para carregar, às vezes até uma hora, ou simplesmente nunca carrega e não responde.

Alguém já passou por isso antes e/ou pode dar alguma orientação sobre como resolver isso?

Eu tentei o seguinte:

• Confirmado que não importa se é um login AD ou login SQL
• Atualizando a versão do SQL Server de 2016 para 2022
• Atualizando a versão do SSMS de 14 para 18 e para 19
• Verificado se há algum bloco SQL (não há nenhum)
• Tentei vários logins diferentes (todos parecem passar por isso)

Existem 25 bancos de dados nesta instância SQL e aproximadamente 50 logins no total.

Infelizmente, esse problema está tornando incrivelmente difícil gerenciar a segurança do usuário e os mapeamentos para bancos de dados sem escrever alguma consulta SQL.

Qualquer apoio ou orientação seria muito apreciado!

Saúde,

EDIT - executei um rastreamento SQL e identifiquei a seguinte consulta como o infrator:

USE [database_name]
SELECT
u.name AS [Name],
CAST(CASE dp.state WHEN N'G' THEN 1 WHEN 'W' THEN 1 ELSE 0 END AS bit) AS [HasDBAccess],
ISNULL(u.default_schema_name,N'') AS [DefaultSchema]
FROM
sys.database_principals AS u
LEFT OUTER JOIN sys.database_permissions AS dp ON dp.grantee_principal_id = u.principal_id 
and dp.type = @_msparam_0
WHERE
(u.type in ('U', 'S', 'G', 'C', 'K' ,'E', 'X'))
and
(ISNULL(suser_sname(u.sid),N'')=@_msparam_1)

Ele é executado após a seleção de um banco de dados para execução e é a quarta consulta a ser executada.

EDIT 2 - É especificamente esta parte que está causando o problema e não tenho ideia do porquê:

    and
(ISNULL(suser_sname(u.sid),N'''')=@_msparam_1)

EDIT 3 - Tenho certeza de que é a função "suser_sname", tendo-a testado em diferentes bancos de dados e logins diferentes. Ele simplesmente trava e nunca é concluído, forçando-me a fechar o SQL.

Qualquer orientação adicional seria apreciada, obrigado.

EDIT 4 - Contexto adicional, desculpas pela omissão original desta informação.

Esse problema está ocorrendo em um domínio separado , nosso ambiente DEV. É onde nossos bancos de dados de produção são restaurados e, como parte dessa restauração, os logins SQL associados são atualizados para funcionar no domínio DEV quando necessário.

Gostaria de saber se talvez alguns logins SQL órfãos estivessem causando esse problema com alguma incompatibilidade do SID em sys.database_principals. Sim, houve alguns logins órfãos, mas após corrigi-los com sp_change_users_login, esse problema ainda ocorre.