投稿者: knarita

レジスタのEBPを基準にして読み解いていきます。EBPで示されるアドレスの手前4バイトが呼び出し元アドレス、EBP以降が引数です。EBPで示される場所に格納されている4バイトが関数呼び出し前のEBPアドレスです。
EBPが0ｘ00C00018の場合を例としてスタックを読み解きます。

0ｘ00C00010 ： 00 00 00 04 // 引数、または、スタック変数
0ｘ00C00014 ： 00 00 00 03 // 引数、または、スタック変数
0ｘ00C00018 ： 00 C0 00 28 // 手前のEBPアドレス
0ｘ00C0001C ： 00 40 10 40 // 呼び出し元アドレス
0ｘ00C00020 ： 00 00 00 02 // 引数、または、スタック変数
0ｘ00C00024 ： 00 00 00 01 // 引数、または、スタック変数
0ｘ00C00028 ： 00 C0 00 40 // 手前のEBPアドレス
0ｘ00C0002C ： 00 40 10 80 // 呼び出し元アドレス

cdecl呼び出し規約や、stdcall呼び出し規約では、引数は右に書かれているものから順にスタックに格納されます。したがってアドレスの大きいものから順に、右から左の引数となります。Pascal呼び出し規約では逆に左から順に格納されます。
C++の場合this ポインタがスタックに追加されます。thisポインタはすべての引数をスタックに格納した後、最後にスタックに積まれます。Windowsでは関数が引数を伴わない場合には、thisポインタをスタックに積まずに、ECXレジスタに格納して関数を呼び出す場合があります。
スタック変数の積まれる順序は保障されません。最適化の結果、順不同にスタックに積まれます。

デバッグを行う上で実行位置に続いて重要なのがスタックの情報です。
別プロセスのスタック情報を取得するには、ReadProcessMemory APIを使用します。「ネィティブデバッガを作る」で取得したCONTEXT構造体のEspレジスタで示されるアドレス以降のデータを読み出します。

BYTE stackPointer[64];
DWORD readedSize(0);
HANDLE hProcess(0);
hProcess = ::OpenProcess(PROCESS_VM_READ, FALSE, debugEvent->dwProcessId);
if (NULL != hProcess)
{
// スタック領域からメモリを読み出す
if (::ReadProcessMemory(hProcess, (LPVOID )context.Esp, &readBuff, sizeof(readBuff), &readedSize))
{
// スタックダンプを表示する
}
}

ReadProcessMemory APIで確保されていないメモリ領域にアクセスすると、デバッグ対象となっているプロセスで不正なメモリアクセスがおこりDebugEventが発生します。ReadProcessMemoryで不正なメモリアクセスを起こし、DebugEventで再びReadProcessMemoryを呼び出し・・・という無限ループに陥らないように注意が必要です。
ReadProcessMemoryの第二パラメータや第三パラメータで割り当てられていないメモリを指定しても、ReadProcessMemoryはエラーを返さずに正常終了します。ReadProcessMemoryがエラーになるか否かで、正しくメモリを読み出せたか判断することはできません。

WindowsOSやMozillaなどアプリケーションのデバッグ情報を送信する機能を備えたソフトウェアが増えています。Debugging Functions APIを使って実行中の不正なメモリアクセスなどを監視してデバッグ情報を取得する機能を確認してみましょう。
まずデバッグを行うにはCreateProcess APIを使ってデバッガからデバッグ対象のプロセスをDEBUG_PROCESSオプション付きで起動するか、あるいはデバッグ対象のプロセスからデバッガをDEBUG_ONLY_THIS_PROCESSオプション付きで起動する必要があります。
続いてWaitForDebugEvent APIを使用してデバッグ対象プロセス内でイベントが発生するのを待ちます。ここでは不正なメモリアクセスエラーだけを対象として考えます。dwDebugEventCodeがEXCEPTION_DEBUG_EVENT、ExceptionCodeがEXCEPTION_ACCESS_VIOLATIONの場合にエラーをトラップしていみます。これ以外にDLLのLoad/Unload、プロセスやスレッドの開始/停止、デバッグ標準出力へのメッセージや、プロセス内で発生した各種例外を取得することができます。
デバッグ対象プロセスの状態を取得するために、GetThreadContext APIを使用します。これによりデバッグ対象プロセス内で不正なメモリアクセスが発生した時のCPUレジスタの状態を取得できます。取得されるCONTEXT構造体の内容は使用しているCPUのアーキテクチャによって異なります。デバッグにこの情報を利用するためには、各種CPIアーキテクチャ毎にレジスタがどのように扱われるのか熟知している必要があります。
今回はx86 CPUアーキテクチャを対象としますので、CONTEXT構造体のeipレジスタに注目してください。eipレジスタの値が不正なメモリアクセスが発生した時に実行されていたアプリケーションコードの場所をしめします。あとはMAPファイルなどを確認して問題箇所を特定します。
デバッグイベントに対する処理が終わったら、ContinueDebugEvent APIを呼び出します。このAPIの呼び出しによりデバッグイベントの発生により一時停止していしるデバッグ対象プロセスの処理を再開させます。

