none
「プログラムの応答を待ちます」のあるダイアログがシステムから表示される条件について  RRS feed

  • 質問

  • アプリケーションを使っており,待ち状態が続くと以下のようなダイアログが表示されることがありませす。

    ==

    (アプリ名)は応答していません

    Windowsによりオンラインで解決策を確認できます。プログラムを閉じると、情報が失われる可能性があります。

    →解決策を確認してプログラムを終了します

    →プログラムを終了します

    →プログラムの応答を待ちます

    ==

    【質問】

    このダイアログが表示されるのは,プログラム的にはどのような状況なのでしょうか?

    私の作成しているアプリである操作をした際に、上記のダイアログが表示されるのですが、

    同じ操作をしてもより高スペックなPCでは表示されないです。

    関数の実行に時間が掛かる操作をした場合であることに間違いはないですが、

    確認したいのは、例えば,システム側に処理が何秒間戻らないとこのダイアログが表示される、

    と言った内容です。

    ご存知の方がいらっしゃいましたら、教えていただけますでしょうか?

    以上よろしくお願いします。

    2017年2月17日 7:46

回答

  • 例えば、プログラムで無限ループなどでメッセージを処理しない状態が続いた場合に、応答なしとOSに判断されるようです。

    Windowsが、応答なしと判断するまでのデフォルトの秒数はわかりませんが、「応答なし」状態と判断されるまでの時間はレジストリで設定を変更できるようです。

    レジストリの

    HKEY_CURRENT_USER\Control Panel\Desktop

    にHungAppTimeoutがなければ文字列値で作成し、ミリ秒単位で指定します。

    また、アプリケーション側でDisableProcessWindowsGhosting関数を呼び出すことによって、応答なしの表示に移行しないようにもできるようです。

    https://social.technet.microsoft.com/Forums/ja-JP/3edbe74c-3eda-45f0-bb9b-41fb6b4aff94

    #デフォルトの値は上記の投稿によると5000(5秒)のようですね。
    2017年2月17日 8:00
  • OS 的には、Windows Message に対する応答が滞った状態のことで、表示されるまでの時間については HKEY_CURRENT_USER\Control Panel\Desktop\HungAppTimeout ですかね。

    初期値=なし、既定値=5000ミリ秒だったはず。

    2017年2月17日 8:08
  • このダイアログが表示されるのは,プログラム的にはどのような状況なのでしょうか?

    使用されている言語がわからないのですが、どの言語であれウィンドウ プロシージャのボトルネックを回避するで説明されているように

    ウィンドウ プロシージャの実行中は、同じスレッド上で作成されたウィンドウに対するその他のメッセージはブロックされます。このため、ウィンドウ プロシージャ内の処理が長時間になってしまうことを避けなければなりません。たとえばプログラムが TCP 接続を開いていてサーバー応答を無期限に待機する場合、これがウィンドウ プロシージャ内で実行されていると、要求が完了するまで UI は応答せず、待機している間ウィンドウはマウスやキーボードの入力、ウィンドウの再描画、閉じる動作などを処理できません。

    という設計がなされていないことが原因です。

    2017年2月17日 8:11
  • あと、XP 以降では「応答なし」の表示のためのゴーストウィンドウが表示され、元のウィンドウがバックグラウンドに回されますが、それを抑制する場合は、DisableProcessWindowsGhosting を呼び出します。

    実際にはこうした抑制を行うのではなく、長時間応答がなくなってしまわぬように非同期処理として実装するのが望ましいのですけれどね。

    2017年2月17日 8:15
  • アプリケーションが長時間(HungAppTimeout[ms]以上)メッセージキューからメッセージの取得を
    行っていないと、システムはそのアプリがハングアップしていると判定するようです。
    この様な状態は、メインスレッドが直接いわゆるビックジョブを行う等の実装をしていると、たやすく発生するようです。
    ビックジョブは子スレッド化してメインスレッドから追い出し、
    メインスレッドが常にメッセージの取得を行える様に配慮すれば良いのではないでしょうか。
    2017年2月17日 8:36

