none
MessageBoxでクラッシュ RRS feed

  • 質問

  • はじめまして。

    Win7 Pro 64bit上でVS2012を使ってWin32アプリケーションを作成しています。

    特定のマシン上でデバッグを行うと、MessageBox()の先で以下のような現象が発生するのですが、

    原因をご存知の方がいらっしゃれば解決策を教えて頂きたく投稿しました。

    -- 例外発生時のメッセージ --

    xx.exe の 0x6dfc85a8 (IMJPTIP.DLL) で初回の例外が発生しました: 0xC0000005: 場所 0xfeeefeee を読み込み中にアクセス違反が発生しました。


     *** An Access Violation occurred in "xxx\Release\xx.exe" :

    The instruction at 6DFC85A8 tried to read from an invalid address, FEEEFEEE

     *** enter .exr 0BF5D6D8 for the exception record
     ***  enter .cxr 0BF5D728 for the context
     *** then kb to get the faulting stack

    Windows によって xx.exe でブレークポイントが発生しました。

    ヒープが壊れていることが原因として考えられます。xx.exe または読み込まれた DLL にバグがあります。

    あるいは、xx.exe がフォーカスを持っているときに、ユーザーが F12 キーを押したことが原因として考えられます。

    可能であれば、出力ウィンドウに詳細な診断情報が表示されます。

    -- ここまで --

    -- コールスタックの一部 --

      ntdll.dll!_RtlUnhandledExceptionFilter2@8()  + 0x2ab バイト 
      ntdll.dll!_RtlUnhandledExceptionFilter@4()  + 0x12 バイト 
      msctf.dll!CicExceptionFilter()  + 0xe バイト 
      msctf.dll!CThreadInputMgr::_ActivateTip()  + 0x1bc91 バイト 
      msvcrt.dll!@_EH4_CallFilterFunc@8()  + 0x12 バイト 
      ntdll.dll!ExecuteHandler2@20()  + 0x26 バイト 
      ntdll.dll!ExecuteHandler@20()  + 0x24 バイト 
      ntdll.dll!_RtlDispatchException@8()  + 0xd3 バイト 
      ntdll.dll!_KiUserExceptionDispatcher@8()  + 0xf バイト 
      IMJPTIP.DLL!Tiputil::TipHotkeyItemCollection::CreateItem()  + 0xf バイト 
      IMJPTIP.DLL!CTipFnPropertyUI::UpdateButton()  + 0x2d バイト 
      IMJPTIP.DLL!CTipFnPropertyUI::OnFocusChanged()  + 0xd バイト 
      IMJPTIP.DLL!CTipFnPropertyUI::_OnFocusChanged()  + 0x17 バイト 
      IMJPTIP.DLL!Tiputil::CTipContextFocusSink::OnFocusChanged()  + 0x1a バイト 
      IMETIP.DLL!Tsfutil::TfRangeBackup::Restore()  + 0x18 バイト 
      IMETIP.DLL!CTipContextEditorMgr::CallOnFocusChanged()  + 0x5d バイト 
      IMETIP.DLL!CTipContextEditorMgr::SetContextFocus()  + 0xb2 バイト 
      IMETIP.DLL!CTipContextEditorMgr::OnProfileMgrEvent()  + 0x110 バイト 
      IMETIP.DLL!CTipContextEditorMgr::_OnProfileMgrEvent()  + 0x17 バイト 
      IMETIP.DLL!Tiputil::CTipProfileMgrEventSink::OnProfileActivated()  + 0x1f バイト 
      IMETIP.DLL!Imeapiutil::ImeCandidateChineseCharacterCategory::GetChineseCharacterCategory()  + 0x15 バイト 
      IMETIP.DLL!CTipProfileMgr::CallOnProfileActivated()  + 0x5a バイト 
      IMETIP.DLL!CTipProfileMgr::ActivateProfileProc()  + 0x98 バイト 
      IMETIP.DLL!CTipProfileMgr::OnActivated()  + 0xca バイト 
      IMETIP.DLL!Tiputil::TextInputProcessorActivateSink::OnActivated()  + 0xd バイト 
      IMETIP.DLL!CTextInputProcessor::CallOnActivated()  + 0x3f バイト 
      IMETIP.DLL!CTextInputProcessor::ActivateProc()  + 0x58 バイト 
      IMETIP.DLL!CTextInputProcessor::ActivateEx()  + 0x38 バイト 
      msctf.dll!CTip::Activate()  + 0x5eb4 バイト 
      msctf.dll!CThreadInputMgr::_ActivateTip()  + 0x154b7 バイト 
      msctf.dll!CThreadInputMgr::ActivateInputProcessor()  + 0x6d バイト 
      msctf.dll!SyncActivateAssemblyByAsm()  + 0x216 バイト 
      msctf.dll!SyncActivateAssembly()  + 0x72 バイト 
      msctf.dll!ActivateAssemblyPostCleanupCallback()  + 0x22 バイト 
      msctf.dll!CThreadInputMgr::_CleanupContextsWorker()  + 0x8ae8 バイト 
      msctf.dll!CThreadInputMgr::_CleanupContexts()  + 0x41 バイト 
      msctf.dll!ActivateAssembly()  + 0x82 バイト 
      msctf.dll!CThreadInputMgr::EnsureTIPsActivated()  + 0xbf74 バイト 
      msctf.dll!CThreadInputMgr::SetFocusEventHook()  + 0x96 バイト 
      msctf.dll!CThreadInputMgr::Resume()  + 0xdb バイト 
      msctf.dll!CThreadInputMgr::ActivateEx_P()  + 0x105 バイト 
      msctf.dll!CicBridge::ActivateIMMX()  + 0x3d バイト 
      msctf.dll!__CtfImeCreateThreadMgr@8()  + 0x7d バイト 
      imm32.dll!_CtfImmTIMActivate@8()  + 0x1483 バイト 
      imm32.dll!_InternalImmLockIMC@8()  + 0xb52 バイト 
      imm32.dll!_ImmLockIMC@4()  + 0xf バイト 
      imm32.dll!_ImmSetActiveContext@12()  + 0x1268 バイト 
      user32.dll!_FocusSetIMCContext@8()  + 0x2c バイト 
      user32.dll!_ImeSystemHandler@16()  + 0x4c バイト 
      user32.dll!_ImeWndProcWorker@24  + 0xf3 バイト 
      user32.dll!_ImeWndProcW@16()  + 0x29 バイト 
      user32.dll!_InternalCallWinProc@20()  + 0x23 バイト 
      user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7 バイト 
      user32.dll!_DispatchClientMessage@24()  + 0x51 バイト 
      user32.dll!___fnDWORD@4()  + 0x2b バイト 
      ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x2e バイト 
      user32.dll!_NtUserSetFocus@4()  + 0x15 バイト 
      user32.dll!_MB_DlgProc@16()  + 0x10a バイト 
      user32.dll!_InternalCallWinProc@20()  + 0x23 バイト 
      user32.dll!_UserCallDlgProcCheckWow@32()  + 0x14d バイト 
      user32.dll!_DefDlgProcWorker@24()  + 0x88 バイト 
      user32.dll!_DefDlgProcW@16()  + 0x29 バイト 
      user32.dll!_InternalCallWinProc@20()  + 0x23 バイト 
      user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7 バイト 
      user32.dll!_SendMessageWorker@24()  + 0x112 バイト 
     user32.dll!_InternalCreateDialog@28()  + 0x76e
      user32.dll!_InternalDialogBox@24()  + 0xb8 バイト 
      user32.dll!_SoftModalMessageBox@4()  + 0x757 バイト 
      user32.dll!_MessageBoxWorker@4()  + 0x269 バイト 
      user32.dll!_MessageBoxTimeoutW@24()  + 0x52 バイト 
      user32.dll!_MessageBoxExW@20()  + 0x1b バイト 
      user32.dll!_MessageBoxW@16()  + 0x18 バイト 

    > xx.dll!Cxx::func(...)  行 3713 + 0x1d バイト C++

      [マネージからネイティブへの移行] 

    -- ここまで --

     本現象はReleaseビルドした.exeファイルを直接実行した時には発生しません。

     宜しくお願いします。

    2014年4月24日 3:35

