ダンプファイルに保存されたイベントログを取り出す

エンドユーザー様環境で BSOD が発生したため、取り急ぎ ダンプファイルはいただいたものの、その後の調査でイベントログを確認したくなったことはありますか?   皆さん、こんにちは。Windows Driver Kit サポートチームの津田です。今回は、そんな皆様に、ダンプファイルからイベントログを取り出す方法をご案内します。   ただし、あくまでもダンプファイルに残っている範囲の情報になります。そのため、ダンプファイルから得られたイベントログからは有用なログは得られないけれども、実際のイベントログには有用な情報が得られるかもしれないという場合には、改めてエンドユーザー様に事情を説明して、イベントログの採取をお願いすることになります。(もしくは、このようなことにならないよう、ダンプファイルだけでなく予めイベントログのご採取もお願いしておくことも考えられます。)逆に、今回ご案内する方法によって、ダンプファイルから有用なイベントログが得られれば、ご自身やエンドユーザー様等実際の情報採取に関わる方々に、追加のご負担をお願いせずに済む、また、追加の情報採取をお願いする側も待たずに済む、というメリットがあります。   具体的な手順は以下です。   1.ダンプファイルを WinDbg でオープン 2. !wmitrace.strdump で確認したいログの Logger Id を確認 3. !wmitrace.logsave <Logger Id> <ファイル名>.evtx でイベントログを保存 4. イベントビューアーで .evtx ファイルを開いてログを確認   1.ダンプファイルを WinDbg でオープン   今回は例として、前回の記事「ダンプファイルに保存された ETW トレースログを表示する」<https://blogs.msdn.microsoft.com/jpwdkblog/2016/08/29/%e3%83%80%e3%83%b3%e3%83%97%e3%83%95%e3%82%a1%e3%82%a4%e3%83%ab%e3%81%ab%e4%bf%9d%e5%ad%98%e3%81%95%e3%82%8c%e3%81%9f-etw-%e3%83%88%e3%83%ac%e3%83%bc%e3%82%b9%e3%83%ad%e3%82%b0%e3%82%92%e8%a1%a8/> で使用したダンプファイルをそのまま使います。ダンプファイルの開き方についても、この記事の「8. ダンプファイルを WinDbg でオープン」をご参照ください。   2. !wmitrace.strdump で確認したいログの Logger Id を確認   WinDbg 上の…


ダンプファイルに保存された ETW トレースログを表示する

ご自身が開発されているドライバについて、BSOD 発生時点のダンプファイルの情報からでは根本原因がわからず、BSOD 直前から発生までのドライバ内部の状態を知りたいと思ったことはありますか?   皆さん、こんにちは。Windows Driver Kit サポートチームの津田です。今回は、そんな皆様に、ETW トレースログを BSOD 発生時点のダンプファイルから参照する方法をご案内します。ETW についてご存じない方は、まずは、以前の「Event Tracing for Windows (ETW)」<https://blogs.msdn.microsoft.com/jpwdkblog/2011/12/27/event-tracing-for-windows-etw/> のエントリをご参照ください。   BSOD が発生するまでのトレースログがダンプファイルで参照できますと、以下の 4 点の事前準備は必要ですが、BSOD 発生時のメモリやレジスタの情報から逆アセンブリを追いかけるだけでは遡れなかった情報が取得できます。     (a) BSOD 発生時のダンプファイルで、根本原因特定のために知りたい変数や構造体を特定する。   (b) それがわかるよう、ETW トレースログをご自身のドライバのソースコードに埋め込む。   (c) そのドライバを、現象が再現する環境にインストールする。   (d) logman.exe でトレースログ採取を開始した後、現象を再現する。   これにより、根本原因が判明する可能性が高まります。しかも、ライブデバッグのように WinDbg をカーネルデバッグ接続してタイミングが変わったり、ソースコードのどこが原因なのか必ずしも特定できていない状況でステップ実行をするというような時間がかかったりするというデメリットを回避できます。   本ブログ エントリでは、以下の前提で進めます。     – (a),(b) は省略します。   – (c) として上述のブログ…


シリアルケーブルでのカーネルモードデバッグ設定手順