// デバッグ対象のプロセスを開始する
STARTUPINFO startupInfo;
PROCESS_INFORMATION processInfo;
::memset(&processInfo, 0x00, sizeof(processInfo));
::memset(&startupInfo, 0x00, sizeof(startupInfo));
startupInfo.cb		= sizeof(startupInfo);
if (CreateProcess(NULL, m_cmdLineInfo.m_runAppName.GetBuffer(), NULL, NULL, FALSE, DEBUG_PROCESS, NULL, NULL, &startupInfo, &processInfo))
{
// デバッグイベントを待つ
DEBUG_EVENT debugEvent;
while (WaitForDebugEvent(&debugEvent, INFINITE))
{
if (EXCEPTION_DEBUG_EVENT == debugEvent.dwDebugEventCode)
{
if (EXCEPTION_ACCESS_VIOLATION == debugEvent.u.Exception.ExceptionRecord.ExceptionCode)
{
// スレッドハンドルの取得
HANDLE hThread(0);
hThread = ::OpenThread(THREAD_GET_CONTEXT, FALSE, debugEvent->dwThreadId);
if (NULL != hThread)
{
// スレッドの状態を取得
CONTEXT		threadContext;
threadContext.ContextFlags	= CONTEXT_ALL;
if (GetThreadContext(hThread, &threadContext))
{
// ここでデバッグ処理をおこなう
}
}
}
}
ContinueDebugEvent(debugEvent.dwProcessId, debugEvent.dwThreadId, DBG_CONTINUE);
}
}

リリース後のアプリケーションで例外が発生した場合、codファイルを使用して例外の発生した行を特定することができます。
コンパイル時に生成された、アセンブリ言語のコードと、コンピュータ語のコードを保存することができます。プロジェクトのプロパティを開いて、C/C++の出力ファイルにある「アセンブリの出力」を変更して、「アセンブリコード、コンピュータ語コード、ソースコード」を選択します。これでビルド時に拡張子codのファイルが生成されます。
マップファイルを使用することで、例外オフセットから障害が発生したアドレスを調べられることは「マップファイルを使用したデバッグ」で解説しました。

Address Publics by Value Rva+Base Lib:Object
0000:00000001 ___safe_se_handler_count 00000001
0000:00000000 ___ImageBase 00400000
0001:00000000 _wmain 00401000 f crashTest.obj
0001:00000020 ?funcA@@YAHXZ 00401020 f crashTest.obj
0001:00000050 ?funcB@@YAHH@Z 00401050 f crashTest.obj
0001:00000090 ?funcC@@YAXXZ 00401090 f crashTest.obj

ここで例外の発生している関数funcBと例外オフセットアドレスの差を求めます。この場合、例外オフセットが0ｘ1064、 関数の先頭アドレスが0x1050で、差分は0x14(20)バイトです。ここでcodファイルのfuncBの場所を参照します。

PUBLIC ?funcB@@YAHH@Z ; funcB
; Function compile flags: /Odtp
; COMDAT ?funcB@@YAHH@Z
_TEXT SEGMENT
_val$ = -4 ; size = 4
_arg1$ = 8 ; size = 4
?funcB@@YAHH@Z PROC ; funcB, COMDAT

; 29 : {

00000 55 push ebp
00001 8b ec mov ebp, esp
00003 51 push ecx

; 30 : char *val = NULL;

00004 c7 45 fc 00 00
00 00 mov DWORD PTR _val$[ebp], 0

; 31 : strcpy(val, “Hello World”); // 1.ソースコードの31行目で例外が発生している

0000b 8b 45 fc mov eax, DWORD PTR _val$[ebp]
0000e 8b 0d 00 00 00
00 mov ecx, DWORD PTR $SG-6
00014 89 08 mov DWORD PTR [eax], ecx // 2.ここで例外が発生している
00016 8b 15 04 00 00
00 mov edx, DWORD PTR $SG-6+4
0001c 89 50 04 mov DWORD PTR [eax+4], edx
0001f 8b 0d 08 00 00
00 mov ecx, DWORD PTR $SG-6+8
00025 89 48 08 mov DWORD PTR [eax+8], ecx

; 32 : printf(“call funcB”);

00028 68 00 00 00 00 push OFFSET $SG-7
0002d ff 15 00 00 00
00 call DWORD PTR __imp__printf
00033 83 c4 04 add esp, 4

; 33 : return 0;

00036 33 c0 xor eax, eax

; 34 : }

00038 8b e5 mov esp, ebp
0003a 5d pop ebp
0003b c3 ret 0
?funcB@@YAHH@Z ENDP ; funcB
_TEXT ENDS

0ｘ0014バイトの個所を探すと、2.の個所で例外が発生していることがわかります。これは1.で示されるソースコード上の31行目にあたります。この作業でリリース後のアプリケーションでもソースコード状の何処で例外が発生しているのか特定することができます。