CreateProcessの第1引数って

「WindowStationとDesktopと」の関連で、CreateProcess()の引数を調べてました。
(dwCreationFlagsとか)
手元に「Advanced Windows 第5版(上)」があったので、そちらも参照してました。
(そういえば、昔(第3版だったかな?)は1巻だけだったのに、最近は上下巻に分かれてるんですね)
その中で、昔から気になっていた「第1引数」の正体が・・・・
「このpszApplicationName(MSDNではlpApplicationNameってなってます)パラメータによって実現される機能は、WindowsのPOSIXサブシステムをサポートするためにCreateProcess関数に追加されたものです」
ってことは、第1引数は気にするなと。
っていうか、
第1引数として『追加』ってどういうこと!!
普通、『追加』って言えばケツにつけるでしょ。

WindowStationとDesktopと

一般保護違反(General Protection Fault)のメッセージボックスのOKボタンをプログラムから押させたいというリクエストがあったので、
EnumWindowとかSendMessageとか使ったプログラムを作成。
(今時Win32API使うんかい!!ってツッコミは無しで(^^ゞ)
しかし、対象プログラムはサーバ上でサービスから別プロセスで起動されてるとのこと。
・・・デスクトップ空間違うじゃん!!
とりあえず、ネット検索しまくりで「OpenWindowStation()」と「OpenDesktop()」のサンプル見つけたまではいいけど、
テスト環境作ってみて、「実環境と一緒なのかどうか不明!」ってことに気付く。
となると、いろんなデスクトップ空間で動かせるかチェックしたいところ。
「Desktop Heap Information Monitor Tool 」とかで、"WinSta0/Default"とか"SAWinSta/SADesktop"とかが存在するのは
確認できたけど、
どーやってGPFエラーメッセージボックスを意図的に違うデスクトップ空間に出力すんの!!
いや、サービスのプロパティで「デスクトップとの対話をサービスに許可」チェックを入れるとか入れないとかは知ってますけど、
逆に"SAWinSta/SADesktop"に出そうとするとどうすればいいの???
(サービスプログラム自身は"SAWinSta/SADesktop"とかに表示してるのは確認してますよ。
 でも、GPFエラーのメッセージボックスはログインしていると"WinSta0/Default"に表示するんですよね)
プログラムのサブシステム(Console/Window)とかでも動作が違うのかな??
まぁ、結論は"WinSta0/Winlogon"にはアクセスできないから100%はあきらめろってことで。(;一_一)

Hyper-Vを管理コンソールを使わずに・・・

会社環境をHyper-Vにしようとしたときに、クライアントはWindows7ではなくXPが大多数を占めるので、HYper-Vマネージャーが使えない
困った
ということで、何か良い方法がないかと探していると、「vmconnect」なるコマンドがあると。
Hyper-Vマネージャーから「接続」ってしたときと同じ画面ですね。
これでいいかも!と思いましたが・・・・
Hyper-V管理機能をインストールしないと使えません。
(T_T)
(インストール先が「%ProgramFiles%\Hyper-V」です)
とりあえず、電源ON/OFFだけできればOKだから、ASP.NETで管理画面でも作るか?(作れるのか??)

Windows7からのHyper-Vマネージャー接続 and ESET Smart Security

Windows7からWindows Server 2008 R2のHyper-V管理用にHyper-Vマネージャーを入れてみた。
 ping→OK
 リモートデスクトップ接続→OK
 Hyper-Vマネージャー→NG
???接続できない。
しかも、一旦接続できなくなると、pingもリモートデスクトップ接続もNGになって、サーバを再起動ないといけない。
サーバ側のファイアウォールログ(失敗分だけ)を取得するように設定してみても何もログは出力されない。
となると、「クライアント側からそもそも通信していない」ということも考えられる。
Windows 7側にESET Smart Securityを入れているので、ESET Smart Security側のパーソナルファイアウォールのログを見てみると 
 「
ポートスキャニング攻撃が検知されました。」ってある。
 しかも、ソースがサーバのアドレス!!
サーバはインストールしたばかりだから変なもの入れてません。まぁ、Windowsって裏でいろいろ通信しますからねぇ。
たしかに、ESET Smart Securityのファイアウォールを停止するとちゃんと接続できます。
ネットでネタを探してみると、
 ・セキュリティソフトでファイアウォールを装備している場合、一定期間攻撃元との通信を遮断する
 ・ESET Smart Securityの場合、攻撃元(今回はサーバ)が再起動されると攻撃元リストから一旦外れる
ということみたいなので、ESET Smart Securityのパーソナルファイアウォール設定から「IDSと詳細オプション」を選択して、「攻撃を検出したら安全ではないアドレスを遮断」をOFFに変更。
とりあえず、Hyper-Vマネージャーは使えるようになりましたが、セキュリティ設定上はあまりよろしくないかと。
でも、攻撃検知対象から特定アドレスを除外する設定はないっぽいので、どうしようもなく。
※ちなみに、Hyper-Vサーバ自身への接続ができない状態でも、Hyper-V上でホストされている仮想マシンへの接続(リモートデスクトップ接続など)は正常にできます。