すべての返信

  • 回答ではありません。あしからず。

    >*** An Access Violation occurred in "xxx\Release\xx.exe" :

    の部分だけ見ると、リリースを起動しているようにみえます。

    一方、"0xfeeefeee"は、デバッグビルドのとき、開放されたメモリーが
    この値で埋められます。つまりデバッグビルドが起動されているように
    思えます。

    んで、掲示された内容に矛盾があると思えるので、
    もう一度全コンパイル、ビルドして、再度試してみてはいかがでしょう。

    2014年4月24日 7:17
  • 投稿者です。コメントありがとうございます。

    ビルドのプロパティを再度確認してみます。

    #でも、.exeを直接起動すると動くのはなぜ。。。

    2014年4月24日 7:34
  • パッと見ですがコールスタックからは、日本語IME が例外だして VS2012 がトラップしてるようにみえますね。

    > 特定のマシン上でデバッグを行うと、MessageBox()の先で以下のような現象が発生する ...

    となってますから、特定マシンの Office バージョン違いで IME が違うとかですかね?

    > #でも、.exeを直接起動すると動くのはなぜ。。。

    デバッガが事前トラップしてるだけで、実際は IME 側でトラップされて OS まで届いてないとかじゃないですかね?

    2014年4月29日 6:00
  • 投稿者です。コメントありがとうございます。

    ビルドのプロパティを見直し、一部のプロジェクトでDebugビルドのものが混入していましたが、直してはみたものの、状況に変化はありません。

    ご指摘の通り、特定のマシンにはOfficeを入れておりませんが、VSってOfficeの有無やバージョンで動作が変わるのでしょうか?

    2014年4月30日 5:04
  • この投稿は、回答ではなく、切り分け観点として提案するものです。

    exe を直接起動すると発生しないのだとすると、以下の手順でも発生しないと言うことでしょうか。

    1.exe を直接起動
    2.Visual Studio のツールメニューなどから対象の exe にアタッチしてデバッグ開始
    3.再現する操作を実行する

    この手順でも再現するのであれば環境に依存する何かに問題があることがうかがえます。
    逆にこの手順で発生しないのであれば Visual Studio での設定ミスにより、「exe 直接起動」とは別の exe が起動されている(別伸ばしにも存在する?)、デバッグ開始でのみ発生する?といった可能性が見えてくるでしょうか。

    2014年4月30日 5:19
    モデレータ
  • #でも、.exeを直接起動すると動くのはなぜ。。。

    >  msctf.dll!CicExceptionFilter() 

    ここからもうかがえるように、TSFは通常動作時、TIP内で発生したexceptionの多くをSEHで隠しています。

    2014年4月30日 6:54
  • >  ご指摘の通り、特定のマシンにはOfficeを入れておりませんが、VSってOfficeの有無やバージョンで動作が変わるのでしょうか?

    自分は VS の動作が「Officeの有無で動作が変わる」のは見たことありません。

    VSの環境設定は複雑ですからマシンで違う設定になってるのは良く見ますけど...

    自分は HomeCloset さんが指摘してるように、アプリと直接は関係ない TSF から投げられている通常は表にでない例外にデバッガが反応してるように見えるという見解です。

    Office のバージョンで IME の挙動が変わると考えるのはおかしくないでしょう?

    MessageBox での発生らしいので Azulean さんの提案してる手順でも再現できると考えてますが、発生しないなら環境設定を疑う事になります。しかし、そうなるとちょっとどのあたりという事までは見当がつきませんね...。


    スタックからすると IME (TIP)がだした例外を TSF がトラップしてるのかな?

    それだと「TSF から投げられてる」という表現はおかしいですね、失礼しました。

    • 編集済み kyano30 2014年4月30日 10:35 追加
    2014年4月30日 10:14
  • よく見ると、確かに「初回例外」と書いてますね。(「ハンドルされていない」ではなく)

    だとすると、「デバッグ」メニューから「例外」を選択してダイアログを開き、「Win32 Exceptions」の「スローされるとき」にチェックがついていないかを確認するところからでしょうか。
    デフォルトはチェックされていませんので、問題が発生する環境でチェックがついていれば外してみてください。

    ※Visual C# 開発者などで初期設定をしていた場合、このスクリーンショットに存在しない「ユーザーにハンドルされていないとき」も表示されますが、今回設定を確認・変更するのは「スローされるとき」であることは変わりません。

    2014年4月30日 11:15
    モデレータ
  • Azulean さんの返信へのよこやりみたいになっちゃって申し訳ないですが...。

    昔は灰色チェックだった覚えがあったので、デフォルトで未チェックは変だと思って確認してみたら VS2013 では、 Win32 Exception 内の全項目にチェックがつかない限り 指摘部分は未チェックで表示されます。

    指摘されている Win32 Exception のツリーを開いて現象の例外となる Access violation のチェック状態を確認してください。

    デフォルトでチェックは外れてたし VS のバージョンも違うので蛇足だったらすみません。

    VS の環境違いでトラップされている状況なら、ここの設定の可能性が高いですね。

    2014年4月30日 14:42
  • 投稿者です。多数のコメントありがとうございます。

    まとめて回答させて頂きますと、exe直接起動後VSで当該プロセスにアタッチしてexeを動かした時には例外は発生しませんでした。

    また、VSでの例外設定で、Win32 Exceptionsの項目のチェックを全て外してVSから起動しても、同じ現象が発生しました。

    最初の投稿で「クラッシュ」という表現を使いましたが、本件の例外発生時に「継続」ボタンでexeの実行を継続すると、以降のMessageBoxは問題なく表示されるようです。

    MessageBoxには基本同じCStringを渡してるのですが、発生個所の違いさえあれ、必ず初回に呼んだMessageBoxで上記現象が発生します。

    2014年5月2日 1:03
  • 「継続」で問題ないのは推測してたとおりですが、「スロー時中断」じゃないとは思ってなかったです。

    しかし、良く考えると「非エラーのハンドルされない例外」になってても、おかしくなかったですね ...

    結果をふまえて原因を再検討すると、

    MessageBoxには基本同じCStringを渡してるのですが、発生個所の違いさえあれ、必ず初回に呼んだMessageBoxで上記現象が発生します。

    この記述が「初回コール時のみ例外発生で2回目以降は例外無し」という意味ならば、「起動後アタッチで例外が起こらない」事もふまえると、デバッガの影響で「ダイアログ初期化」時に TIP 不良になってるというあたりが推測になります ....

    そうなると原因は、やはり本命 IME 、対抗 OS パッチという風に考えます。

    もちろん「ユーザーコードには問題ない」とまでは思えませんけど...

    2014年5月2日 6:11
  • 再現性があるということで、自分だったら、Application Verifier で heap をしつこくチェックした状態でデバッガからプロセスを起動して、もっと早い段階で異常が起きていないか見ます。あるいは少なくとも、異常に関わっている特定の heap block の trace を見ます。
    2014年5月2日 13:05
  • 自分の状況認識の詳細を...

    スタックトレースの履歴メソッド名や例外情報から「MessageBox 作成で TIP ホットキー情報作成中に未割当メモリ参照による例外」をフィルタ処理した「報告例外」でデバッガが中断している状況と考えています。

    そうなると「未割当メモリ参照」は「TIP プロファイル情報の矛盾」あるいは「権限不良」等に起因する「メモリ割当不良」が原因と当りをつけてます。

    Application Verifier は詳しくないのですが、原因調査の一助になりそうなのでお勧めしたい手段ですね。

    しかし、状況からすれば「MessageBox で IME 入力はない」ので根本解決まではからずに、

    1. 中断状況が IME 由来の報告例外に起因するものである
    2. 「アプリケーション」が正常動作である

    といった事の確認でも実質問題ないように思えます。

    IME 変更や OS パッチで現象が起こらなくなる確認がとれれば、リリース先でも同対処で良く思えますしね。

    お勧めしたい対処ではないですけど...

    2014年5月2日 16:38
  • 投稿者です。コメントありがとうぎざいます。

    追加情報となりますが、当初例外発生に気を取られていたのですが、例外が発生した時点ではMessageBoxの表示は

    行われていました。

    また、別のクラスでも同じことをしているのですが、こちらは問題なく動作しております。

    2014年5月9日 1:53