RegEditを開き、以下の場所へ
「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion」
「RegisteredOrganization」＝会社名
「RegisteredOwner」＝名前
セットアップ時、適当に設定しまい、なんらかのアプリをインストールする際にもこの情報が使われるため、衛生上良くない場合は修正すべし
WindowsXP,Vista,7
Windows7やVistaは標準のままだと受信icmpをブロックするようにファイアウォールが設定されている。
しかも、コントロールパネルから起動する「Windowsファイアウォール」からは修正できない。
１．管理ツール
２．セキュリティーが強化されたWindowsファイアウォール
３．受診の規則
４．新規作成
というステップが必要となる。
これを知らないと送信pingはOKだが、受信pingがNGのつぼにハマるなり・・・ニンニン
詳しくはこちら「Windows Vistaのファイアウォールでpingへの応答を許可する」
掲題の通り、BIOSでIntel VTをEnableに設定して再起動する。
これでOKだね、Hyper-V2.0君！
ゲストをインスト・・・「Attempting to load a 64-bit application,however this CPU is not compatible with 64-bi mode」
なんでやねん！？
色々と探る・・・３日経過？？？
ふと、昔の自作機を思い出してみる・・・・
PCの電源を切るだけではなく、コンセントから抜くことにより完全リセットされ、BIOSが正しく設定されることがあった！！
まさか・・・この発展した現代PCにそんな邪道がぁ？？？
ビンゴ！でした（笑）
BIOS上では正しく「Enable」と何度見てもなっていましたが、内部では切り替わって無かったらしい・・・
恐ろしや、PCマジック！
そんなこんなで今日も猛勉強、ありがとナイ。。。（涙）
WIndows7を自作マシンへ新規にインストールしようとISOイメージを焼き、セットアップ開始。
マザーDG45ID（インテル）
メモリ8G（UMAX2G×4）
CPU CoreQ 9550
サクサク進みファイルのコピー中となり、60％・・・
「必要なファイルをインストールできません。 ファイルが破損しているか見つからない可能性があります。・・・」
はてっ？焼きミスかな？ということで、時間かかるベリファイまでやって再度、焼く。。。
再チャレンジ！
「ファイルが破損・・・」？？？
DVDドライブの問題か？
外付けDVDでインストール開始・・・70%で駄目？？？
HDDがイカれているのか？
余っているHDDにチェンジして・・・駄目？
ブータブルUSBからインストールを試みるも・・・駄目？
他にもBIOSを最新版にしたり、古いものへ変えてみたりも・・・駄目？
Windows 2008R2をインストールしてみても同じ所で落ちる・・・これが一層俺を苦しめる？？？
最小構成にしてインストール開始・・・・無事に終了！！
原因はメモリでした（汗）
memtest86+で全然問題なかったから、疑ってなかった、こんなこともあるのか（とほ）
2G×4=8Gがダメらしい、ここまで、一週間ぐらいかかった（怒）
インストールした後に8Gへ戻したが、今の所、問題なし
ちなみにWindows 2008R2も全く同じ症状でした。
このマシンにVMware ESXi 4.0を乗っけて8GのままゲストにWindows7 Or Windows 2008R2をインストすると、同じ現象になりました（苦笑）
「ファイルが破損・・」って関係無いメッセージにまどわされた！！！
（メモリなので正確には全然関係なくは無いが・・・）
MSさん、もう少し頑張ってメッセージを作ってよ（苦笑）
「メモリが駄目です。。。と」
人生勉強メモでした。
追伸：DG45IDのマザーはインテル製とは思えん出来。。。BIOS0127と0129でDVI出力が御臨終となり0113へ見えない画面と闘いながら、リカバリーのしまつ。。。無事にリカバリー出来たが、これがほんとのインテル入ってる？（もちろんUMAXメモリも相性悪いが）
今まで色々な言語の参考書を読んできたが、肝心なことが書かれていないと思い、世の中に一言（笑）
開発者に一番重要で必要なスキルは、Log出力機能を付けることだ！
1番の狙いとしては不正エラーを捉えることが目的で、後はおまけで色々と適材適所に仕掛けて、ほしい情報を出力すればいい。
じっくりテストをしたとしても運用を開始して本番環境で、ほぼ必ずと言ってよいほど、簡単には分からないエラーが発生する。その際、確実に問題点を絞り出すことが非常に重要となるので、この為だけに仕掛けると言っても過言ではない。この機能があるとないとでは大違いである。
当たり前だが、プログラム内は目に見えない。Log出力してあれば見える形でユーザーに対し「これで大丈夫です」と説明する材料となり、自信を持って説明することが出来る。また説明する開発者もアタフタせずにすむ。（笑）
開発する場合は正常なルートを初めは作ってしまいがちだが、一番はじめにLog出力機能を考えて作成する。最近ではLog4など色々と言語にぶら下がっている出力機能もあるので自作しても良いし、既存のLogClassを使用しても良い。
機能としては、出力機能、出力停止機能、出力先変更機能は最低ほしい。フラグやPathは定数をきっておいても良い。
最低限ほしい出力内容は日時、どこから出力されたか、ステータスはエラーなのかログなのかの切り分け情報、内容と四つはおさえてほしい。もちろんそのシステムにより、必要な情報は出力する。Web系アプリならマルチスレッドでの動作な使用ユーザー情報（IDなど）も必要で可能であればDBへ出力してもいい。
このDBへの書き込みはDB接続を前提としているので接続自体に問題が発生した時に捉えられないことがあるので、基本はローカルにログを吐いて、DB接続が確認できたらDBへも吐き出させるのが有効。（毎日夜中の1時になど）
DB出力は注意が必要で、プログラムエラーのログを吐こうとしたらDB接続エラーとなることが考えられる。エラーのエラーは本末転倒になる。DB出力は十二分に確認が必要。またシステム負荷の度合をみながら設置すること。
■Logを出力するタイミング
・エラー時
・単体起動時、単体終了時
・重要な箇所（DB更新など）
言語に存在し、余裕があればThrow系と連携をとると最適になる。
本当に硬いシステムの中身はLog出力機能が充実しているものであり、不安定なシステムにはLog機能が充実していないことが多い。
これが出来て一人前？・・・当たり前（苦笑）
