これは私をしばらく悩ませてきたものであり、これに対する解決策がなければなりません。ShellExecuteを呼び出して外部ファイル（ドキュメント、実行可能ファイル、URLなど）を開くたびに、ShellExecuteが新しいプロセスを生成して戻る前に、プログラムで非常に長いロックアップが発生します。誰かがこれを解決または回避する方法を知っていますか？
編集：そしてタグが示すかもしれないように、これはC++を使用するWin32上にあります。
2715 次
2 に答える
9
何が原因なのかはわかりませんが、（sysinternalで有名な）Mark Russinovichのブログには、このようなものをデバッグする方法を説明している素晴らしいブログがあります。あなたのために見るのに良いものは、遅延したWindows Vistaのファイルを開くダイアログのケースです。彼はプロセスエクスプローラーのみを使用して同様の問題をデバッグしました（ドメインへのアクセスの問題であることが判明しました）。もちろん、通常のWindowsデバッガーを使用して同様のことを行うことができます。
あなたの問題はおそらく彼と同じではありませんが、これらのテクニックを使用すると、問題の原因に近づくのに役立つ場合があります。CreateProcess呼び出しを呼び出してから、いくつかのスタックトレースをキャプチャし、どこでハングしているように見えるかを確認することをお勧めします。
プロセスの起動遅延のケースは、さらに関連性が高い場合があります。
于 2008-10-07T08:19:36.070 に答える
3
マルチスレッドですか？
ShellExecute でファイルを開く際の問題を見てきました。実行可能ファイルではなく、アプリケーション (通常は MS Office) に関連付けられたファイルです。DDE を使用してファイルを開くアプリケーションは、すべてのプログラム (すべてかどうかはわかりませんが...) のすべてのスレッドにメッセージをブロードキャストしました。私は自分のアプリケーションのワーカー スレッドでメッセージを送信していなかったので、シェル (およびファイルのオープン) をしばらくハングアップさせていました。最終的に、メッセージを処理するのを待っている間にタイムアウトになり、アプリケーションが起動してファイルが開きました。
ループで PeekMessage を使用して、そのワーカー スレッドのキュー内のメッセージを削除したことを思い出します。私はいつもこれを別の方法で回避する方法があると思っていましたが、メッセージのターゲットにならないようにスレッドを別の方法で作成することはできますか?
更新 これを行っていたのはスレッドだけではなく、ウィンドウにサービスを提供しているスレッドであったに違いありません。レイモンド(リンク 1)はすべてを知っています(リンク 2) . CoInitialize (シングル スレッド アパートメント) か、MFC の何かがスレッド用の隠しウィンドウを作成したに違いありません。
于 2008-10-07T22:39:29.597 に答える