2

要するに が欲しいという問題CreateProcessがありStartProcessます。問題は、プロセスを作成CreateProcessしたときに true が返されたにもかかわらず、システムがプロセスを開始できなかった状況があることです。たとえば、起動対象のインポートの 1 つが解決できない場合でも成功します。CreateProcess

このプロセスを開始することによって、私が何を達成したいのかに応じて、おそらく多くの提案が可能です。ただし、このプロセスを開始することによって特に何かを達成することを望んでいないため、これらの提案はどれも役に立たない可能性が高いと思います.

WaitForSingleObject一例として、プロセス ハンドルに対してを呼び出してからGetExitCodeProcess. しかし、プロセスが永遠に残る可能性があるため、プロセスが終了するのが待ちきれません。

もう 1 つの提案例はWaitForInputIdle、 を呼び出すことです。これは、起動対象が作成することを合理的に期待できるウィンドウを使用して、起動対象と通信したい場合にうまく機能します。しかし、私はそれを望んでおらず、合理的に期待することはできません. 私が知っている限りでは、起動対象はコンソール プロセスであり、メッセージ キューはありません。同様に、(ヒューリスティックな意図で) 見つけ出すのを待つ余裕もありません。

実際、ランチャーについては何も推測できません。

ここで私がどのように考えているかをよりよく理解するために、この問題の裏側を見てみましょう。プロセスが開始されない場合、ユーザーにアドバイスする方法を示すエラー コードが必要です。インポートがすべて解決され、メイン スレッドが CRT スタートアップ コード (または同等のコード) にジャンプしようとしていることを認識し、返されたエラー コードがERROR_SUCCESS. しかし、私は実際にはランチャーに興味がなく、ランチャーで優れたユーザー エクスペリエンスを提供したいと思っているだけです。

ああ、もう 1 つ: これをシンプルにしたいのです。デバッガーを書きたくありません。:-)

アイデア？

4

2 に答える 2

1

One example suggestion might be to call WaitForSingleObject against the process handle and then GetExitCodeProcess. But I can't wait for the process to exit because it might stick around forever.

Why don't you wait for the process handle for some reasonable time. If the timer expires before the handle is signaled, you can presume the process is up and running. If the handle is signaled first, and the exit code is good, then you can presume it ran and completed successfully.

In case you haven't seen it, the CreateProcess vs started problem was mentioned in Raymond Chen's blog.

Honestly, if you're not willing to accept heuristics (like, "it hasn't ended with a failure code after three seconds, therefore we assume all is well") then you're going to have to write a 'debugger', by which I mean inspect the internals of the launched process.

于 2011-02-15T06:46:45.703 に答える
0

この質問は長い間答えが出ていないので、答えは「できません」と結論付けても問題ないと思います。

于 2011-08-06T22:24:53.863 に答える