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

すべての返信

• 

  

  0

  サインインして投票

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

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

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

  • 回答の候補に設定 立花楓Microsoft employee 2017年1月19日 4:32

  2017年1月17日 16:49
• 

  

  0

  サインインして投票

  原因がまだ判りません。

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

  モジュールntｄｌｌ。ｄｌｌのアドレス　77ＤＥＥＢ83でアドレス00000014に対する書込み違反が起きました

  2017年1月19日 3:54
• 

  

  0

  サインインして投票

  > アプリを起動すると

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

  ---

  hebikuzure

  • 回答の候補に設定 立花楓Microsoft employee 2017年1月20日 0:57

  2017年1月19日 4:25
• 

  

  0

  サインインして投票

  アプリは弊社で以前開発した特定のアプリになります。

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

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

  2017年1月24日 1:14
• 

  

  0

  サインインして投票

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

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

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

  
  

  • 編集済み BadCompany 2017年1月24日 2:58 追加
  • 回答の候補に設定 立花楓Microsoft employee 2017年1月31日 4:36

  2017年1月24日 2:56
• 

  

  0

  サインインして投票

  ・基礎知識

  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++のコードをチェック
  
  

  • 編集済み tmori3y2 2017年1月24日 9:58
  • 回答の候補に設定 立花楓Microsoft employee 2017年1月31日 4:36

  2017年1月24日 3:06
• 

  

  0

  サインインして投票

  マネージコードの場合も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(ベースアドレスの再配置)の再現性など、不明な点も多いので、この方法により、クラッシュダンプの解析が出来るかは未知数ですが、運用環境と解析を行う環境で同じ条件を整えられれば再現できる可能性はあるかもしれません。他に手がなければチャレンジする価値はあるでしょう。

  
  

  • 編集済み tmori3y2 2017年1月24日 11:53
  • 回答の候補に設定 立花楓Microsoft employee 2017年1月31日 4:36

  2017年1月24日 11:41