Joe*_*sky 9 microsoft-outlook windows-7 microsoft-outlook-2007 dde
运行 Windows 7（RC，64 位）。突然之间，在几个月没有出现问题后，今天点击链接变得非常缓慢。
我在两个地方注意到了这一点。
(1) 单击 Outlook 电子邮件中的超链接以启动 Firefox，大约需要一分钟。单独启动 Firefox 是即时的 - 我有一个 SSD 驱动器和一个非常快的 CPU。(2) 打开 Outlook 电子邮件所附的 Word 文档也需要很长的时间。
这两者的唯一共同点是它们使用 DDE 机制（如果我没记错的话）向应用程序发送 DDE 打开命令。在 Windows XP 下，有时可以通过取消选中文件类型映射中的“使用 DDE”复选框来解决此问题，但是，我在 Windows 7 下找不到任何等效项。
如果 Internet Explorer 以某种方式变慢，那么单击 Office 中的链接也会变慢，即使您不使用 Internet Explorer 作为默认浏览器。所以：检查 Internet Explorer 是否仍然运行良好。
尽管您似乎确信 DDE 是罪魁祸首，但 Office 有一个令人惊讶的奇怪功能：它首先使用 Internet Explorer 组件来查看单击的 URL 是否有效。它不会将自己标识为 Internet Explorer；在访问日志中，您可能会看到：
User Agent: Microsoft Office Existence Discovery
之后，它将生成的 URL传递给默认浏览器。那是：
如果对 URL 的隐藏调用产生了一些重定向，那么默认浏览器甚至不会给出原始 URL，而是重定向的 URL。
如果网站出于某种原因阻止了用户代理“Microsoft Office Existence Discovery”，或者如果您的 Internet Explorer 设置以某种方式阻止了对该网站的正确访问，那么该链接可能看起来已经失效，而实际上使用普通浏览器它可以正常工作。
有没有想过为什么您的浏览器在单击 Office 中的链接时总是将您重定向到某个登录页面？正确：如果 Internet Explorer 未在网站上进行身份验证（尤其是当它不是您的默认浏览器时），那么某些站点可能会响应重定向到登录页面，从而使 Office 忘记您实际单击的 URL...
微软关于 Microsoft Office 存在发现协议博客文章的描述中关于这个有趣的烦人的“Microsoft Office 协议发现”的更多细节：
从 Microsoft Office 2007 中的 URL 位置打开文档时，Office 库可以向 Web 服务器发出 HTTP HEAD 请求以获取打开 URL。此请求与设置为“Microsoft Office Existence Discovery”的用户代理一起发送。此调用是 Office 2007 的新调用。
HEAD 请求的目的是检查 URL 位置上的内容是否作为文档存在，而不仅仅是作为只读会话向下流式传输的临时资源。该调用还将尝试获取 Web 服务器在 HEAD 响应中返回的内容的最后修改时间。
[...]
此调用发生在所有 URL 打开尝试中，即使本身并未请求编辑。因此，额外的 Web 调用（由 Office 应用程序在其网络会话中的进程空间而非单独会话中的 Web 浏览器发起）可能会导致某些用户看到额外的身份验证提示 (401) 或丢失会话状态和不必要的重定向 (302) 到登录页面或其他反馈表单。这是预期的行为。
似乎可以使用注册表禁用此功能；单击后在MS Word 验证链接上查看我的回答。
我越来越近了。
重新启动解决了问题。:) 这并不是一个永久的解决方案......
根据微软程序员 Raymond Chen 的说法，DDE 应该已经过时了，但每个人似乎仍在使用它。
他说，DDE 的问题在于它是协作性的，一个挂起的应用程序可能会导致所有其他应用程序在尝试使用 DDE 时无法正确响应。
就我而言，重新启动解决了问题，因为它关闭了无法正确响应 DDE 消息的应用程序。
在 Windows XP 时间范围内解决此问题的常见解决方案是取消选中文件类型处理程序中的“使用 DDE”框，但该复选框在 Windows 7 中似乎不再存在。即使 DDE 已过时，应用程序仍将其注册在注册表中，以便像 Outlook 2007 这样的愚蠢应用程序仍然使用它来启动超链接。
这个解决方案不是很有用，因为即使是更愚蠢的应用程序，如 Firefox，也非常热衷于使用 DDE，以至于每次启动时都会将自己重新注册为使用 DDE。唯一永久的解决方案是更改注册表中相应键的安全设置，以便 Firefox 无法对其进行写入。
我对这个答案仍然不太满意。