きまぐれライダー日記

先週あたりから自分のドメインに
またアクセス出来なくなっていました。

原因はDynamicDNSUpdateClientであるDiCE for Linuxが更新せずに止まっていました。
（今までの経験上2ヶ月ぐらいすると止まっている様な気がする・・・。
とりあえず、DynamicDNSが更新されないことには
外部からアクセスする事が出来ないため
安定化のためにcronを使って毎週DiCEを再起動するようにしました。

ついでに、メモリを512MB増設して
１GBにしたため、スワップメモリをほとんど使用しなくなりました。
（メモリの消費量の原因は、ウィルス対策ソフトなんですけどね・・・

これで改善されなければ、また考えようっと（笑

日付変更前にバイトから帰宅し
その後、日付変更した頃に実家に帰省しました。

今までに選挙会場の本人確認のバイトはしたことがありますが
投票自体は初めてだったりします（こら
忙しくて実家に戻っている余裕も無かったので・・・

で、実際に地元の選挙会場に行って選挙をしてきた訳ですが
本人確認ってあんなにいい加減でしたっけ？

自分がバイトやってた時は、
本人確認のために生まれ月を言わないといけなかったハズなんだけど
今回は何も言わずに投票用紙を渡された。これって自分の地元だけなのか・・・？
とりあえず、やる気の無さはよーく伝わってきた（苦笑

仮想マシンの名前付きパイプ接続を使ってWinDbgとの接続実験をしてみました。
とりあえず、Windows XP SP3 (x86)の環境下で
Sun VirtualBox、VMware Player、VMware Workstation(v6.5)の３つで試した結果。
VMware Workstationのみ接続を確認出来ました。
VMware系での接続を確認しました。

VirtualBoxはWindowsでの名前付きパイプでの接続方法の資料が見つからず、接続出来ているか怪しい。
VMware Playerは名前付きパイプでの設定は出来るが
GesutOS起動時に何故か怒られて接続出来ない。これは設定が怪しい・・・。
VMware Playerでの名前付きパイプでの接続を確認。やはり設定に問題がありました。
Web上でのWinDbg動作確認報告が多いVMware Workstationだと問題なく動作確認出来ました。

その時の設定は以下のとおり。

[X] 起動時に接続
名前付きパイプを使用
・ \\.\pipe\com_1
・ この端末はサーバです。
・ 接続先はアプリケーションです。
[X] ポーリングでCPUを放棄する

ちなみに、VMwareの構成ファイルであるvmxファイルの中は以下のとおり。

serial0.present = "TRUE"
serial0.yieldOnMsrRead = "TRUE"
serial0.fileType = "pipe"
serial0.fileName = "\\.\pipe\com_1"
serial0.tryNoRxLoss = "TRUE"

WinDbg側の設定は以下のとおり。

port : \\.\pipe\com_1
baudrate : 115200
pipe : true
reconnect : true

仮想マシン上でOSをデバッグモードで起動し
WinDbgからPIPE接続でKernelDebugを開始すると１台の端末でデバイスドライバの
開発からデバッグおよび動作確認を楽々行う事が出来ます。

但し、WinDbgでソース上にDbgBreakPoint()を記載してソースデバッグ等を行った場合は
デバイスドライバをコンパイルした際に出力される.pdb（Program Debug Database）ファイルが
WinDbgに使用されているため、そのままドライバの再コンパイルを行った際にリンケージで失敗します。
その場合は、一度WinDbg側でBreakをして停止して、WinDbgを終了させた上で終了し再コンパイルを行う。
再びWinDbgを開始するとBreakした状態からデバッグを再スタートする事が出来る。
（WinDbgを終了する際にSessionを保持しないといけないかも・・・[未確認]

とりあえず、仮想マシンを使ったデバイスドライバの開発が一番スマートかつ安全な環境だと思う。
特に、VMware WorkstationのようにSnapshot機能で元の状態に戻せるのは
ブルースクリーンから逃れられなくなるといった精神的な負担も減らしてくれる（笑

欲を言えば、VirtualBox上でWindowsの名前付きパイプ接続が出来れば
お金が掛からなくて良いんだけど・・・誰か情報ありません？

仕事（バイト）でDeviceDriverの開発はじめました（笑
本来ならうちでやる仕事じゃないんですが・・・
まぁ、今まで触れたことの無い領域のため、ワクワクしながら作業してます・・・面倒だけど。

Driverの開発は楽しいです。特にWindowsのKernelDebug。
まず2台の端末を用意し、お互いをRS-232Cのクロスケーブルで物理的に接続。
ターゲットとなるPC（Debug対象）のBoot.iniを編集しoperation systemのセクションの値の後ろに以下を追加
（OS：WindowsXP COM１にて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に接続