none
ntdll.dllの書込み違反のエラーダイアログが出る RRS feed

  • 質問

  • Windows server 2008R2でアプリを起動すると、ntdll.dllの書込み違反のエラーダイアログが出る。

    アプリの起動はOS再起動後の起動ではエラーは出ませんが、アプリを終了後、再度起動するとエラーが表示します。

    半年前まではWindows server 2008R2でこの現象は出ていませんでした。

    何か対応策はありますでしょうか

    2017年1月17日 3:02

すべての返信

  • ntdllはアプリケーションがOSの機能にアクセスするときに利用するモジュールなので、呼び出し側のアプリの問題です。

    https://social.technet.microsoft.com/Forums/ja-JP/8457f94a-1514-4698-848a-565e7ab1b82f/ntdlldll?forum=windowsgeneraldevelopmentissuesja

    などを参考に情報を収集してみたらどうでしょうか?

    2017年1月17日 16:49
  • 原因がまだ判りません。

    ちなみにダイアログの表記は下記になります。

    モジュールntdll。dllのアドレス 77DEEB83でアドレス00000014に対する書込み違反が起きました

    2017年1月19日 3:54
  • > アプリを起動すると

    特定のアプリケーションでのみ発生するのか、すべてのアプリケーションで発生するのか、特定のアプリケーションであればその名称は何か、アプリケーションのベンダーには情報がないのか(そもそもベンダーに問い合わせているのか)など、アドバイスを得るために提供できる情報がまだ多数あると思います。


    hebikuzure

    2017年1月19日 4:25
  • アプリは弊社で以前開発した特定のアプリになります。

    このエラーの調査方法が判らないです。

    どのようにすればいいのでしょうか?

    2017年1月24日 1:14
  • 自社で開発したアプリでしたらソースがあると思いますが、開発環境でデバッグモードで動作させ、エラーが発生している箇所を

    特定し、アプローチする等基本的な開発の作業と思いますが

    実行モジュールでしか発生しなのであれば、デバッグコードを追加し、詳細なデータを出力するようにしてエラーが発生する箇所を特定することが第一歩と思います。


    2017年1月24日 2:56
  • ・基礎知識

    https://msdn.microsoft.com/ja-jp/library/d5zhxt22.aspx

    ・ダンプファイルの回収

    エラー報告が有効なら

    %LOCALAPPDATA%\Microsoft\Windows\WER

    をチェックしてあれば回収。

    そうでなければ以下をチェックしてレジストリを設定して、ダンプファイルを保存して回収。

    https://social.technet.microsoft.com/Forums/ja-JP/39f87382-bffe-4677-a985-533d9fca7f45/wer?forum=winserver8

    ・ダンプファイルの解析

    リリース時点のビルドのpdbファイルとソースファイルがあれば、すぐにソースの行番号まで判明します。

    pdbファイルが残っていなければ、可能ならビルドしなおして(pdbを生成しない設定なら生成するように変更)、再配置してダンプを取り直すのが良いです。(追記)

    最悪、そのようなことができないなら、ダンプファイルの逆アセンブルのエラー報告のアドレス位置のマシン語の16進数のバイトシーケンスをコピーして、/FAcsオプションを付けてビルドし直した時に出来るアセンブリコードから検索する方法があります。(C++の場合)

    (追記)

    具体的には、

    * ダンプファイルでエラーの発生している部分をチェック: <モジュール名>!<16進数アドレス>()

    * エラーの出ているアドレスの逆アセンブルコードをチェック (アドレスの前後5行):

    表示形式は以下のようになっているので、オペコードのバイト列を控えておく(コピー)

    <16進数アドレス> <16進数のマシン語のオペコードのバイト列(可変長)> <左記をアセンブラ言語に置き換えたコード>

    * <モジュール名>のプロジェクトを開いて、/FAcsオプションを付けてビルド

     https://msdn.microsoft.com/ja-jp/library/367y26c6.aspx

    * 生成される.codファイルを開いて、オペコードのバイト列を検索(改行がある場合があるのでヒットしないときは短くする)

    * 逆アセンブルコードに対応するC++のコードをチェック

    2017年1月24日 3:06
  • マネージコードの場合もpdbによる解析は有効です。

    pdbが使えない場合は、クラッシュダンプの解析は難しいです。以下は使えるかわからないという前提で読んでください。

    リリースビルドのプログラムを問題のモジュールを読み込んだ状態でブレークさせ、逆アセンブルすることで、JITコンパイラが生成したアセンブラ言語のコードにアクセスできます。

    https://msdn.microsoft.com/ja-jp/library/a3cwf295.aspx

    https://blogs.msdn.microsoft.com/myamada/2010/05/14/visual-studio/

    .NETのバージョンによってJITが違う場合があるので、運用環境と解析を行う環境で生成されるアセンブラ言語のコードが異なる場合があることに注意してください。

    https://blogs.msdn.microsoft.com/jpvsblog/2016/01/11/net-framework-4-6-64-bit-jit/

    また、プロセスの仮想アドレス空間へのアセンブリの読み込み順の再現性や、REBASE(ベースアドレスの再配置)の再現性など、不明な点も多いので、この方法により、クラッシュダンプの解析が出来るかは未知数ですが、運用環境と解析を行う環境で同じ条件を整えられれば再現できる可能性はあるかもしれません。他に手がなければチャレンジする価値はあるでしょう。


    2017年1月24日 11:41