ユーザーモードのアプリケーションやドライバを開発しているからと言って、カーネルモードのデバッグをする必要がないと思っていませんか?   皆さん、こんにちは。WDK サポートチームの津田です。ユーザーモードのアプリケーションやドライバを開発していても、例えば、以下のようなトラブルシューティングのシナリオに遭遇することがございます。これらのシナリオのように一見カーネルモードのデバッグが必要ないように思われる件でも、必要に応じてカーネルモードのデバッグの設定をお願いすることがございます。   ・   一般的な CreateFile/ReadFile/WriteFile/DeviceIoControl 等の Win32 API が期待通りの動作をせず、エラーを返す場合 → カーネルモードで I/O マネージャが I/O リクエストパケット (IRP) に変換し、カーネルモードドライバーのスタックに送るので、その処理過程をライブデバッグする必要がある場合があります。   ・   スプーラサービスのように、Remote Procedure Call (RPC) で他のプロセス B からプロセス Aの関数が呼ばれた結果、ご自身のアプリケーションがプロセス A から API で取得する値が期待通りにならない。RPC の呼び出し元のプロセス B が何かを特定したい場合 → ユーザーモードデバッガで、プロセス A においてRPC の呼び出しが行われた呼び出し先の関数にブレークポイントを貼ります。現象再現時、ここにブレークします。その状態で、カーネルデバッガからブレークインすることで、他の全てのプロセスの各スレッドのコールスタックから、該当関数を呼び出しているものを確認します。これにより呼び出し元のプロセス B を確認できます。   ・   何らかのプロセスが、COM ポートなど特定のデバイスをオープンしているために、ご自身のアプリケーションはオープンできない。そのプロセスを特定したい場合 → 当該デバイスのドライバの IRP_MJ_CREATE コールバック関数でブレークポイントを貼り、再現させてブレークインすれば、どのプロセスでそのオープンが行われているか確認できる可能性があります。(システムスレッド経由など、複数のプロセスをまたがっていたりすると、もう少し調査が必要です。)   そこで、今回は、これまでカーネルモードのデバッグをする機会がなかった皆様のために、シリアルケーブルでのカーネルモードデバッグ設定手順をご案内いたします。大まかな流れは以下のようになりますが、それぞれのステップを図入りで解説します。   1.     ホスト PC…


デバッガ (WinDbg) をインストールする

カーネルモードもユーザーモードも、ライブデバッグもダンプ解析もできる、無償のデバッガ WinDbg をインストールしたことがありますか?   皆さん、こんにちは。WDK サポートチームの津田です。今回は、WinDbg をインストールしたことがない皆様のために、WinDbg をインストールする手順をご案内いたします。   今回は、インターネット接続された、Windows 10 Version 1511 x86 環境で、管理者権限を持つユーザーを前提に進めます。また、WDK 10 を既にインストールされている方は、その中にも含まれていますが、今回は WinDbg 単体 (スタンドアロンバージョン) でインストールしたいと思います。   1.    以下のページから、「Debugging Tools for Windows (WinDbg) を SDK から入手する」のリンクをクリックしてください。   WDK、WinDbg、関連ツールのダウンロード https://msdn.microsoft.com/ja-jp/windows/hardware/hh852365.aspx   デバッグ ツールの入手   Debugging Tools for Windows (WinDbg) を SDK から入手する http://go.microsoft.com/fwlink/p/?LinkId=536682   2.    以下のように、sdksetup.exe がダウンロードされるので、[実行] をクリックしてください。     3.   …


WDF ソースコード公開

皆様、いかがお過ごしでしょうか。WDK サポートチームの石沢です。 今回の記事より Twitter アカウント MSDEVJP より更新をお知らせいただけることになりました!是非ご活用ください。また Twitter よりお越しの皆様、初めまして!本ブログではドライバ開発に関する記事を公開しております。今後とも何卒よろしくお願いいたします。 今回は Windows Driver Frameworks (WDF) に関するお話しです。 去年の 3 月に WDF のソースコードが GitHub 上に公開されました。  Windows Driver Frameworks これにより Windows 10 では WDF を含めたデバッグをできるようになったわけなのですが、今回はどのように設定すればソースコードデバッグできるのか具体的な手順を詳しく解説いたします。   <今回のメニュー> カーネルデバッグ開始 シンボルパスとソースパスの設定 ブレイクポイントを設定しよう Go! 上手くいかないときは   ■ 1.カーネルデバッグ開始 まずはカーネルデバッガ (Windbg) を接続しましょう。今回は Windows 10 バージョン 10586に接続しています。 バージョンは Windbg 接続時に以下のように表示されますので、把握しておくとよいでしょう。   Connected to Windows 10…


Hyper-V 第二世代仮想マシンの Guest OS への windbg 接続方法

久方ぶりです。まさかたです。   さて、以前、「Hyper-Vなどの仮想OSにwindbgをアタッチする方法」で、仮想 OS 上の COM ポートに名前付きパイプを割り当てる方法をご案内いたしました。この方法は、現在もご利用いただけますが、Windows 8.1/Windows Server 2012 R2 より導入された Hyper-V 第二世代仮想マシンの Guest OS には、デフォルトでは以下のように COM ポートが見えない状態になっているため、戸惑われる方がいらっしゃるかと思います。     そこで、今回は、第二世代仮想マシンの Guest OS でも従来通り名前付きパイプを COM ポートに設定して、windbg でカーネルデバッグを行っていただくための方法をご紹介いたします。   その前に前提として、そもそも Hyper-V 第二世代仮想マシンとは、Hyper-V マネージャーで仮想マシンを新規作成する際に、以下のように選択した仮想マシンのことです。     以前の第一世代と比べて、エミュレーションするハードウェアを新しくしたからこそできるいくつかの特徴がありますが、詳細は、下記ドキュメントに譲ります。     Generation 2 Virtual Machine Overview   http://technet.microsoft.com/en-us/library/dn282285.aspx   ここでは、あくまでもカーネルデバッグの設定をする上で必要な話として、BIOS ベースのファームウェアではなく UEFI ベースとなってセキュアブートがデフォルトとなっていることや、サポートするゲスト OS が現時点では以下の 4 種類であることを記載しておきたいと思います。  …


