C++ 摆脱由ShellExecute造成的邪恶延迟

这件事困扰了我一段时间，必须找到解决办法。每次调用ShellExecute打开外部文件（无论是文档、可执行文件还是URL）时，在ShellExecute生成新进程并返回之前，我的程序都会被长时间锁定。有人知道如何解决这个问题吗

---

<>编辑：正如标签可能指出的，这是在Win32上使用C++。

< P>我不知道是什么引起的，但是Mark Russinovich（SysReinSym的名声）有一个非常棒的博客，他解释了如何调试这些东西。一个很好的例子是，他只使用process explorer调试了一个类似的问题（结果是访问域时出现了问题）。当然，您可以使用常规的windows调试器执行类似的操作

你的问题可能和他的不一样，但是使用这些技术可以帮助你更接近问题的根源。我建议调用

CreateProcess

调用，然后捕获一些堆栈跟踪并查看它似乎挂起的位置

---

可能更适合您。

您是多线程的吗

我看到了使用ShellExecute打开文件时出现的问题。不是可执行文件，而是与应用程序关联的文件-通常是MS Office。使用DDE打开文件的应用程序在所有（我不知道是否都是…）程序中向所有线程广播消息。因为在我的应用程序中，我没有在工作线程中泵送消息，所以我会将shell（以及文件的打开）挂起一段时间。它最终在等待我处理消息时超时，应用程序将启动并打开文件

我记得在循环中使用PeekMessage只是删除该工作线程队列中的消息。我一直认为有一种方法可以通过另一种方式避免这种情况，也许创建线程的方式不同，这样就永远不会成为消息的目标

---

更新

---

这肯定不仅仅是任何线程在做这件事，而是一个服务于窗口的线程雷蒙德无所不知。我打赌是CoInitialize（单线程单元）还是MFC中的某个东西为线程创建了一个隐藏窗口。

因此，这意味着在客户端机器上运行的任何应用程序如果没有线程发送消息，都可能导致这样的延迟？谈论一个无用的API：（更新了更多信息。我在1996-1997年间遇到过这个问题，所以我花了一些时间才真正记住整个问题。在Raymond Chen的帮助下。如果线程有窗口，它必须发送消息-这是windows编程合同的一部分