针对你遇到的这个棘手问题，结合你只有SSMS权限、完全无法修改代码的约束，我给你整理了几个环境层面的排查方向，全部都是可以直接在SSMS里执行SQL验证的：

一、先挖底层日志找更具体的错误线索 #

虽然sysmail_allitems里没记录，但msdb的这两个日志表大概率藏着比SSMS弹出的错误更细节的信息：

-- 查看数据库邮件运行日志，按时间倒序取最新的
SELECT log_date, error_number, message, description 
FROM msdb.dbo.sysmail_log 
ORDER BY log_date DESC;

-- 查看数据库邮件事件日志，找初始化失败的具体原因
SELECT log_date, event_type, message 
FROM msdb.dbo.sysmail_event_log 
ORDER BY log_date DESC;

比如日志里可能会明确提到“tempdb权限不足”“无法访问sqlcmd组件”这类具体指向，比笼统的-2147417850有用多了。

二、对比测试与生产的邮件配置文件权限 #

sp_send_dbmail用@query时，执行上下文的权限是核心，先检查你用到的standard配置文件的授权情况：

SELECT 
    p.profile_name,
    COALESCE(u.name, '所有用户') AS authorized_principal,
    u.type_desc AS principal_type,
    pp.is_default
FROM msdb.dbo.sysmail_profile p
LEFT JOIN msdb.dbo.sysmail_principalprofile pp 
    ON p.profile_id = pp.profile_id
LEFT JOIN msdb.sys.database_principals u 
    ON pp.principal_sid = u.sid
WHERE p.name = 'standard';

对比测试环境的结果，看生产环境是否给standard配置文件加了额外的权限限制——比如测试环境允许所有用户访问，但生产环境只授权了特定主体，而你的AD用户刚好不在里面。

三、验证@query执行的上下文权限 #

@query参数的执行依赖当前用户（或数据库邮件代理账户）的权限，你可以做两个针对性测试：

1. 模拟数据库邮件代理账户执行脚本

sp_send_dbmail执行@query时，默认会用SQL Server代理的服务账户上下文，你可以先找到这个账户，再模拟它跑测试脚本：

-- 先找到SQL Server代理的服务账户
SELECT name FROM msdb.sys.server_principals 
WHERE name LIKE 'NT SERVICE\SQLSERVERAGENT' OR name LIKE '%Mail%Proxy%';

-- 模拟该账户执行你的测试脚本
EXECUTE AS LOGIN = 'NT SERVICE\SQLSERVERAGENT'; -- 替换成上面查到的实际账户名
GO
declare @profil varchar(30)
declare @recipients varchar(2000)
declare @subject varchar(2000)
declare @body varchar(8000)
declare @query varchar(2000)
set @profil='standard'
set @recipients='test.testmail@company.com'
set @subject='Test Mail SP'
set @body='Test '
set @query='SELECT 1;'

EXEC msdb.dbo.sp_send_dbmail @profile_name=@profil,@recipients=@recipients,@subject=@subject,@body=@body,@query=@query;
GO
REVERT;

如果模拟代理账户能成功发送邮件，说明问题出在你的AD用户在生产环境缺少某些关键权限（比如tempdb的对象创建权限）。

2. 检查当前用户在tempdb的权限

sp_send_dbmail执行@query时，会在tempdb创建临时对象来处理查询结果，你可以检查自己的AD用户是否有足够权限：

USE tempdb;
SELECT 
    permission_name,
    state_desc
FROM sys.database_permissions dp
JOIN sys.server_principals sp 
    ON dp.grantee_principal_id = sp.principal_id
WHERE sp.name = 'DOMAIN\你的AD账号'; -- 替换成你的实际账号，比如COMPANY\ZhangSan

对比测试环境的结果，生产环境如果缺失CREATE TABLE、CREATE PROCEDURE这类基础权限，大概率会导致sqlcmd初始化失败。

四、对比SQL Server的核心配置参数 #

有些高级配置可能影响sqlcmd的初始化，你可以查这些参数并和测试环境对比：

-- 查看高级配置项的当前值
SELECT name, value, value_in_use, description
FROM sys.configurations
WHERE name IN ('show advanced options', 'xp_cmdshell', 'Ole Automation Procedures');

注意：不要随便修改这些参数，只需要对比测试环境的配置值——比如测试环境Ole Automation Procedures是启用的，而生产环境禁用了，就可能是问题根源。

五、检查数据库邮件的系统配置 #

对比测试与生产环境的数据库邮件核心配置，看是否有参数差异导致初始化失败：

SELECT name, value, description
FROM msdb.dbo.sysmail_configuration
ORDER BY name;

重点关注AccountRetryAttempts、AccountRetryDelay、DatabaseMailExeMinimumLifeTime这些和邮件执行生命周期相关的参数，生产环境如果配置了过短的生命周期，可能会导致sqlcmd还没初始化完成就被终止。

最后补充个小提示 #

错误码-2147417850对应的是RPC_E_WRONG_THREAD，通常和线程初始化、权限上下文、临时资源访问有关。结合你的场景，最可能的原因是tempdb权限不足、邮件配置文件的权限限制或者SQL Server代理账户的权限缺失，建议你先从日志和权限排查入手，应该能快速找到突破口。如果有新的日志信息，也可以补充出来，大家再一起分析！