すべての返信

  • 例えば、プログラムで無限ループなどでメッセージを処理しない状態が続いた場合に、応答なしとOSに判断されるようです。

    Windowsが、応答なしと判断するまでのデフォルトの秒数はわかりませんが、「応答なし」状態と判断されるまでの時間はレジストリで設定を変更できるようです。

    レジストリの

    HKEY_CURRENT_USER\Control Panel\Desktop

    にHungAppTimeoutがなければ文字列値で作成し、ミリ秒単位で指定します。

    また、アプリケーション側でDisableProcessWindowsGhosting関数を呼び出すことによって、応答なしの表示に移行しないようにもできるようです。

    https://social.technet.microsoft.com/Forums/ja-JP/3edbe74c-3eda-45f0-bb9b-41fb6b4aff94

    #デフォルトの値は上記の投稿によると5000(5秒)のようですね。
    2017年2月17日 8:00
  • OS 的には、Windows Message に対する応答が滞った状態のことで、表示されるまでの時間については HKEY_CURRENT_USER\Control Panel\Desktop\HungAppTimeout ですかね。

    初期値=なし、既定値=5000ミリ秒だったはず。

    2017年2月17日 8:08
  • このダイアログが表示されるのは,プログラム的にはどのような状況なのでしょうか?

    使用されている言語がわからないのですが、どの言語であれウィンドウ プロシージャのボトルネックを回避するで説明されているように

    ウィンドウ プロシージャの実行中は、同じスレッド上で作成されたウィンドウに対するその他のメッセージはブロックされます。このため、ウィンドウ プロシージャ内の処理が長時間になってしまうことを避けなければなりません。たとえばプログラムが TCP 接続を開いていてサーバー応答を無期限に待機する場合、これがウィンドウ プロシージャ内で実行されていると、要求が完了するまで UI は応答せず、待機している間ウィンドウはマウスやキーボードの入力、ウィンドウの再描画、閉じる動作などを処理できません。

    という設計がなされていないことが原因です。

    2017年2月17日 8:11
  • あと、XP 以降では「応答なし」の表示のためのゴーストウィンドウが表示され、元のウィンドウがバックグラウンドに回されますが、それを抑制する場合は、DisableProcessWindowsGhosting を呼び出します。

    実際にはこうした抑制を行うのではなく、長時間応答がなくなってしまわぬように非同期処理として実装するのが望ましいのですけれどね。

    2017年2月17日 8:15
  • アプリケーションが長時間(HungAppTimeout[ms]以上)メッセージキューからメッセージの取得を
    行っていないと、システムはそのアプリがハングアップしていると判定するようです。
    この様な状態は、メインスレッドが直接いわゆるビックジョブを行う等の実装をしていると、たやすく発生するようです。
    ビックジョブは子スレッド化してメインスレッドから追い出し、
    メインスレッドが常にメッセージの取得を行える様に配慮すれば良いのではないでしょうか。
    2017年2月17日 8:36
  • ktakeuti さん、こんにちは。
    フォーラム オペレーターの立花楓です。

    ktakeuti さんがこちらの質問を投稿されてから少し時間が経ちましたが、問題は無事解決しましたでしょうか。

    お寄せいただいた数々の情報を他の方々にも活用していただきたいと思いましたので、ひとまず、私の方で回答マークを付けさせていただきました。
    ※問題が未解決である場合は、回答マークを外していただくことも可能です。

    フォーラムのヘルプ
    https://social.technet.microsoft.com/Forums/ja-JP/e164507c-7d3b-47d7-8be8-dd383e61507c?forum=announceja

    その後わかったことなどがあれば、ご返信いただければと思います。

    よろしくお願いします。


    MSDN/TechNet Community Support 立花楓

    2017年2月27日 4:45
    モデレータ