VCで作成したソフトがWin32u.dllの処理でAppHangとなりダウンすることがある

TN 0 評価のポイント
2025-12-01T11:16:35.9+00:00

VCで作成したソフトが、AppHang(1002)となってダウンするのですが、

コンパイラをVC6->VS2017に変更する前は発生していませんでした

PC側でメモリ異常や不足といったHW的な問題はないと思います

ダウンは不定期に発生します

Dumpが出力されているケースがあったので、解析してみましたが、

Win32u.dllのNtUserGetMessageのところでした

32Bitアプリなので、Wow64SystemServiceCallをしているようですが

応答が返ってこずにHang扱いになっていようでした

気になるのが、AppHangになる直前にVNCだと思うのですが、

"tvnserver"のDisconnectログ(257)が記録されています

この辺りで検索もしてみたのですが、問題になっているような事例は

見つけられませんでした

こういう場合、どういう風に原因を追究すればいいでしょうか？

開発者テクノロジ | C++
開発者テクノロジ | C++

C プログラミング言語の拡張機能として作成された高レベルの汎用プログラミング言語。低レベルのメモリ操作機能に加えて、オブジェクト指向、汎用、関数型の機能を備えています。

0 件のコメント

2 件の回答

並べ替え方法: 古い順
最も役に立つ 新しい順 古い順
  1. gekka 14,551 評価のポイント MVP ボランティア モデレーター
    2025-12-02T04:05:14.69+00:00

    その問題はあなたのテスト環境で再現するものですか？それとも別のユーザーの環境でのみ発生するものですか？
    問題の発生した環境にVC6でコンパイルしたバイナリ(以下A)とVS2017でコンパイルしたバイナリ(以下B)の両方をためすと(B)でのみ発生しているのですか？
    それとも単純に(B)をリリースした以降に問題が発生するようになっただけですか？

    NtUserGetMessageは公開されていないWindowsの内部APIだがGetMessageから呼び出される。 おそらくアプリケーションはGetMessageでメッセージキューから取り出そうとしているが、GetMessageはメッセージがキューに無ければメッセージが追加されるまでブロックされるので、そこで止まっただけの可能性。なのでNtUserGetMessagが問題なのではなく、メッセージが送られてこなくなったことを調べる必要があるでしょう。

    とりあえずGetMessageを使わずに、MsgWaitForMultipleObjectsとPeekMessageを組み合わせて、同時にSetTimerをMsgWaitForMultipleObjectsよりも短い周期で動かす。
    WM_TIMERすら届かないならメッセージが止まっているので、MsgWaitForMultipleObjectsタイムアウトしたらシステムの状態をログにとって見るぐらい。。

    "tvnserver"とは何ですか？
    tvnserverというのがTightVNCだと仮定すると、TightVNCであることを利用者が認識していない場合、その環境はリモートから侵入されています。

    TightVNCであることを利用者が認識している場合、VNCを通じてリモートでそのデスクトップ環境を操作していると推定。
    VNCの通信が切れる->デスクトップセッションが止まる->ユーザーセッションが止まる->デスクトップメッセージがなくなる->メッセージキューに何も送られてこなくなる->アプリがとまったように見える。 VNCサーバーがマウスやキーボードやIMEの状態を監視およびクライアントからの入力を挿入するのにSetWindowsHookExなどでフックをしている場合に、そのフックが正しく動作しなくなるとメッセージがアプリケーションに届かなくなりフリーズしたようになる。
    VNCがAttachThreadInputでアプリケーションに入力を挿入しようとしているときにVNCが止まるとフリーズしたような状態になる(入力以外のたとえばタイマーとかは届く)。

    この回答は役に立ちましたか?

  2. 人間 350 評価のポイント
    2025-12-02T06:30:34.0533333+00:00

    x64 環境で採取された 32 ビット アプリのダンプでは、デフォルトでは x64 モードになってしまうので、"!wow64exts.sw" コマンドで明示的に x86 モードに切り替える必要があります。

    下記コマンドを実行すると、x64/x86 双方の全スレッドのコールスタックが確認できます。

    .echo !!!! x64 callstack & registers !!!!

~*kn

r

.echo !!!! x86 callstack & registers !!!!

!wow64exts.sw

~*kn

r

    この回答は役に立ちましたか?

    0 件のコメント

お客様の回答

質問作成者は回答に "承認済み"、モデレーターは "推奨" とマークできます。これにより、ユーザーは作成者の問題が回答によって解決したことを把握できます。