我也遇到了同样的问题：在使用Object Explorer访问远程服务器时，SSMS会无限期地挂起。Windows系统事件日志将显示DCOM错误10009（“DCOM无法使用任何配置的协议与计算机MACHINE_NAME通信。”）。
解决方案是清除我的个人资料中MRU历史记录和其他设置。方法如下：
你会发现你的MRU列表已经被清除了。此时你可以重新输入你的凭据并像往常一样使用SSMS。
如果一切正常，你可以删除重命名的文件夹。否则，删除新创建的“11.0”文件夹，并将原始文件夹重新命名为“11.0”。
我不知道是否真的是MRU列表导致了这个问题，还是其他个人资料数据导致的。
我们发现SSMS试图通过端口135建立DCOM连接到SQL Server（可能是为了SSIS、T-SQL调试或其他操作）。我们的防火墙配置为阻止端口135。通过在防火墙中开放该端口，我们能够使用SSMS（这也就是为什么它对本地数据库有效而对远程数据库无效的原因）。不幸的是，一个开放的端口135会引来很多攻击，所以这对我们来说不是一个可行的解决方案。
关闭所有数据库的自动关闭功能。这对我来说效果很好！
每次扩展或刷新数据库列表时，服务器都会唤醒数据库，导致系统卡顿。
只需运行以下命令查找所有开启自动关闭功能的数据库：
SELECT name, is_auto_close_on
FROM master.sys.databases AS dtb
WHERE is_auto_close_on = 1
ORDER BY name
这种方法即使主机创建的登录将您路由到tempdb或其他默认情况下，管理工作室仍将使您处于您的数据库上下文中。
现在我看到您在谈论对象资源管理器节点，而不是我错误地解释的“使用数据库”下拉菜单。尝试的方式可能是突出显示数据库节点（不要展开它）并单击F7（对象资源管理器详细信息）。如果这对您有用，则可以通过此方法导航层次结构，并且作为奖励，您可以在此处显示许多实体属性并进行多选，这两个内容在对象资源管理器中无法控制。
如果这没有帮助，则您的主机应该比他们表现出的更好地帮助您。如果支持SSMS 2012，则他们应该能够在SSMS 2012中测试并确认或否认它是否能够复制。如果不支持，则我认为您的补救措施是安装SSMS 2008（它们可以共存）并将其用于管理此特定服务器。
当然，您可以使用目录视图和/或DMV做到几乎所有您可以在对象资源管理器中做的事情（以及许多您无法做到的事情）。因此，在确定要做什么之前，您可能需要回顾（或与我们分享）您正在使用对象资源管理器的确切内容-如果有一种方法可以不使用对象资源管理器来完成它，则您可能会喜欢解决方法而不是拥有两个版本的工具（因为2012 SSMS中的改进绝对没有任何关系与对象资源管理器）。
SqlStudio.bin从旧的配置文件文件夹复制到新的配置文件文件夹中（旧的配置文件文件夹可以随后删除）我有一些SQL Server，从2000年到2012年，可以在我的桌面上通过SMSS访问它们。问题的出现频率不同，看起来是这样的：当我折叠对象资源管理器中的服务器时，SMSS会冻结。
查看相关服务器上的活动监视器后，我发现一个进程在master数据库中执行以下查询，主机为我的桌面：
SELECT dtb.name AS [Name] FROM master.dbo.sysdatabases AS dtb ORDER BY [Name] ASC SMSS
终止进程可以解决SMSS的冻结。
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM master.sys.databases AS dtb
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM
master.sys.databases AS dtb
Where name <> 'StuckDB' ORDER BY [Name] ASC
以下是对我有效的操作步骤： 打开SSMS 点击连接到对象资源管理器按钮 在连接到服务器对话框中展开选项 >> 点击重置所有 完成！
我通过将默认数据库更改回主数据库来解决了这个问题。