2009,08,27 Thursday
仕事(バイト)でDeviceDriverの開発はじめました(笑
本来ならうちでやる仕事じゃないんですが・・・
まぁ、今まで触れたことの無い領域のため、ワクワクしながら作業してます・・・面倒だけど。
Driverの開発は楽しいです。特にWindowsのKernelDebug。
まず2台の端末を用意し、お互いをRS-232Cのクロスケーブルで物理的に接続。
ターゲットとなるPC(Debug対象)のBoot.iniを編集しoperation systemのセクションの値の後ろに以下を追加
(OS:WindowsXP COM1にて115200bpsの環境の場合)

あとは、WinDbgが接続待ちになったのを確認して
ターゲットPCをデバッグモードで起動すると、KernelDebugが始まる。
さてさて、このWinDbgというデバッガ
brakeやらWatchやらStepOverやら、よく見るデバッグツールと同じ機能が付いてます(笑
もちろん、breakを行うとターゲットPCは止まります(笑
ダンプも出来て、メモリの手動書き換え等も出来る。再起動までも・・・
で、実際にDeviceDriverのデバッグをする際には
Driverのソース類をWinDbgに設定しておくと、ソースレベルでデバッグが出来ちゃいます。
もちろん、ソースの中でブレークポイントを呼び出すコードを記述しておけば
ソース側(実際はドライバ)からbreakしてくれます。
まぁ、こういう機能が無いと根性デバッグになってしまうので困りますが・・・
問題は、OS内部(Kernelモード)での動作になるので
ドライバにバグが含まれているとOSごとクラッシュします(汗
下手するとPCがそのままお亡くなりになる可能性大・・・。
そこで考えたのが最近流行の仮想マシン。
仮想シリアルポートを用意して、GesutOSをデバッグモードで作業すればクラッシュしても問題無い。
今日はVirtualBoxを使って試していたのですが・・・上手くいかず(?)
とりあえずWeb上で先人が見つかったため、またリベンジをしてみる予定。
・ blog : WinDbgでGesutOSに接続
本来ならうちでやる仕事じゃないんですが・・・
まぁ、今まで触れたことの無い領域のため、ワクワクしながら作業してます・・・面倒だけど。
Driverの開発は楽しいです。特にWindowsのKernelDebug。
まず2台の端末を用意し、お互いをRS-232Cのクロスケーブルで物理的に接続。
ターゲットとなるPC(Debug対象)のBoot.iniを編集しoperation systemのセクションの値の後ろに以下を追加
(OS:WindowsXP COM1にて115200bpsの環境の場合)
/debugport=com1 /baudrate=115200もう一台のPC(デバッガ側)ではWinDbgを起動して、KernelDebugの設定を行う。

あとは、WinDbgが接続待ちになったのを確認して
ターゲットPCをデバッグモードで起動すると、KernelDebugが始まる。
さてさて、このWinDbgというデバッガ
brakeやらWatchやらStepOverやら、よく見るデバッグツールと同じ機能が付いてます(笑
もちろん、breakを行うとターゲットPCは止まります(笑
ダンプも出来て、メモリの手動書き換え等も出来る。再起動までも・・・
で、実際にDeviceDriverのデバッグをする際には
Driverのソース類をWinDbgに設定しておくと、ソースレベルでデバッグが出来ちゃいます。
もちろん、ソースの中でブレークポイントを呼び出すコードを記述しておけば
ソース側(実際はドライバ)からbreakしてくれます。
まぁ、こういう機能が無いと根性デバッグになってしまうので困りますが・・・
問題は、OS内部(Kernelモード)での動作になるので
ドライバにバグが含まれているとOSごとクラッシュします(汗
下手するとPCがそのままお亡くなりになる可能性大・・・。
そこで考えたのが最近流行の仮想マシン。
仮想シリアルポートを用意して、GesutOSをデバッグモードで作業すればクラッシュしても問題無い。
今日はVirtualBoxを使って試していたのですが・・・上手くいかず(?)
とりあえずWeb上で先人が見つかったため、またリベンジをしてみる予定。
・ blog : WinDbgでGesutOSに接続
| Programming::WDK | comments (0) |
コメント
コメントする
この記事のトラックバックURL
http://wish-star.sytes.net/~gaku/tb.php/150
トラックバック
TOP PAGE △