ACPI ドライバーインターフェース

こんにちは、K里です。 今回は ACPI ドライバーインターフェースについてお話したいと思います。ACPI (Advanced Configuration and Power Interface) は、OS 主導の電源管理制御を実現するために既定された OS – BIOS 間のインターフェース仕様になります。ACPI の電源制御は、OS がいつ何をやるかを決めるのに対し、ACPI BIOS は各種 ACPI テーブル (RSDP に始まり FACP、DSDT など)、AML などをサポートし、具体的な制御方法を提供します。 カーネルドライバーから ACPI BIOS に関する情報の取得あるいは制御を行う手法として、ACPI Control Method を定義しており、AML (ACPI Machine Language) で記述されます。カーネルドライバーは、ACPI Control Method が読み込まれるデバイスオブジェクト (PDO) の名前空間内で以下の IOCTL を使用してこれらの Method を実行することが可能です。これには、Child Object で定義される Control Method も含まれます。 l  IOCTL_ACPI_EVAL_METHOD l  IOCTL_ACPI_ASYNC_EVAL_METHOD…


WOW64 デバッギング

ご無沙汰しております。なおきお~です。 少しずつ暖かくなり、過ごしやすい日が増えてきました。皆さん、如何お過ごしでしょうか? 暖かくなってきたとはいえ、季節の変わり目は、体調を崩しやすいので、お気を付けください。   春は、入学、入社など、新たな一歩を踏み出す季節でもあると思います。 新たな一歩というほど大げさなもの、新しいものではありませんが、今回は、WOW64 のデバッグの Tips を紹介したいと思います。   Windows 7 や Windows Server 2008 R2 のリリース以降、64 ビット Windows OS も浸透してきているように感じます。 ただ、32 ビットのアプリケーションは、まだまだ 多くあり、ユーザ モードのプロセスも含めて、完全に 64 ビットに移行できるのは、まだまだ 先のことになってしまうように思えます。 特に Windows OS に実装されている WOW64 は、完ぺきではないまでも、高い互換性を保持しているように思えます。 ただ、いざデバックをするとなると少々面倒になります。例えば、32 ビット プロセスに対して、64 ビットのメモリ ダンプを取得して、スタックが見られなかったり、カーネル モードのデバッギングの際で、32 ビット プロセスのコンテキストに合わせても、32 ビットのスタックが見られなかったりするなどです。   そんな時に、ちょっと便利な方法をユーザ モード デバッギングとカーネル モード デバッギングで、紹介します。 まず、ユーザ モード デバッギングでは、wow64exts.dll というデバッグ エクステンションを使用します。…


スタックオーバーフロー

こんにちは、K里です。   今回は Windows OS がクラッシュする最多要因の一つであるカーネルスタックオーバーフローについてお話したいと思います。   カーネルスタックは、関数間でやりとりする引数、戻り値や関数内で使用するローカル変数を保持するためのストレージ領域で、そのサイズはプロセッサアーキテクチャに依存して x86 では 12 KB、x64 (amd64/EM64T 含) では 24KB、Itanium では 32 KB と固定で割り当てられます。また、カーネルスタックは、Windows OS の各プロセスで動作するスレッド単位で割り当てられますので、スレッド内で呼び出される全ての関数で使用するスタック消費サイズが割り当てサイズを超えた場合スタックオーバーフローが発生します。その結果、OS はシステム内で致命的なエラーが発生したと判断し、下記のいずれかの Bugcheck を発生させることになります。   Bug Check Codes http://msdn.microsoft.com/en-us/library/ff542347(VS.85).aspx STOP 0x1E: KMODE_EXCEPTION_NOT_HANDLED STOP 0x2B: PANIC_STACK_SWITCH STOP 0x7E: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED STOP 0x7F: UNEXPECTED_KERNEL_MODE_TRAP STOP 0x8E: KERNEL_MODE_EXCEPTION_NOT_HANDLED   以下は x86 での典型的なスタックオーバーフローです。   1: kd> !analyze -v *******************************************************************************…


USB 2.0 カーネル デバッグ その後

こんにちは、K里です。今回は、以前ご紹介した USB 2.0 カーネルデバッグについての追加情報をお知らせします。USB デバッグの詳細については、まずは以下の記事をご一読いただけますと幸いです。   USB 2.0 カーネル デバッグ 前編 USB 2.0 カーネル デバッグ 後編   上記記事の前編にて、ターゲットマシンの設定 (3) に以下のコマンドがあります。     bcdedit /set {identifier} loadoptions busparams=x.y.z   これは、カーネルデバッガ接続のために使うデバイス (USB EHCI の Host Controller や 1394 Host Controller) を一意に指定するために、デバイスマネージャーで確認される  busparams=<Bus>.<Device>.<Func> の入力を行いますが、この busparams の指定方法が、USB デバッグの場合、ターゲット OS によって何進数で入力するのかが異なります。以下、1394 デバッグも併せてターゲット OS 毎の指定方法を記載します。   Target OS USB 2.0 Debug…