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

Question

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

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

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

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

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

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

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

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

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

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

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

見つけられませんでした

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

Answer 1

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

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

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

~*kn

r

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

!wow64exts.sw

~*kn

r

Answer 2

その問題はあなたのテスト環境で再現するものですか？それとも別のユーザーの環境でのみ発生するものですか？
問題の発生した環境に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が止まるとフリーズしたような状態になる(入力以外のたとえばタイマーとかは届く)。