Critical Section のデバッグ情報

本日は、Critical Section についてご紹介をさせていただきます。Critical Section を用いることにより、アプリケーションが使用する各種リソース(ヒープ メモリ、変数等)をスレッド間で排他制御を行うことができるようになります。以下の図では、黒い実線がそのスレッドでの動作が可能な状態を示し、赤実線が排他を行いたい処理になります。また、Thread 2 の赤点線は、排他待ちとなります。この図からもわかるとおり、Thread 1 の LeaveCriticalSection により、Thread 2 の処理が行うことが可能になります。 しかしながら、この便利な機能も、実装を誤るとデッドロックを起こしてしまうことがあります。その結果、アプリケーションがハング (停止) 状態となってしまう要因の一つとなります。そのため、Windows は、デバッグを行う際に有効となる情報を CRITICAL_SECTION 構造体に格納します。 具体的には、Windows SDK に同梱されている “WinNT.h” ファイル には、CRITICAL_SECTION 構造体が定義が行われており、DebugInfo メンバー変数に情報が格納されることとなります。 typedef struct _RTL_CRITICAL_SECTION {     PRTL_CRITICAL_SECTION_DEBUG DebugInfo;     //     //  The following three fields control entering and exiting the critical     //  section for the resource…


[HOWTO] UMDH を用いたメモリリーク調査技法

Platform SDK (Windows SDK) サポートの平田です。私は、元 ADSI/ILM/FIM を担当しておりました。ひょっとするとhttp://blogs.technet.com/b/jpilmblg をご覧になられた方がいらっしゃるかもしれません。ぴろととして記事を書いておりましたが、今後は SDK サポートの平田として鋭意皆様のお役に立てればと考えております。 ところで先日、調布にあるオフィス近くのビアガーデンに行ってまいりました。思ったより混んでいたものの、運よく座ることができました。最近暑い日が多いので、外で飲むビールが美味しくて夏を全身で感じることができました。皆様も、水分と塩分をしっかり補給していただいて体調管理には十分お気を付けください。私たちも、気持ちも体もベストコンディションでお客様の問題を解決できるよう、日々体調管理に気を付けてまいります。 汗で水分がリークすると熱中症になるかなぁとか思い立ったので、本日は、メモリ リークに焦点を当てて調査を行う方法についてご紹介いたします。 概要説明多くの場合、アプリケーションのメモリ リーク箇所の特定は非常に難しいトラブルシューティングとなります。しかしながら、本日ご紹介させていただく User-Mode Dump Heap (以下、UMDH) というツールを用いることで、メモリ リークの発生箇所や、リークの大きさを特定することができます。私たちもお客様からのお問い合わせを調査する際に利用しているツールですので、ひょっとしたらメモリ リークしてるかも?という場合にぜひともご利用いただきたいツールです。 UMDH ツールは、Windows SDK に含まれる Debugging Tools for Windows の一部として提供されており、簡単に利用できるのですが、VirtualAlloc() や VirtualAllocEx() で確保されたメモリのメモリ リークは残念ながら検出することができません。その点だけお気を付けいただければ便利に使えるツールです。 ツールのインストール自分のプログラムにメモリ リークが疑われたら、まず、パフォーマンス モニターでメモリに関する情報を採取してみましょう。これには、パフォーマンス モニターの Process カテゴリの情報を採取し、 Private Bytes の値を監視します。この値が右肩上がりの傾向であれば、メモリ リークが発生している可能性あるため、より詳しく調査をするために UMDH の出番となります。 1)   UMDH のインストール方法以下の SDK をダウンロードしてインストールします。この時、[Debugging Tools for Windows]…


重箱の隅のデバッグ(1) – インポートセクションで設定するブレークポイント

皆さんこんにちは。Platform SDK チームの Chiharun です。  「重箱の隅のデバッグ」シリーズ第 1 回としてデバッグ関連のトピックをご紹介します。ここで利用する WinDbg デバッガはマイクロソフトが公開している高機能なデバッグツールです。入手方法については、以下のURLをご覧下さい。 デバッグ ツールとシンボル: はじめにhttp://msdn.microsoft.com/ja-jp/windows/hardware/gg462988 インポートセクションについて日々の仕事で提供元が不明だったり、デバッグシンボルの存在しないプログラムをデバッグする状況は多々あります。そのような場合にデバッガコマンドでインポートセクションを確認することによってプログラムが呼び出す API の概要を把握し、インポートセクションをライブデバッグで利用する方法について説明したいと思います。 一般的にプログラムが動作する時にメインの EXE プログラム単体ですべての処理を実行することはありません。 必要に応じてプログラムが利用する API の関数本体が実装された外部の DLL に存在する関数を呼び出します。 メインの EXE プログラムは関数へのポインタが設定されたインポートセクションから関数のアドレスを取得して他の DLL に存在する関数を呼び出します。 Windows OS がプログラムをロードする時に、プログラムが参照する外部の DLL の API のアドレスをプログラムが参照できるようにするため、プログラムのインポートアドレステーブルを外部の DLLに存在する API の関数アドレスで初期化します。関連する情報についてはMSDNマガジンの2002年2月号で解説された記事がありますのでリンクをご紹介します。 MSDN Magazine 2002 February – An In-Depth Look into the Win32 Portable Executable File Formathttp://msdn.microsoft.com/en-us/magazine/cc301805.aspx では本題に戻ります。インポートセクションの情報をを確認する方法はいくつかあります。以下の例では少し大きめの緑色の太文字で入力コマンド部分を示します。方法 1…