自作の逆ジオコーディングサービスをgoogle様にホスティングしていただいていて、それをjavaでもって実装していた。
ちょっと考えがあって実装してみたら実に秒からミリ秒単位への高速化を実現。
最初からやっとけよ!っていう内容なんですけどね。
無料枠と有料枠の端境でDataStoreとInstanceのバランスをとることもうまくいけそうだなあ、なんて年末にホクホク。
で、デプロイしたらとたんに文字化け。12/31早朝に。
データもソースも全部UTF8で固めてあっても。
イヤになるねぇ。Latin1圏がうらやましい。
結論はString.split()。
こいつのソース読んでないけど、これを行うと文字化けする。
やっぱ他人が作ったライブラリはわかんないね。
オブジェクト原理主義者の犯行だな!
ていうかいいよ別にバイト列で・・・
オブジェクト指向だ!!!!!!!とか、肩に力入りすぎ。この言語。
2013年12月31日火曜日
HttpURLConnectionが親切すぎて生きるのがつらい
誰なんですかねえ、こんなオレオレライブラリっぽいのマージしたのは。
自分のアプリだけで使っとけよ!というくらい親切すぎて生きるのがつらい。
getResponceCode()だけでブロックする、というよりread()でブロックする。
ブロックそのものは文句はないんだけど、せめてデータが1バイトでも届いているかチェックするためにinputstreamを取得するだけでブロックする。そこまで面倒を見て下さるなんて感激。
setReadTimeoutが、レスポンスが返ってくるまでの間という大くくりにしか適用できない。
サーバのレスポンスが一定以上だとそもそもreadできない。例外がおきる。
オレオレライブラリの作者には200以外いらなかったのはわかるが、よりによってFileがないよ、っていう例外放り投げるなんてたまげたなあ。超イケテル。
そもそも使うなという評価しか思い浮かばない。
確かにイチからhttpのような原始的なプロトコルの実装を今更やんのかよ、と言いたくなる気持ちもよくわかるけど、こういうオレオレライブラリはSDKから外したほうがいい。
シャリンノサイセイサンガーとかいう人は良く考えたほうがいい。
車輪は回るから車輪であって回らないのは車輪ではない。
無理に回す必要はない。よく回る車輪を作ればいい。
まあ、いろいろ多環境下における仮想環境がらみとかネットに強いアピールが必要だった当時の政治的背景とかあるんでしょうけど。
でもcommitした人に聞いてみたいね。
どう思う?って。
最初からselect()導入しとけばいいのに・・・
当時はなかったとしても、せめてThread.interrupt()できれば使い勝手は向上するとは思うけど、
いったい、だれがこんなもんSDKに忍ばせたんだろう
裏のスレッドでdisconnect()すればキャンセルできるよ!とかへぼすぎでしょ。。。
かくして車輪の再生産が始まるのであった。
自分のアプリだけで使っとけよ!というくらい親切すぎて生きるのがつらい。
getResponceCode()だけでブロックする、というよりread()でブロックする。
ブロックそのものは文句はないんだけど、せめてデータが1バイトでも届いているかチェックするためにinputstreamを取得するだけでブロックする。そこまで面倒を見て下さるなんて感激。
setReadTimeoutが、レスポンスが返ってくるまでの間という大くくりにしか適用できない。
サーバのレスポンスが一定以上だとそもそもreadできない。例外がおきる。
オレオレライブラリの作者には200以外いらなかったのはわかるが、よりによってFileがないよ、っていう例外放り投げるなんてたまげたなあ。超イケテル。
そもそも使うなという評価しか思い浮かばない。
確かにイチからhttpのような原始的なプロトコルの実装を今更やんのかよ、と言いたくなる気持ちもよくわかるけど、こういうオレオレライブラリはSDKから外したほうがいい。
シャリンノサイセイサンガーとかいう人は良く考えたほうがいい。
車輪は回るから車輪であって回らないのは車輪ではない。
無理に回す必要はない。よく回る車輪を作ればいい。
まあ、いろいろ多環境下における仮想環境がらみとかネットに強いアピールが必要だった当時の政治的背景とかあるんでしょうけど。
でもcommitした人に聞いてみたいね。
どう思う?って。
最初からselect()導入しとけばいいのに・・・
当時はなかったとしても、せめてThread.interrupt()できれば使い勝手は向上するとは思うけど、
いったい、だれがこんなもんSDKに忍ばせたんだろう
裏のスレッドでdisconnect()すればキャンセルできるよ!とかへぼすぎでしょ。。。
かくして車輪の再生産が始まるのであった。
2013年12月28日土曜日
android x86 4.2.2版をvmwareで起動する方法
rootでログインしてvmwgfx.koを削除するか新しいものを入手して置換するとよい
例によってlinuxのカーネルオブジェクトの配置はやたら深いところにあるので、find | xargsしてやるとよいと思う
例によってlinuxのカーネルオブジェクトの配置はやたら深いところにあるので、find | xargsしてやるとよいと思う
2013年12月17日火曜日
androidでのsqlite3管理には信じられないバグがある
android4.2.2.でのお話です。
androidでsqlite3を利用しているアプリをアンインストールすると、恐ろしいことにdatabasesディレクトリにroot以外触れないジャーナルが残されて、二度とそのフォルダが使えなくなる場合があります。
例えばadb shell上でlsをとってみると・・・
ディレクトリで、しかも000。
しかもなんだか知りませんが同名のファイルが２つもできてます。
二度と削除できないファイルの豪華同時二本立て。
器用ですねえ。
猛烈にfsckかけたくなりますね。
当然、この端末はrootをとっていないので自分でやっちゃったわけではありません。
システムがおおポカやからしてしまっているわけです。
恐ろしくて使えません・・・というわけにもいきませんので、どうにかしようと思った場合、一応、こんな状況でも、databasesディレクトリはユーザ権限でアクセスできます
mvは可能なので、これを消すために端末初期化とかrootをとるという選択肢は通常はユーザからゆるされることはないので、これでごまかすしかないでしょう。
やっぱり、発展途上のデバイスはｺﾜｲですねぇ
あんまり枯れてない上に、組み込み向けの開発だということを自覚しながら開発しないと。
androidでsqlite3を利用しているアプリをアンインストールすると、恐ろしいことにdatabasesディレクトリにroot以外触れないジャーナルが残されて、二度とそのフォルダが使えなくなる場合があります。
例えばadb shell上でlsをとってみると・・・
# ls -l databases ls -l databases d--------- root root 2013-12-17 10:52 sdb-journal d--------- root root 2013-12-17 10:52 sdb-journal #パーミッションを見ていただけますとわかる通り、全くでたらめです。
ディレクトリで、しかも000。
しかもなんだか知りませんが同名のファイルが２つもできてます。
二度と削除できないファイルの豪華同時二本立て。
器用ですねえ。
猛烈にfsckかけたくなりますね。
当然、この端末はrootをとっていないので自分でやっちゃったわけではありません。
システムがおおポカやからしてしまっているわけです。
恐ろしくて使えません・・・というわけにもいきませんので、どうにかしようと思った場合、一応、こんな状況でも、databasesディレクトリはユーザ権限でアクセスできます
ls -la drwxrwx--x u0_a46 u0_a46 2013-12-17 11:35 databases
mvは可能なので、これを消すために端末初期化とかrootをとるという選択肢は通常はユーザからゆるされることはないので、これでごまかすしかないでしょう。
やっぱり、発展途上のデバイスはｺﾜｲですねぇ
あんまり枯れてない上に、組み込み向けの開発だということを自覚しながら開発しないと。
2013年12月14日土曜日
Windows8.1標準機能のベアドライブバックアップ *追補の追補*
申し訳ございません。また書き忘れていたことを思い出しました。
Windows8.1ではwbadminでバックアップしたディスクをリストアすると、次回バックアップができなくなります。
はい。何を言っているのわかりませんでしょう。
わたくしにもわかりません。
※先月試した時点の話題です。個体差もあるかもしれませんし、現在は改善されているかもしれません。もはや検証する気は起きませんが。
わたくしの場合の状況は、上記のデカい文字で申し上げました通り、リストアは完了した段階で、もう一回バックアップを行おうとするときに
ディスク領域が不足しているため、保存場所にボリュームのシャドウ コピーを作成できません。バックアップするすべてのボリュームについて、シャドウ コピーの作成に必要な最小限のディスク領域が利用可能であることを確認してください。これは、バックアップの保存先と、バックアップに含まれるボリュームの両方について行う必要があります。
とか言われて失敗終了します。
1TBのディスクに対してｶﾗｯﾎﾟの2TBのディスクをバックアップ先を指定しても、です。
要するにうそついてんだよMS。
もーやーだーなーこの会社。
めんどくせえから適当なこといって追っ払っちまえ、っていう態度アリアリ。
まあ、そうはいっても、バックアップができないのは納得がいきません。
このエラーが起きる前後でCAPI2のエラーが続発しているのがイベントログで確認できたので(暗号化サービスで、システム ライター オブジェクトで OnIdentity() の呼び出しを処理中にエラーが発生しました。)、それが原因かと思い、その対処策として提示されている対策を片っ端からとりましたが全く改善しませんでした。
コノ件については、だいぶ時間をかけて散々調べましたが原因が全く分かりませんでした。
数日後、あきらめて、たまたま更新されていたモジュールがあるらしいのでwindows updateかけて再起動したら再度バックアップができるようになりました。
理由は不明です。
ﾃﾞｽｸﾄｯﾌﾟにxlsとかdocのファイルを置きまくっていた人しか喜ばない階層化できない(携帯のhome画面だって階層化できるのに!)スタート画面とか含めて
Windows8.1はOSではなくオモチャ
という結論に達しました。ハイ、ワタクシの無能は思いっきり棚の上に置き忘れています。
坊主憎けりゃナントヤラ。
でも、パッケージとしてWindows8.1を売ってるわけですからねぇ。
カーネルだけ優秀でも・・・ねぇ。
linuxがlinuxだけでは使い道がなくてUbuntuとかRedHatとか派生してくるのと同様の意味で、NTカーネル使ってるからイイっちゅー評価にはどうしても達しえませんでした。
おもちゃ大好きだから私はいいんですが、OSを求める人は購入すべきではありません。
Windows9をお待ちなさい。
悪いこと言わないから。
きっとよくなってますよ、may be
なんかあったかな他に・・・
さすがにうんざりしてこれ以降、あんまりwindowsさわってなかったから・・・
とかいって、また触り始めて全く懲りていないのです。
愉しいですねえトラブル。
脳汁ってんですか、そういうのが出ますね。
一歩間違えると、この年齢ですともうすぐ脳溢血に直結しそうですが。
Windows8.1ではwbadminでバックアップしたディスクをリストアすると、次回バックアップができなくなります。
はい。何を言っているのわかりませんでしょう。
わたくしにもわかりません。
※先月試した時点の話題です。個体差もあるかもしれませんし、現在は改善されているかもしれません。もはや検証する気は起きませんが。
わたくしの場合の状況は、上記のデカい文字で申し上げました通り、リストアは完了した段階で、もう一回バックアップを行おうとするときに
ディスク領域が不足しているため、保存場所にボリュームのシャドウ コピーを作成できません。バックアップするすべてのボリュームについて、シャドウ コピーの作成に必要な最小限のディスク領域が利用可能であることを確認してください。これは、バックアップの保存先と、バックアップに含まれるボリュームの両方について行う必要があります。
とか言われて失敗終了します。
1TBのディスクに対してｶﾗｯﾎﾟの2TBのディスクをバックアップ先を指定しても、です。
要するにうそついてんだよMS。
もーやーだーなーこの会社。
めんどくせえから適当なこといって追っ払っちまえ、っていう態度アリアリ。
まあ、そうはいっても、バックアップができないのは納得がいきません。
このエラーが起きる前後でCAPI2のエラーが続発しているのがイベントログで確認できたので(暗号化サービスで、システム ライター オブジェクトで OnIdentity() の呼び出しを処理中にエラーが発生しました。)、それが原因かと思い、その対処策として提示されている対策を片っ端からとりましたが全く改善しませんでした。
コノ件については、だいぶ時間をかけて散々調べましたが原因が全く分かりませんでした。
数日後、あきらめて、たまたま更新されていたモジュールがあるらしいのでwindows updateかけて再起動したら再度バックアップができるようになりました。
理由は不明です。
ﾃﾞｽｸﾄｯﾌﾟにxlsとかdocのファイルを置きまくっていた人しか喜ばない階層化できない(携帯のhome画面だって階層化できるのに!)スタート画面とか含めて
Windows8.1はOSではなくオモチャ
という結論に達しました。ハイ、ワタクシの無能は思いっきり棚の上に置き忘れています。
坊主憎けりゃナントヤラ。
でも、パッケージとしてWindows8.1を売ってるわけですからねぇ。
カーネルだけ優秀でも・・・ねぇ。
linuxがlinuxだけでは使い道がなくてUbuntuとかRedHatとか派生してくるのと同様の意味で、NTカーネル使ってるからイイっちゅー評価にはどうしても達しえませんでした。
おもちゃ大好きだから私はいいんですが、OSを求める人は購入すべきではありません。
Windows9をお待ちなさい。
悪いこと言わないから。
きっとよくなってますよ、may be
なんかあったかな他に・・・
さすがにうんざりしてこれ以降、あんまりwindowsさわってなかったから・・・
とかいって、また触り始めて全く懲りていないのです。
愉しいですねえトラブル。
脳汁ってんですか、そういうのが出ますね。
一歩間違えると、この年齢ですともうすぐ脳溢血に直結しそうですが。
android端末がsuspendに入らない
界隈じゃdeep sleepとかいうみたいですね。
なんでもいいんですけど。
携帯界隈は用語が特殊で戸惑いますね。ROMとかRAMとか。意味不明。横文字つかっといてさらにわざと誤用とか器用すぎてウラシマには生きるのがつらい。
サービスの起床の是非やスリープするタイミングを調べて、WakeLockが必要なのかどうか検証するため、xperiaでもってTICK_TIMEを受信した時刻をひたすらメモリ上に記録するサービスを作成し、それをbindServiceで任意のタイミングでのぞくアプリを作成してみました(ストレージを使用することによってOSがsuspendを抑止したらいやだから)。
見事に起きてる。ばっちり。
ディスプレイ消灯中がスリープ、という状態なんでしょうが、TICK_TIMEが最大でも数十秒ずれるだけでおおよそ平均1分間隔で受信できてしまっている。
画面点灯中は100ms以内にTIME_TICKが飛んでくるから確かに精度は落ちている。しかし・・・
ただクロック数落としてるだけでしょ、これ。
これ、スリープというより・・・ただの低電力モード?
アプリ自体は稼働してしまってるんだからsleepとはいえんよねぇ。少なくとも寝てない。
なんかほかのアプリがWakeLock離してないのかともおもったけど、「電池使用量」で調べてみてももっとも怪しいgoogle関連のサービスの総「スリープにしない」時間が1時間程度。
うーん、sonyのこの端末はカーネルレベルでsuspend抑止してる?
ホントかなあ?
「電池使用量」の表示欄も、こうなってみるとぁゃιぃね。
起動中、の欄も起動してないことになってるのに、事実こうやってTICK_TIMEを記録しつづけるサービスが動いているのだから(AlarmManagerのWAKEUPも使ってませんよ)。
電池の持ちはいいから、そこは別に文句はないのだけど、もしsuspendしないならWakeLockなんかいらん。
最近の他の端末ではするのだろうか。
位置情報サービスを切ってみたりWiFiを切ってみたりいろいろやってもなんだか寝ない。
もししないなら、もう過去の端末は切り捨ててしまってWakeLockはアプリレベルでは気にしなくていい????
でもそんなことないよなぁ、という気がするなぁ。
逆にKitKatではすぐ寝ちゃってたりするのかもしれない。
古いデバイスでも軽快に!というのが売りだから。
お金あればほかの実機も買って試験できるんだけどなぁ。
金が敵なのに、そのカタキに最近あわねぇんだよなぁ
なんでもいいんですけど。
携帯界隈は用語が特殊で戸惑いますね。ROMとかRAMとか。意味不明。横文字つかっといてさらにわざと誤用とか器用すぎてウラシマには生きるのがつらい。
サービスの起床の是非やスリープするタイミングを調べて、WakeLockが必要なのかどうか検証するため、xperiaでもってTICK_TIMEを受信した時刻をひたすらメモリ上に記録するサービスを作成し、それをbindServiceで任意のタイミングでのぞくアプリを作成してみました(ストレージを使用することによってOSがsuspendを抑止したらいやだから)。
見事に起きてる。ばっちり。
ディスプレイ消灯中がスリープ、という状態なんでしょうが、TICK_TIMEが最大でも数十秒ずれるだけでおおよそ平均1分間隔で受信できてしまっている。
画面点灯中は100ms以内にTIME_TICKが飛んでくるから確かに精度は落ちている。しかし・・・
ただクロック数落としてるだけでしょ、これ。
これ、スリープというより・・・ただの低電力モード?
アプリ自体は稼働してしまってるんだからsleepとはいえんよねぇ。少なくとも寝てない。
なんかほかのアプリがWakeLock離してないのかともおもったけど、「電池使用量」で調べてみてももっとも怪しいgoogle関連のサービスの総「スリープにしない」時間が1時間程度。
うーん、sonyのこの端末はカーネルレベルでsuspend抑止してる?
ホントかなあ?
「電池使用量」の表示欄も、こうなってみるとぁゃιぃね。
起動中、の欄も起動してないことになってるのに、事実こうやってTICK_TIMEを記録しつづけるサービスが動いているのだから(AlarmManagerのWAKEUPも使ってませんよ)。
電池の持ちはいいから、そこは別に文句はないのだけど、もしsuspendしないならWakeLockなんかいらん。
最近の他の端末ではするのだろうか。
位置情報サービスを切ってみたりWiFiを切ってみたりいろいろやってもなんだか寝ない。
もししないなら、もう過去の端末は切り捨ててしまってWakeLockはアプリレベルでは気にしなくていい????
でもそんなことないよなぁ、という気がするなぁ。
逆にKitKatではすぐ寝ちゃってたりするのかもしれない。
古いデバイスでも軽快に!というのが売りだから。
お金あればほかの実機も買って試験できるんだけどなぁ。
金が敵なのに、そのカタキに最近あわねぇんだよなぁ
結局googleに頼ってしまう
この間借りさせていただいているblogサービスもgoogle様のご支配下にありますが、以前google等に頼らず自力で逆ジオコーディング、ということを言っていましたが、結局google様のお慈悲にすがることにしました。
というのは、web apiを利用させていただくのではなく、(逆ジオコーディングにはGoogle Mapと併用しなければ利用できない規約があるためです)Google App Engine ちゅうのがあるってことを知ったからです。
ここは、まあいわばただのホスティングサービスなんですが、おもしろいのは無料であること(!!)、Tomcat(!!!)が利用可能であること。
すなわち、android用に作ったクラスがそのまんま移植作業なしで動いてしまうという点です。
最近まではpyとかだけだったらしいんですが、そこはウラシマですから存じ上げません。
(Cとsedとperlとshばっかりなので全く知りませんでした。 )
さらにすごいのは、httpsをしゃべってくれること(証明書付きで!)
オレオレ証明書ならいくらでも用意できますが、いちいち警告が出るのが(いくら経路を暗号化するだけの目的ですよ、と申し上げたところで )当然不審をそそりますし、だからといって経緯度情報は大切なプライバシですから経路上で暴露しながらパケットが到着しても困ります。
その点、お仕着せのhost名を使う限り信頼済みとなっているのがありがたいです。
市区町村レベルの情報を返すだけとはいえ、そこはインターネットですからその仮想パス上にはNFCとかKFCとかSDKとかAPIとか(あれ?話題のあそこなんだっけ)不思議な団体が目を光らせている可能性は排除しきれません。
受け取るのは携帯からのリクエストを想定している以上、経緯度とIPアドレスといった個人が特定できる情報ですからやはりある程度は神経質にならざるを得ません。
そりゃ証明書を買って自鯖でやったほうがいいに決まってます。
実際、このサービスは無料版の場合、処理速度はandroid実機で処理するのとどっこいどっこい。
DBも特殊。いついきなりサービスを終了するかもわからない。
電気代や回線代の分お得ですが、より柔軟なサーバ側のカスタマイズにも向きません。
でも結局お金がない。これにつきます。
これだけでキラキラ輝いて見えます。
しかもandroidとソースは一緒ですからどちらかメンテすれば自動的にもう一方に適用できるというすばらしさ。
修正モジュール、サーバ側はperl,端末はjavaで同様のロジックを・・・とかだったら鼻血が出ます。
携帯もドメイン管理もホスティングも検索もweb apiもblogも・・・ぜーんぶgoogle・・・
無料DDNSはもうやらないのかなぁ
最後の砦、携帯電話の番号だけはgoogle先生にお教えしておりませんが、携帯メアドはGoogle App Engineに登録する際に教えちゃいました。
どうでもいいけど送信者アドレス指定受信って日本で普及しているの知らないのかなgoogle大先生。日本ではxxx@yyy.zzzからメールが送られるから受信許可しといてねって一言ある商習慣をガン無視。
これがアベノミクスってやつかな。キッシンジャー外交かな?
意地でもMicrosoft accountを作らないアタクシとは思えないほどキモチワルイ状況です。
iOSとどっちだ!ってくらい。
Microsoftも仲間に入りたそうに見ているわけだわなぁ
というのは、web apiを利用させていただくのではなく、(逆ジオコーディングにはGoogle Mapと併用しなければ利用できない規約があるためです)Google App Engine ちゅうのがあるってことを知ったからです。
ここは、まあいわばただのホスティングサービスなんですが、おもしろいのは無料であること(!!)、Tomcat(!!!)が利用可能であること。
すなわち、android用に作ったクラスがそのまんま移植作業なしで動いてしまうという点です。
最近まではpyとかだけだったらしいんですが、そこはウラシマですから存じ上げません。
(Cとsedとperlとshばっかりなので全く知りませんでした。 )
さらにすごいのは、httpsをしゃべってくれること(証明書付きで!)
オレオレ証明書ならいくらでも用意できますが、いちいち警告が出るのが(いくら経路を暗号化するだけの目的ですよ、と申し上げたところで )当然不審をそそりますし、だからといって経緯度情報は大切なプライバシですから経路上で暴露しながらパケットが到着しても困ります。
その点、お仕着せのhost名を使う限り信頼済みとなっているのがありがたいです。
市区町村レベルの情報を返すだけとはいえ、そこはインターネットですからその仮想パス上にはNFCとかKFCとかSDKとかAPIとか(あれ?話題のあそこなんだっけ)不思議な団体が目を光らせている可能性は排除しきれません。
受け取るのは携帯からのリクエストを想定している以上、経緯度とIPアドレスといった個人が特定できる情報ですからやはりある程度は神経質にならざるを得ません。
そりゃ証明書を買って自鯖でやったほうがいいに決まってます。
実際、このサービスは無料版の場合、処理速度はandroid実機で処理するのとどっこいどっこい。
DBも特殊。いついきなりサービスを終了するかもわからない。
電気代や回線代の分お得ですが、より柔軟なサーバ側のカスタマイズにも向きません。
でも結局お金がない。これにつきます。
これだけでキラキラ輝いて見えます。
しかもandroidとソースは一緒ですからどちらかメンテすれば自動的にもう一方に適用できるというすばらしさ。
修正モジュール、サーバ側はperl,端末はjavaで同様のロジックを・・・とかだったら鼻血が出ます。
携帯もドメイン管理もホスティングも検索もweb apiもblogも・・・ぜーんぶgoogle・・・
無料DDNSはもうやらないのかなぁ
最後の砦、携帯電話の番号だけはgoogle先生にお教えしておりませんが、携帯メアドはGoogle App Engineに登録する際に教えちゃいました。
どうでもいいけど送信者アドレス指定受信って日本で普及しているの知らないのかなgoogle大先生。日本ではxxx@yyy.zzzからメールが送られるから受信許可しといてねって一言ある商習慣をガン無視。
これがアベノミクスってやつかな。キッシンジャー外交かな?
意地でもMicrosoft accountを作らないアタクシとは思えないほどキモチワルイ状況です。
iOSとどっちだ!ってくらい。
Microsoftも仲間に入りたそうに見ているわけだわなぁ
地図上に点を打って簡単なポリゴンを作りたい
表題のようなことをしたいなあ、という人はあまりいないかもしれませんが、ここに一人いたので実際にやってみました。
ポリゴンといってもそんな大げさなものではなくて、たとえば大雑把な地図上の地点をクリックしていって経緯度のリストができていれば、それは立派なポリゴンになるわけです。
で、特殊なソフトも入れたくないし、立派な地図も買うほどのものじゃない・・・というときにお役立ちなのが我が国の政府からは利用が制限されているgoogle mapさん。
なにが有用かというと、国内でいうと地図だけならゼンリンさんですが、google mapさん経由で閲覧する以上、プラスアルファがあるわけです。
Google Maps JavaScript API v3 (以下API)が利用できるため、地図とAPIを組み合わせるだけで、目的のものがいともたやすくできてしまいます。
政治上の信念や主張も大切ですが、ここはポリゴンのためです。政府職員でも何でもないわたくしはありがたく使わせていただきましょう。
で、APIなんか使わなくても、もともと特定地点の経緯度は特定の操作をすればすぐわかるようになっています。
ですが、その特定の操作が、連続して経緯度を得るにはちょっと根気がいる作業になってしまうという欠点があります。
そこで、真のプログラマたるもの、楽をしたいならどんな面倒なことでもやる。。。というほどのこともなく、この場合、面倒なことは一切ありません。
ちょっとブラウザ上で動くスクリプトを書けばいいだけで済んでしまいます。APIが整備されているおかげです。
しかも、このAPI、利用するためにgoogleさんに登録の必要がないというすさまじい太っ腹ぶり。シビれますね。
ｺｰﾄﾞを書いたその瞬間からhttpをしゃべるサーバを立てることなく、ﾌﾞﾗｳｻﾞでローカルファイルとして作成したhtmlファイルを表示させてスクリプトを動かすだけで利用できてしまうという点でも助かります。
(「誰でも自由にアクセスできるウェブサイトであれば、無料で利用できるサービスです。」とありますが、さすがにコードを書いてる途中から公開できるわけがなく、ローカルで手軽にテストできるのがうれしいですね)
要点は非常に簡単。それこそその辺のサンプルを拾ってきて(本家のも含めて山ほどあります)、ともかくgoogle mapを表示するってな感じのスクリプトをまずhtmlファイルに追加します。
その時点でもう地図が画面上に表示できているはずです。
アトはもう簡単。クリックされたときに呼ばれるリスナを登録してあげるところだけがミソです。
たとえば
map = new google.maps.Map(document.getElementById("地図表示領域"), mapOptions);
としてmapオブジェクトを作ってあったとすれば、イベントリスナとして
google.maps.event.addListener(map, 'click', function(event) {
func(event.latLng );
});
のようにしてあげると（このjava記法ほんとダイキライ。javascriptトカjavaノトキケッキョクツカッチャウケド)、経緯度がfunc()に渡るのであとはどうでも好きにすればいいわけです。
※念のため、funcはAPIじゃないですよ、自分で定義した関数です。
どこをクリックしたのかわかりやすいようにマーカを表示させ、さらにリスナに渡されるオブジェクトのメンバに経緯度が入っているので、それをどこかに用意した要素(たとえばdiv部など)に
document.getElementById("point_list").innerHTML += location.lat() + "," + location.lng() + "<br/>"
のように追加していくだけで十分メタツールになりえます。
ポリゴンが完成したら、その要素からテキストをコピーすればいいわけです。
凝ろうと思えばいくらでも凝れる、一昔前ではまるで夢物語のような高性能アプリの雛形が、回線インフラと膨大な地図データとAPI(とインフレなPC性能)のおかげでたったの数十行でできてしまいます。
まさにネットウラシマを実感する瞬間です。
ポリゴンといってもそんな大げさなものではなくて、たとえば大雑把な地図上の地点をクリックしていって経緯度のリストができていれば、それは立派なポリゴンになるわけです。
で、特殊なソフトも入れたくないし、立派な地図も買うほどのものじゃない・・・というときにお役立ちなのが我が国の政府からは利用が制限されているgoogle mapさん。
なにが有用かというと、国内でいうと地図だけならゼンリンさんですが、google mapさん経由で閲覧する以上、プラスアルファがあるわけです。
Google Maps JavaScript API v3 (以下API)が利用できるため、地図とAPIを組み合わせるだけで、目的のものがいともたやすくできてしまいます。
政治上の信念や主張も大切ですが、ここはポリゴンのためです。政府職員でも何でもないわたくしはありがたく使わせていただきましょう。
で、APIなんか使わなくても、もともと特定地点の経緯度は特定の操作をすればすぐわかるようになっています。
ですが、その特定の操作が、連続して経緯度を得るにはちょっと根気がいる作業になってしまうという欠点があります。
そこで、真のプログラマたるもの、楽をしたいならどんな面倒なことでもやる。。。というほどのこともなく、この場合、面倒なことは一切ありません。
ちょっとブラウザ上で動くスクリプトを書けばいいだけで済んでしまいます。APIが整備されているおかげです。
しかも、このAPI、利用するためにgoogleさんに登録の必要がないというすさまじい太っ腹ぶり。シビれますね。
ｺｰﾄﾞを書いたその瞬間からhttpをしゃべるサーバを立てることなく、ﾌﾞﾗｳｻﾞでローカルファイルとして作成したhtmlファイルを表示させてスクリプトを動かすだけで利用できてしまうという点でも助かります。
(「誰でも自由にアクセスできるウェブサイトであれば、無料で利用できるサービスです。」とありますが、さすがにコードを書いてる途中から公開できるわけがなく、ローカルで手軽にテストできるのがうれしいですね)
要点は非常に簡単。それこそその辺のサンプルを拾ってきて(本家のも含めて山ほどあります)、ともかくgoogle mapを表示するってな感じのスクリプトをまずhtmlファイルに追加します。
その時点でもう地図が画面上に表示できているはずです。
アトはもう簡単。クリックされたときに呼ばれるリスナを登録してあげるところだけがミソです。
たとえば
map = new google.maps.Map(document.getElementById("地図表示領域"), mapOptions);
としてmapオブジェクトを作ってあったとすれば、イベントリスナとして
google.maps.event.addListener(map, 'click', function(event) {
func(event.latLng );
});
のようにしてあげると（このjava記法ほんとダイキライ。javascriptトカjavaノトキケッキョクツカッチャウケド)、経緯度がfunc()に渡るのであとはどうでも好きにすればいいわけです。
※念のため、funcはAPIじゃないですよ、自分で定義した関数です。
どこをクリックしたのかわかりやすいようにマーカを表示させ、さらにリスナに渡されるオブジェクトのメンバに経緯度が入っているので、それをどこかに用意した要素(たとえばdiv部など)に
document.getElementById("point_list").innerHTML += location.lat() + "," + location.lng() + "<br/>"
のように追加していくだけで十分メタツールになりえます。
ポリゴンが完成したら、その要素からテキストをコピーすればいいわけです。
凝ろうと思えばいくらでも凝れる、一昔前ではまるで夢物語のような高性能アプリの雛形が、回線インフラと膨大な地図データとAPI(とインフレなPC性能)のおかげでたったの数十行でできてしまいます。
まさにネットウラシマを実感する瞬間です。
2013年12月13日金曜日
Windows8.1標準機能のベアドライブバックアップ *追補・重要*
たまたま、過去に書いたことを確認しているうちにとても重要なことを公開し忘れていることに気づきました。
過去、USBメモリではなくUSB接続のHDD(以下USBHDD)にバックアップからの回復用メディアを作ったほうが安心ですよ、と記述いたしましたが、これはMSに限っては嘘です。
USBHDDからシステムを回復しようとした場合、
USBHDDにある回復ドライブを消そうとしてリストアができません。
です。はい。
何を言っているかわからないと思います。
なお、HDDは
状況としては次のようになります。
ここがミソです。
文中にある通り、「現在回復環境を実行しているドライブ」とはUSBHDDのことです。
リストア先にはもはやｶﾗｯﾎﾟのディスクがあるのですが、このｽﾊﾞﾗｼｲリストアソフトはUSBHDDの回復ドライブを消さないとだめだと強硬に言い張るのです。
もう、この会社にはSurfaceユーザと大企業ユーザ以外に相手をする気がないんだと思います。
この画面にたどり着くまでに、バックアップ先のHDDからバックアップデータを選択する必要があります。
ということは、ｶﾗｯﾎﾟのHDDが存在していることはｼｽﾃﾑは知っています。
しかし、そこをリストア先に提案することはありません。
もちろん、バックアップ元はｶﾗｯﾎﾟですからドライブレターが振られず、バックアップ先がCドライブとなってしまっていますから、そこはdiskpartコマンドできちんとZなどに振りなおしてみました。
しかし、やはりリストア先としてｼｽﾃﾑは提案してくれません。
全くの憶測ですが、決め打ちで「回復ドライブから起動したらそこはリストア先」という、なんだか聞くだけで顔が恥ずかしくて真っ赤になるようなｺｰﾄﾞが書かれているのかもしれませんね。
もしくは、無料アップデートした旧Windows8ユーザに対する嫌がらせ・・・？さすがにうがちすぎでしょうか。
なるべくWindows8.1のライセンスごと買ってもらいたい、という思惑なのかもしれません。(メディアだけ購入なんて手段、一般ユーザにはありましたっけ?)
DVDから起動した場合のリストアの場合はこのようなメッセージは現われませんから、（もちろん、以前述べたように)Preview版ISOからのリストアは可能です。
(ただし、Preview版の有効期限が切れた後も回復メディアとして使用できるかどうかまでは、残念ながら検証できていません)
一般のユーザさんがPreview版のISOを焼いているかどうか、そこは疑問ですが・・・
やはりUSBフラッシュメモリを毎度リフレッシュし続けるか、Windows8.1を新規で買えってことで落ち着くのでしょう。
なぜ、リストア先ではない回復ドライブを消去する必要があるのかも不明ですし、ｶﾗｯﾎﾟになっているHDDもあるのに、そこへのリストアという選択肢も示さないのかも不明です。
しかし、マイクロソフトさまの製品を利用させていただく以上、偉大なご意志に従わなければなりません。
せっかく写真もとってあったのに、公開をしていなかったので、急いで追補とさせていただきます。
ほんとどうでもいいけど、そいやあ、なんか知らんがなんかおかね当たるようなキャンペーンやってるけど、これ当たっても、もらうには支払者情報の登録が必要なんだよね。
胡散臭いなあ。アメリカ人ってこういうの割と平気なのかな。facebookとか怖くて登録できない小心者にはキツイなぁ。appleやgoogleだってｺﾜｲのに実績がないMSのストアなんて・・・だから金券くばってんだろうけど。
過去、USBメモリではなくUSB接続のHDD(以下USBHDD)にバックアップからの回復用メディアを作ったほうが安心ですよ、と記述いたしましたが、これはMSに限っては嘘です。
USBHDDからシステムを回復しようとした場合、
USBHDDにある回復ドライブを消そうとしてリストアができません。
です。はい。
何を言っているかわからないと思います。
なお、HDDは
- バックアップ元のHDD
- バックアップ先のHDD
- 回復メディア用に作成するUSBで接続されたHDD
状況としては次のようになります。
- マイクロソフトさまの仰せのとおり回復ドライブを作成する(ただしUSBフラッシュではなくHDD)
- wbadmin、または「システムイメージの作成」でバックアップを取る
- バックアップ元を消す（ここでｶﾗｯﾎﾟのHDDが1つできます)
- 1.で作成した回復ドライブからシステムを起動し、バックアップ先から(元のバックアップ元の)ｶﾗｯﾎﾟのHDDに、リストアをおこな、、、おうとする
ここがミソです。
文中にある通り、「現在回復環境を実行しているドライブ」とはUSBHDDのことです。
リストア先にはもはやｶﾗｯﾎﾟのディスクがあるのですが、このｽﾊﾞﾗｼｲリストアソフトはUSBHDDの回復ドライブを消さないとだめだと強硬に言い張るのです。
もう、この会社にはSurfaceユーザと大企業ユーザ以外に相手をする気がないんだと思います。
この画面にたどり着くまでに、バックアップ先のHDDからバックアップデータを選択する必要があります。
ということは、ｶﾗｯﾎﾟのHDDが存在していることはｼｽﾃﾑは知っています。
しかし、そこをリストア先に提案することはありません。
もちろん、バックアップ元はｶﾗｯﾎﾟですからドライブレターが振られず、バックアップ先がCドライブとなってしまっていますから、そこはdiskpartコマンドできちんとZなどに振りなおしてみました。
しかし、やはりリストア先としてｼｽﾃﾑは提案してくれません。
全くの憶測ですが、決め打ちで「回復ドライブから起動したらそこはリストア先」という、なんだか聞くだけで顔が恥ずかしくて真っ赤になるようなｺｰﾄﾞが書かれているのかもしれませんね。
もしくは、無料アップデートした旧Windows8ユーザに対する嫌がらせ・・・？さすがにうがちすぎでしょうか。
なるべくWindows8.1のライセンスごと買ってもらいたい、という思惑なのかもしれません。(メディアだけ購入なんて手段、一般ユーザにはありましたっけ?)
DVDから起動した場合のリストアの場合はこのようなメッセージは現われませんから、（もちろん、以前述べたように)Preview版ISOからのリストアは可能です。
(ただし、Preview版の有効期限が切れた後も回復メディアとして使用できるかどうかまでは、残念ながら検証できていません)
一般のユーザさんがPreview版のISOを焼いているかどうか、そこは疑問ですが・・・
やはりUSBフラッシュメモリを毎度リフレッシュし続けるか、Windows8.1を新規で買えってことで落ち着くのでしょう。
なぜ、リストア先ではない回復ドライブを消去する必要があるのかも不明ですし、ｶﾗｯﾎﾟになっているHDDもあるのに、そこへのリストアという選択肢も示さないのかも不明です。
しかし、マイクロソフトさまの製品を利用させていただく以上、偉大なご意志に従わなければなりません。
せっかく写真もとってあったのに、公開をしていなかったので、急いで追補とさせていただきます。
ほんとどうでもいいけど、そいやあ、なんか知らんがなんかおかね当たるようなキャンペーンやってるけど、これ当たっても、もらうには支払者情報の登録が必要なんだよね。
胡散臭いなあ。アメリカ人ってこういうの割と平気なのかな。facebookとか怖くて登録できない小心者にはキツイなぁ。appleやgoogleだってｺﾜｲのに実績がないMSのストアなんて・・・だから金券くばってんだろうけど。
2013年12月10日火曜日
経緯度から市区町村名を得たい
googleさんとかのオンラインサービスに頼らず自力で。
実際にやってみました。
国交省さんが公開している国土数値情報 行政区域データというのがおじゃる。
これ、よくできているなあ、と感心したのは、経緯度から市区町村名を得たい、という目的の場合、saxでも後方参照だけで面データに紐づいている市区町村名がわかるようにできていること。
あと、国土地理院みたいな半端なデータじゃなくてちゃんと水界とかも加味して"行政界として"ポリゴンが完結していること。
地味にありがたいよ、これ。
ご丁寧に始点と終点がreferenceになっていて間違いようがないように作ってある。そのreferenceも前方でまとめて定義してあるので、前方参照する手間がない。
実に助かる!
逆に言えば市区町村名から面を得ようとするとsaxでは前方参照が起こってしまうのですが。
saxにこだわるのは、パースしている状況をintな変数1つ+さっき見た要素の値だけで遷移させられるから。
確かに現在どういうことをやっているのかをしっかり管理しないといけないデメリットはありますが、メモリを大幅に節約できることはとても大きい。とくに組み込み機器向けには。
DOM作ったりxpath式で自由自在に取り出すのも結構だけど、それってちょっとリッチ杉。
日本の市区町村って２０００近いもんねぇ。
というわけで、とにかく面白くてandroidでapk経由でデータを持ち込んでgoogle apiを使わないで市区町村名を得るアプリを書いてみたのですが・・・動くんだけど、元ネタファイルがデカすぎてapk形式ではもちづらいんですよねぇ。
assetsに格納してもeclipseさん激おこだし・・・
別個にダウンロードする形式にすれば・・・とか言い出すと、だったら最初から鯖/蔵でいいよねと。
いつ何時有料化されたり打ち切りになってしまうかわからないサービスを利用するのもｺﾜｲんで、ある程度自力でやりたいのですが、肝心の「ある程度」ってのをファイルサイズ的に痛烈に超過してしまっているので存在意義がないレベルまで落ちてしまう。
実際の処理としては本当に単純で、あらかじめ雑なふるい分けのために県単位での矩形を求めておけば47都道府県全部を検索する必要もなく、国外はそもそも検索する必要がない。処理時間としてはあっという間に終わってしまうCPUパワーを携帯ですら持ってる。
ただ結局市区町村を自力で特定するためには膨大なサイズのxmlをどうにかする必要があって、それをバイナリ化するなり自分で工夫する必要が出てきてしまう。
ここで急に一般化できなくなる。
国交省の作った最新ﾌｧｲﾙで置き換えれば市町村合併にだってへっちゃら!なんてことができなくなっちゃう。
独自の変換用フィルタをかませるひつようがあるからねぇ。
結局現実的な対応としてはどっかからサーバと回線調達してきてユーザに必要な都度クエリを投げてもらう、というどっかで見たようなところに落ち着くんですかねぇ。
実は、どいつもこいつも時計の見た目やいい加減な予報(ほとんど曇りとかなんだよそれ。直訳すぎだろ。しかも台風来てても曇りだとか抜かすし)が気に入らないから、自分で時刻・天気予報(ちゃんと気象庁の)・スケジュール(ないけどね)をロックスクリーンに出すandroid向けwidgetを作っていて、できているんだけど、予報地域を手動で設定するより自動がかっこいいよね、と思って作ったらGISデータのほうがむちゃくちゃ大きくなって困ったなあ、ってだけなんですけどね。
実際に動いてはいるんだけど、これじゃ公開もできないよなぁ。
ま、需要はない気もするけど。
あればだれかがとっくに作ってるよね。
自己満足、自己満足。
実際にやってみました。
国交省さんが公開している国土数値情報 行政区域データというのがおじゃる。
これ、よくできているなあ、と感心したのは、経緯度から市区町村名を得たい、という目的の場合、saxでも後方参照だけで面データに紐づいている市区町村名がわかるようにできていること。
あと、国土地理院みたいな半端なデータじゃなくてちゃんと水界とかも加味して"行政界として"ポリゴンが完結していること。
地味にありがたいよ、これ。
ご丁寧に始点と終点がreferenceになっていて間違いようがないように作ってある。そのreferenceも前方でまとめて定義してあるので、前方参照する手間がない。
実に助かる!
逆に言えば市区町村名から面を得ようとするとsaxでは前方参照が起こってしまうのですが。
saxにこだわるのは、パースしている状況をintな変数1つ+さっき見た要素の値だけで遷移させられるから。
確かに現在どういうことをやっているのかをしっかり管理しないといけないデメリットはありますが、メモリを大幅に節約できることはとても大きい。とくに組み込み機器向けには。
DOM作ったりxpath式で自由自在に取り出すのも結構だけど、それってちょっとリッチ杉。
日本の市区町村って２０００近いもんねぇ。
というわけで、とにかく面白くてandroidでapk経由でデータを持ち込んでgoogle apiを使わないで市区町村名を得るアプリを書いてみたのですが・・・動くんだけど、元ネタファイルがデカすぎてapk形式ではもちづらいんですよねぇ。
assetsに格納してもeclipseさん激おこだし・・・
別個にダウンロードする形式にすれば・・・とか言い出すと、だったら最初から鯖/蔵でいいよねと。
いつ何時有料化されたり打ち切りになってしまうかわからないサービスを利用するのもｺﾜｲんで、ある程度自力でやりたいのですが、肝心の「ある程度」ってのをファイルサイズ的に痛烈に超過してしまっているので存在意義がないレベルまで落ちてしまう。
実際の処理としては本当に単純で、あらかじめ雑なふるい分けのために県単位での矩形を求めておけば47都道府県全部を検索する必要もなく、国外はそもそも検索する必要がない。処理時間としてはあっという間に終わってしまうCPUパワーを携帯ですら持ってる。
ただ結局市区町村を自力で特定するためには膨大なサイズのxmlをどうにかする必要があって、それをバイナリ化するなり自分で工夫する必要が出てきてしまう。
ここで急に一般化できなくなる。
国交省の作った最新ﾌｧｲﾙで置き換えれば市町村合併にだってへっちゃら!なんてことができなくなっちゃう。
独自の変換用フィルタをかませるひつようがあるからねぇ。
結局現実的な対応としてはどっかからサーバと回線調達してきてユーザに必要な都度クエリを投げてもらう、というどっかで見たようなところに落ち着くんですかねぇ。
実は、どいつもこいつも時計の見た目やいい加減な予報(ほとんど曇りとかなんだよそれ。直訳すぎだろ。しかも台風来てても曇りだとか抜かすし)が気に入らないから、自分で時刻・天気予報(ちゃんと気象庁の)・スケジュール(ないけどね)をロックスクリーンに出すandroid向けwidgetを作っていて、できているんだけど、予報地域を手動で設定するより自動がかっこいいよね、と思って作ったらGISデータのほうがむちゃくちゃ大きくなって困ったなあ、ってだけなんですけどね。
実際に動いてはいるんだけど、これじゃ公開もできないよなぁ。
ま、需要はない気もするけど。
あればだれかがとっくに作ってるよね。
自己満足、自己満足。
2013年11月11日月曜日
監視したい。とても。とても。
監視したいわけです。
PCを。
ずいぶん前の続きです。
でもって、rrdtoolをHotSaNICからつかうんダヨネとか決定してみたわけですが、HotSaNICそのものはデータを集めてきてrrdtoolに記録をお願いしたり、定期的にホームページ用のｸﾞﾗﾌをrrdtoolにお願いして作っていただいたりしているデーモンなわけです。(perlの!)
ということは、windowsを監視したいンですけど。というときにすべきなのはwindowsからいかにして情報をせしめるか、というだけの話になるわけです。
で、C#、実はずっとずっと昔ASPとかなんとかで業務アプリを作ったことはありますが本職はCなので離れていました。
しかし、OpenHardwareMonitorのｺｰﾄﾞが実に楽し気だったのでそいつでwindows側のエージェントというか問い合わせに答えるプログラムを書いたら半日もたたずにできてしまいました。
なんといっても大きかったのは、C#でWQLを発行するのが異常に楽だという点につきます。
また、streamにgzipをかませることができるので、電文を小さくすることが簡単にできたというのも大きい。
ソケットも扱いが楽で、非同期通信の仕組みもよくできている。bsdソケットとはかけ離れているけど、まさしくwindowsライクなライブラリのつくり。これも組みやすさに大いに寄与しますね。
オブジェクトをnewしたあと作成者が意図した段階でdeleteできない、こういうたぐいのCGつき言語のモヤモヤ感は否めませんが、javaよりずっと使いやすい言語ですね。
あとはHotSaNIC側で問い合わせスクリプトを書くだけです。
肝は以下のWQLでしょう。
DISKIO
こいつはwindowsが持つパフォーマンスデータからディスクの稼働状況を取得します。
なお、後置詞にPersecとか書いてあるメンバがありますが、これは嘘です。
累計された数値です。したがって、オーバーフロー対策は必要です。
(root/cimv2)
select
DiskWritesPersec, -- ディスク書き込み回数
DiskReadsPersec, -- 読み込み回数
Timestamp_PerfTime, -- 現在のPC側の時間(tick)
Frequency_PerfTime, -- １秒当たりのtick数
DiskReadBytesPersec, -- ディスク読み込みバイト数
DiskWriteBytesPersec, -- 書き込みバイト数
Name -- デバイス名
from
Win32_PerfRawData_PerfDisk_PhysicalDisk
上記が分かれば、単位時間当たりのリード・ライト回数と転送レートが計算できます。
もっとざっくりやりたければ、tick時間なんか無視して、前回問い合わせ時間～今回問い合わせ時間は問い合わせした側が分かっているわけですから、Timestamp_PerfTimeと
Frequency_PerfTimeは無視してもよいでしょう。
NETWORK TRAFFIC
NICの転送量を取得します。
これもPersecはper secondを意味しません。
(root/cimv2)
select
Name, --デバイス名
BytesReceivedPersec, --受信バイト数
BytesSentPersec, --送信バイト数
PacketsReceivedPersec, --受信パケット数
PacketsSentPersec --送信パケット数
from
Win32_PerfRawData_Tcpip_NetworkInterface
これもDISKIOと同様、どんどん累計していきますから単位時間当たりのリード・ライト回数と転送レートが計算できます。
問合せ間隔を基準にするなら、その間の平均転送量が分かりますね。
DISK消費量
まあ、これは言うまでもないですね。
(root/cimv2)
select
Caption,
FreeSpace,
Size
from
Win32_LogicalDisk
CPU負荷
こいつも言うまでもないでしょうが、一つ違いは論理コア数分と、トータルの平均が取れるというところでしょう。
(root/cimv2)
select
name, -- Where句で指定した名前
PercentIdleTime, -- アイドル時間の割合
PercentUserTime, -- ユーザ時間
PercentPrivilegedTime, -- カーネル時間(みたいなもんだ)
PercentInterruptTime -- 割り込み処理で費やした時間
from
Win32_PerfRawData_PerfOS_Processor
where
name='_Total';
私のPCはCore i7なので8+1の9種類の情報を取ってきます。
where句でnameに_Totalを指定すれば平均、0~7を指定すれば各論理コアの値が取れます。
上記の例では平均をとってきます。
ただ、これだけとっても問い合わせた時のスナップショットですから、表現には一工夫いるでしょう。
メモリ使用状況
こいつも言うまでもありませんね。メンバ名（RDB式に言えばカラム名)そのまんまの値をとってきます。
(root/cimv2)
select
FreePhysicalMemory,
TotalVisibleMemorySize,
TotalVirtualMemorySize,
FreeVirtualMemory
from
Win32_OperatingSystem
惜しむらくは、物理メモリ上にキャッシュされた容量を取得する方法を探しきれなかったことです。
タスクマネージャでは表示しているので、どこかにそういった情報を計算できる元ネタがあるはずなのですが・・・
特にWindowsNT6.0たるVistaからキャッシュが登場して以来、以後ますます洗練されてきており、WindowsNT6.2たるWindows8、6.3たる8.1(ややこしいな)でのｸﾞﾗﾌは面白かろうと思ったのですが。
まあ、仮想メモリと物理メモリの利用量が分かれば、swapされた量もわかりますから、まずよしとしましょう。
連続稼働時間
これも、まあそのまんまです。
(root/cimv2)
select
LastBootUpTime
from
Win32_OperatingSystem
この値と現在時刻を比較すればすぐわかります。
但し、スリープ中の時間を差し引くかどうかは考えどころです。
とはいえ、スリープ中はエージェントも応答できませんから、ｸﾞﾗﾌに欠落ができます。
それを見れば一発でわかるという考え方もありますね。
まあ、スリープ中もｼｽﾃﾑは停止しているわけではありませんから、累積させる方向がよいでしょう。
HDD温度
さてお待ちかね、ここからがsmartmontoolsとOpenHardwareMonitorの出番です。
(root/openhardwaremonitor)
select
Parent, -- ドライブの種別
Value -- 温度
from
sensor
where
sensortype='Temperature' and Parent='/hdd/0'
実を言うと、Windows8のころはOpenHardwareMonitorでは温度は取得できていませんでした。
ですが、怪しかったIntelのHDD管理ツールをWindows8.1にはあえてインストールしませんでした。
すると、OpenHardwareMonitorで温度が取得できることを確認しました。
そこで、8まではsmartmontoolsのコマンドをたたく方式でクライアントを作っていましたが、サーバ側のスクリプトを変更してWQLを発行するように変更しました。
where句にsensortypeとparentがありますが、sensortypeは温度を指定します。Parent句にはWindowsでいうところのUNCパスで表現されるドライブ番号を利用して指定します。
disk0なら/hdd/0 といった具合です。
CPU,GPUクロック、温度、ファン回転数
ここは画面の都合上一気に取得します。
(root/openhardwaremonitor)
select
name, -- 名称
sensortype, -- センサのタイプ
value -- 値
from
sensor
where
sensortype = 'Temperature' or sensortype = 'Fan' or sensortype = 'Clock'
上記のクエリを発行すると、一気にCPUのパッケージ温度、コアごとの温度とクロック数、GPUの温度とクロック数、GPU,CPUおよびケース・電源ファンの回転数を取得することができます。
以上を収集しておけば、ｸﾞﾗﾌを見てニヤつくには十分でしょう。
これら収集したデータを、もともとHotSaNICが収集している元ネタに置き換えるだけで完成です。
実際に作成された一か月半分のｸﾞﾗﾌをお見せしたいところですが、なにせ監視対象がPCだけあってPCを操作している時間がまるわかりなため、お見せすることができません。
PC側のエージェントは私の管理下にありますからご希望の方があれば無保証無ｻﾎﾟｰﾄで差し上げることができます。
HotSaNIC側のライセンスがはっきりしないのでこちらはそのままお分けできませんが、私が書いたｺｰﾄﾞ分についてはお分けすることができます。ただし若干の書き換えが必要になります(問い合わせ先のマシン名や設定ファイルなど。HotSaNICに対する知識はある程度必要になるでしょう)。
当然こちらも無保証無ｻﾎﾟｰﾄとなりますが、まあどちらもそんなもんいらないよね。
ｸﾞﾗﾌを見てニヤつけるような人には。
春夏秋冬の移り変わりを感じることもできますよ。
あなたも是非、監視するまでもないマシンの諸元をｸﾞﾗﾌ化してみよう!
PCを。
ずいぶん前の続きです。
でもって、rrdtoolをHotSaNICからつかうんダヨネとか決定してみたわけですが、HotSaNICそのものはデータを集めてきてrrdtoolに記録をお願いしたり、定期的にホームページ用のｸﾞﾗﾌをrrdtoolにお願いして作っていただいたりしているデーモンなわけです。(perlの!)
ということは、windowsを監視したいンですけど。というときにすべきなのはwindowsからいかにして情報をせしめるか、というだけの話になるわけです。
で、C#、実はずっとずっと昔ASPとかなんとかで業務アプリを作ったことはありますが本職はCなので離れていました。
しかし、OpenHardwareMonitorのｺｰﾄﾞが実に楽し気だったのでそいつでwindows側のエージェントというか問い合わせに答えるプログラムを書いたら半日もたたずにできてしまいました。
なんといっても大きかったのは、C#でWQLを発行するのが異常に楽だという点につきます。
また、streamにgzipをかませることができるので、電文を小さくすることが簡単にできたというのも大きい。
ソケットも扱いが楽で、非同期通信の仕組みもよくできている。bsdソケットとはかけ離れているけど、まさしくwindowsライクなライブラリのつくり。これも組みやすさに大いに寄与しますね。
オブジェクトをnewしたあと作成者が意図した段階でdeleteできない、こういうたぐいのCGつき言語のモヤモヤ感は否めませんが、javaよりずっと使いやすい言語ですね。
あとはHotSaNIC側で問い合わせスクリプトを書くだけです。
肝は以下のWQLでしょう。
DISKIO
こいつはwindowsが持つパフォーマンスデータからディスクの稼働状況を取得します。
なお、後置詞にPersecとか書いてあるメンバがありますが、これは嘘です。
累計された数値です。したがって、オーバーフロー対策は必要です。
(root/cimv2)
select
DiskWritesPersec, -- ディスク書き込み回数
DiskReadsPersec, -- 読み込み回数
Timestamp_PerfTime, -- 現在のPC側の時間(tick)
Frequency_PerfTime, -- １秒当たりのtick数
DiskReadBytesPersec, -- ディスク読み込みバイト数
DiskWriteBytesPersec, -- 書き込みバイト数
Name -- デバイス名
from
Win32_PerfRawData_PerfDisk_PhysicalDisk
上記が分かれば、単位時間当たりのリード・ライト回数と転送レートが計算できます。
もっとざっくりやりたければ、tick時間なんか無視して、前回問い合わせ時間～今回問い合わせ時間は問い合わせした側が分かっているわけですから、Timestamp_PerfTimeと
Frequency_PerfTimeは無視してもよいでしょう。
NETWORK TRAFFIC
NICの転送量を取得します。
これもPersecはper secondを意味しません。
(root/cimv2)
select
Name, --デバイス名
BytesReceivedPersec, --受信バイト数
BytesSentPersec, --送信バイト数
PacketsReceivedPersec, --受信パケット数
PacketsSentPersec --送信パケット数
from
Win32_PerfRawData_Tcpip_NetworkInterface
これもDISKIOと同様、どんどん累計していきますから単位時間当たりのリード・ライト回数と転送レートが計算できます。
問合せ間隔を基準にするなら、その間の平均転送量が分かりますね。
DISK消費量
まあ、これは言うまでもないですね。
(root/cimv2)
select
Caption,
FreeSpace,
Size
from
Win32_LogicalDisk
CPU負荷
こいつも言うまでもないでしょうが、一つ違いは論理コア数分と、トータルの平均が取れるというところでしょう。
(root/cimv2)
select
name, -- Where句で指定した名前
PercentIdleTime, -- アイドル時間の割合
PercentUserTime, -- ユーザ時間
PercentPrivilegedTime, -- カーネル時間(みたいなもんだ)
PercentInterruptTime -- 割り込み処理で費やした時間
from
Win32_PerfRawData_PerfOS_Processor
where
name='_Total';
私のPCはCore i7なので8+1の9種類の情報を取ってきます。
where句でnameに_Totalを指定すれば平均、0~7を指定すれば各論理コアの値が取れます。
上記の例では平均をとってきます。
ただ、これだけとっても問い合わせた時のスナップショットですから、表現には一工夫いるでしょう。
メモリ使用状況
こいつも言うまでもありませんね。メンバ名（RDB式に言えばカラム名)そのまんまの値をとってきます。
(root/cimv2)
select
FreePhysicalMemory,
TotalVisibleMemorySize,
TotalVirtualMemorySize,
FreeVirtualMemory
from
Win32_OperatingSystem
惜しむらくは、物理メモリ上にキャッシュされた容量を取得する方法を探しきれなかったことです。
タスクマネージャでは表示しているので、どこかにそういった情報を計算できる元ネタがあるはずなのですが・・・
特にWindowsNT6.0たるVistaからキャッシュが登場して以来、以後ますます洗練されてきており、WindowsNT6.2たるWindows8、6.3たる8.1(ややこしいな)でのｸﾞﾗﾌは面白かろうと思ったのですが。
まあ、仮想メモリと物理メモリの利用量が分かれば、swapされた量もわかりますから、まずよしとしましょう。
連続稼働時間
これも、まあそのまんまです。
(root/cimv2)
select
LastBootUpTime
from
Win32_OperatingSystem
この値と現在時刻を比較すればすぐわかります。
但し、スリープ中の時間を差し引くかどうかは考えどころです。
とはいえ、スリープ中はエージェントも応答できませんから、ｸﾞﾗﾌに欠落ができます。
それを見れば一発でわかるという考え方もありますね。
まあ、スリープ中もｼｽﾃﾑは停止しているわけではありませんから、累積させる方向がよいでしょう。
HDD温度
さてお待ちかね、ここからがsmartmontoolsとOpenHardwareMonitorの出番です。
(root/openhardwaremonitor)
select
Parent, -- ドライブの種別
Value -- 温度
from
sensor
where
sensortype='Temperature' and Parent='/hdd/0'
実を言うと、Windows8のころはOpenHardwareMonitorでは温度は取得できていませんでした。
ですが、怪しかったIntelのHDD管理ツールをWindows8.1にはあえてインストールしませんでした。
すると、OpenHardwareMonitorで温度が取得できることを確認しました。
そこで、8まではsmartmontoolsのコマンドをたたく方式でクライアントを作っていましたが、サーバ側のスクリプトを変更してWQLを発行するように変更しました。
where句にsensortypeとparentがありますが、sensortypeは温度を指定します。Parent句にはWindowsでいうところのUNCパスで表現されるドライブ番号を利用して指定します。
disk0なら/hdd/0 といった具合です。
CPU,GPUクロック、温度、ファン回転数
ここは画面の都合上一気に取得します。
(root/openhardwaremonitor)
select
name, -- 名称
sensortype, -- センサのタイプ
value -- 値
from
sensor
where
sensortype = 'Temperature' or sensortype = 'Fan' or sensortype = 'Clock'
上記のクエリを発行すると、一気にCPUのパッケージ温度、コアごとの温度とクロック数、GPUの温度とクロック数、GPU,CPUおよびケース・電源ファンの回転数を取得することができます。
以上を収集しておけば、ｸﾞﾗﾌを見てニヤつくには十分でしょう。
これら収集したデータを、もともとHotSaNICが収集している元ネタに置き換えるだけで完成です。
実際に作成された一か月半分のｸﾞﾗﾌをお見せしたいところですが、なにせ監視対象がPCだけあってPCを操作している時間がまるわかりなため、お見せすることができません。
PC側のエージェントは私の管理下にありますからご希望の方があれば無保証無ｻﾎﾟｰﾄで差し上げることができます。
HotSaNIC側のライセンスがはっきりしないのでこちらはそのままお分けできませんが、私が書いたｺｰﾄﾞ分についてはお分けすることができます。ただし若干の書き換えが必要になります(問い合わせ先のマシン名や設定ファイルなど。HotSaNICに対する知識はある程度必要になるでしょう)。
当然こちらも無保証無ｻﾎﾟｰﾄとなりますが、まあどちらもそんなもんいらないよね。
ｸﾞﾗﾌを見てニヤつけるような人には。
春夏秋冬の移り変わりを感じることもできますよ。
あなたも是非、監視するまでもないマシンの諸元をｸﾞﾗﾌ化してみよう!
HAXMのパッチは出ていますよ
あまり話題になっていないようなので一言。
注視していた方には既報となると思います。
Androidのエミュレータとして利用率が高いと思われるIntel謹製のアレ、MacOS10.9やらWin8.1やらでOSごとクラッシュしてしまう問題がありましたが、そのパッチはIntelから出ています。
最新版は1.0.6となっていますが、これがクラッシュします。
Hotfixで1.0.7がリリースされておりますので、該当OSで開発したりニヤニヤしておられるかたは1.0.6を削除後、1.0.7を入れてください。
以下がHotfixへのリンクです。
http://software.intel.com/en-us/articles/intel-hardware-accelerated-execution-manager-end-user-license-agreement-windows-hotfix
私もwin8.1に入れましたが、確かにBSODも出ずにこれまで通りの使い勝手で助かります。
Thank you! Mr.Weggele
注視していた方には既報となると思います。
Androidのエミュレータとして利用率が高いと思われるIntel謹製のアレ、MacOS10.9やらWin8.1やらでOSごとクラッシュしてしまう問題がありましたが、そのパッチはIntelから出ています。
最新版は1.0.6となっていますが、これがクラッシュします。
Hotfixで1.0.7がリリースされておりますので、該当OSで開発したりニヤニヤしておられるかたは1.0.6を削除後、1.0.7を入れてください。
以下がHotfixへのリンクです。
http://software.intel.com/en-us/articles/intel-hardware-accelerated-execution-manager-end-user-license-agreement-windows-hotfix
私もwin8.1に入れましたが、確かにBSODも出ずにこれまで通りの使い勝手で助かります。
Thank you! Mr.Weggele
2013年11月10日日曜日
windows8.1へのアップグレード時の注意喚起
*** ご注意 2015/9/14 追補 ***
当ブログでも相当数な参照をいただいている記事ですので、さらに注意事項を追補させていただきます。
以下の記事は2013/11/10当時のものですが、2015年にWindows10が発表されました。
何の対策もせずにWindows8から8.1を経由してWindows10へアップグレードを行うと、回復パーティションが3つに増殖する場合があります。
その状況と、あらかじめパーティションを切る方法をこちらでご紹介しておりますので、よろしければご参考いただければと思います。
*** 追補ここまで ***
windows8からストア経由で8.1へアップグレードを行う際に注意したいことがあります。
UEFI起動でHDDのサイズが1TBのものでしか検証していませんが、前提条件通りにすると必ず回復パーティションが2つできるという点です。
前提条件として、まっさらなHDDにwindows8をインストールし、windows updateをかけた後すぐに8.1へアップグレードするものとします。
なお、もともとの回復パーティションが大きくとられていた場合には発生しませんが、私のようにクリーンインストール直後、すぐに8.1へアップグレードするような人は足をすくわれる可能性があります。
つまり、メーカー製のPCではなく巨大な回復パーティションやリカバリパーティションを含まないPC、自分で組み上げたPCやパーツ組み上げタイプのBTOショップブランドPCということです。
メーカー製のPCをご利用の方にはこんな情報はいらないでしょうし。
HDDサイズによって異なる可能性がありますが、1TBのHDDの場合、windows8をクリーンインストールすると回復パーティションが300MB、HDDの先頭に作成されます。
8.1へアップグレードすると、その300MBの回復パーティションとは別に363MBの回復パーティションが、なんと、システムが入ったパーティションより後ろに作られてしまいます。
なにが「なんと」かというと、回復パーティションやEFI領域もシステム領域より前にあるというのは、それに続くシステムやデータ用のパーティションサイズを制限させない配慮なわけです(もちろん、GPTでなけばMBR上の制限という理由もあるだろうがここではUEFI起動のお話)
それなのに後ろにできてしまうとどうなるか。
将来、HDDを換装したりしてパーティションサイズを大きくしたくてもできなくなるということです。
２つあるのはどういうことだ、ということで、実際に回復ドライブとしてシステムに認識されているのはどちらか、あるいは両方か、と調べてみると、300MBのほうは全く無視。
バックアップをとっても300MBのほうのドライブはバックアップされないし、reagentc.exeという回復パーティションがらみのツールでも調べることができる。
たとえばこんな感じ。
BIOS起動の人はブート構成データ (BCD) IDは7か27。
で、partition5ってのは、
しかも回復パーティションは、ディスクアドミニストレータでは操作不能。
開放もできないしドライブレターを振ることもできない。
diskpart.exeでは可能なので、早速両者をマウントして中身を見てみたら、300MBのほう(win8で作られたほう)はからっぽ。まったく使われていない。
では363MBのほうから中身をコピーしようとすると、わずか2.4MBほど足りずにコピー不能。
MSの言い分としては「300MBでは足りないし、アップグレード元のパーティションの先頭もずらせない。だから末尾をちょっと拝借したんだ」ということでしょうが、ふざけるなと言いたい。
最初から注意喚起すべきだし、もとの300MBは使っていない完全な死に領域となっている。
まあ、容量はどうでもいいとして、やはり一番の問題はパーティションサイズが制限される、ということが大きいでしょう。
どうせ画像の1枚でも減らせば300MBに収まるんだろうなぁ。
これはもっと大きい回復ドライブの容量をとってあっても、肥大化したwinre.wim(リカバリ用のミニWindowsNTのパッケージ。272MBもあった)を収められないと、まるまる後ろに新規回復パーティションとして取られた上に元の回復ドライブはからのまま、あるいは272MBしかないwinre.wimがぽつんとあるまま、元の容量そのままに放置されます(見た目のディスク容量が劇的に減ります)。
と、いうわけで、すぐにアップグレードしてしまうと面倒の種をまくことになりますよ、というお話。
8.1にアップグレードする前に回復パーティションのサイズを大きくとっておくことをお勧めします。
当ブログでも相当数な参照をいただいている記事ですので、さらに注意事項を追補させていただきます。
以下の記事は2013/11/10当時のものですが、2015年にWindows10が発表されました。
何の対策もせずにWindows8から8.1を経由してWindows10へアップグレードを行うと、回復パーティションが3つに増殖する場合があります。
その状況と、あらかじめパーティションを切る方法をこちらでご紹介しておりますので、よろしければご参考いただければと思います。
*** 追補ここまで ***
windows8からストア経由で8.1へアップグレードを行う際に注意したいことがあります。
UEFI起動でHDDのサイズが1TBのものでしか検証していませんが、前提条件通りにすると必ず回復パーティションが2つできるという点です。
前提条件として、まっさらなHDDにwindows8をインストールし、windows updateをかけた後すぐに8.1へアップグレードするものとします。
なお、もともとの回復パーティションが大きくとられていた場合には発生しませんが、私のようにクリーンインストール直後、すぐに8.1へアップグレードするような人は足をすくわれる可能性があります。
つまり、メーカー製のPCではなく巨大な回復パーティションやリカバリパーティションを含まないPC、自分で組み上げたPCやパーツ組み上げタイプのBTOショップブランドPCということです。
メーカー製のPCをご利用の方にはこんな情報はいらないでしょうし。
HDDサイズによって異なる可能性がありますが、1TBのHDDの場合、windows8をクリーンインストールすると回復パーティションが300MB、HDDの先頭に作成されます。
8.1へアップグレードすると、その300MBの回復パーティションとは別に363MBの回復パーティションが、なんと、システムが入ったパーティションより後ろに作られてしまいます。
なにが「なんと」かというと、回復パーティションやEFI領域もシステム領域より前にあるというのは、それに続くシステムやデータ用のパーティションサイズを制限させない配慮なわけです(もちろん、GPTでなけばMBR上の制限という理由もあるだろうがここではUEFI起動のお話)
それなのに後ろにできてしまうとどうなるか。
将来、HDDを換装したりしてパーティションサイズを大きくしたくてもできなくなるということです。
２つあるのはどういうことだ、ということで、実際に回復ドライブとしてシステムに認識されているのはどちらか、あるいは両方か、と調べてみると、300MBのほうは全く無視。
バックアップをとっても300MBのほうのドライブはバックアップされないし、reagentc.exeという回復パーティションがらみのツールでも調べることができる。
たとえばこんな感じ。
C:\WINDOWS\system32>reagentc /info Windows 回復環境 (Windows RE) およびシステム リセット構成 情報: Windows RE の状態: Enabled Windows RE の場所: \\?\GLOBALROOT\device\harddisk0\partition5\Recovery\WindowsRE ブート構成データ (BCD) ID: ef09b8f3-3897-11e3-85cc-8445ca12688c 回復イメージの場所: 回復イメージ インデックス: 0 カスタム イメージの場所: カスタム イメージ インデックス: 0 REAGENTC.EXE: 操作は成功しました。
BIOS起動の人はブート構成データ (BCD) IDは7か27。
で、partition5ってのは、
- win8で作られた回復パーティション
- EFIｼｽﾃﾑパーティション
- MSR
- ｼｽﾃﾑドライブ(windows8.1が入ってるところ)
- 8.1アップグレード時に4の領域からちょろまかした回復パーティション
しかも回復パーティションは、ディスクアドミニストレータでは操作不能。
開放もできないしドライブレターを振ることもできない。
diskpart.exeでは可能なので、早速両者をマウントして中身を見てみたら、300MBのほう(win8で作られたほう)はからっぽ。まったく使われていない。
では363MBのほうから中身をコピーしようとすると、わずか2.4MBほど足りずにコピー不能。
MSの言い分としては「300MBでは足りないし、アップグレード元のパーティションの先頭もずらせない。だから末尾をちょっと拝借したんだ」ということでしょうが、ふざけるなと言いたい。
最初から注意喚起すべきだし、もとの300MBは使っていない完全な死に領域となっている。
まあ、容量はどうでもいいとして、やはり一番の問題はパーティションサイズが制限される、ということが大きいでしょう。
どうせ画像の1枚でも減らせば300MBに収まるんだろうなぁ。
これはもっと大きい回復ドライブの容量をとってあっても、肥大化したwinre.wim(リカバリ用のミニWindowsNTのパッケージ。272MBもあった)を収められないと、まるまる後ろに新規回復パーティションとして取られた上に元の回復ドライブはからのまま、あるいは272MBしかないwinre.wimがぽつんとあるまま、元の容量そのままに放置されます(見た目のディスク容量が劇的に減ります)。
と、いうわけで、すぐにアップグレードしてしまうと面倒の種をまくことになりますよ、というお話。
8.1にアップグレードする前に回復パーティションのサイズを大きくとっておくことをお勧めします。
2013年11月9日土曜日
Windows8.1標準機能のベアドライブバックアップ *番外編*
windows8のインストールディスクを使用してwindows8.1をリストアも試みました。
結論としては「できない」。
ここまでは、ああ、そうですか。ってなもんで。
ただ、ここからが面白い。
「できない」ことを教えてくれるタイミングがお粗末。
まず、windows8のインストールディスクで起動し、イメージのリストアを試みようとすると、windows8.1のバックアップデータがリストアできるように表示され、選択もできます。
それどころか、リストアを開始できてしまいます。
但し、実行直後抑止され、エラーメッセージが表示されます。
ところが、この前段階として「パーティションを開放して切りなおす」というオプションを選択することができます。
そして、実際に解放されてから「リカバリできないよ」と、くるわけです。
パーティションを開放してしまえば、通常の手段ではもう復旧不可能です。
その後、選択肢として「このままwindows8.1を起動する」なんて項目が選べますが、まあ、どうやるんすかね。(当然できません)
確かにリストア対象のディスクだから問題は顕在化しにくいが、ロールバックできないほど致命的な手を加えた後に「できませんでした、でももう元の状態には戻せません」、というのは工業製品として最低だろ。
テストしてねえな、これ。
本当はwindows8のDVDでもリストアできるようにするつもりだったのな。(そんなわけがないか)
あるいはwindows7でも同様な結果になるかは未検証。
Windows8.1標準機能のベアドライブバックアップ リストア
windows8.1のwbadmin.exeで作成したバックアップデータの復旧方法。
システムがオンラインのままリストアはできません。
また、一部のみの復旧もできません。
その場合はバックアップデータのディスクイメージをOS上でマウントして、必要なファイルを取り出します。
また、バックアップした時のOSの起動方法がBIOSかUEFIであるかは重要です。
リストア時に起動するリカバリメディアの起動方法も同一である必要があります。
復旧用メディアから起動し、詳細オプションを選ぶと「イメージでシステムを回復」という選択肢が得られますから、それを選択することによってバックアップデータをリストアできます。
当然復旧先のディスクのサイズは、バックアップ時のものと同等かそれ以上必要ですし、同一のシステム以外にリストアしたところで動作はしません。
上記条件は以下に述べる手段で同一です。
以下の手段があります。
(私の環境はUEFI環境なのでBIOS環境はわかりません。)
1番目はHDDがぶっ壊れたことを想定したので問題外、3番目はDVDがないので検証不能です。
システムの入ったHDDをいったん消去し、Preview版をDVDに焼いて起動し、リストアしてから数日経ちますが、問題は起きていません。
ただし、リストア直後、WindowsUpdateの設定が、実際には手動更新になっているはずにもかかわらず自動的に行うかのように表示される場合がありました。すぐ直りましたが。
4番目の(3番目もそうでしょうが)「今すぐインストール」と選択できる画面の左下部に「コンピューターを修復する」という選択肢を選択することで、1や2と同様な画面に遷移するので、そこでイメージからリストアすれば完了です。
windows8.1のインストールメディアがない人は、こういった方法もあるということで。
システムがオンラインのままリストアはできません。
また、一部のみの復旧もできません。
その場合はバックアップデータのディスクイメージをOS上でマウントして、必要なファイルを取り出します。
また、バックアップした時のOSの起動方法がBIOSかUEFIであるかは重要です。
リストア時に起動するリカバリメディアの起動方法も同一である必要があります。
復旧用メディアから起動し、詳細オプションを選ぶと「イメージでシステムを回復」という選択肢が得られますから、それを選択することによってバックアップデータをリストアできます。
当然復旧先のディスクのサイズは、バックアップ時のものと同等かそれ以上必要ですし、同一のシステム以外にリストアしたところで動作はしません。
上記条件は以下に述べる手段で同一です。
以下の手段があります。
- ※未検証
(HDD上にある回復パーティションから起動する)
ま、そりゃそうですわな。
OSが起動しなくなったが回復パーティションは生きているなどの場合、別メディアを使わずリストアできます。 - USBに保存した回復ドライブを使う
「コントロール パネル\システムとセキュリティ\ファイル履歴」
の左側に「回復」という素っ気もないメニューを選ぶと、回復ドライブが作れます。
そこで作成したUSBデバイスから起動すると、1.と同様のﾒﾆｭｰが起動します。 - ※未検証
(Windows8.1のインストール用DVDから起動する)
私はWindows8からのアップデート組なのでこれはできませんが、8.1を直接購入された方は一番オーソドックスな方法でしょう。 - Windows8.1Preview版のDVDから起動する
実はこれが言いたかった。
(私の環境はUEFI環境なのでBIOS環境はわかりません。)
1番目はHDDがぶっ壊れたことを想定したので問題外、3番目はDVDがないので検証不能です。
システムの入ったHDDをいったん消去し、Preview版をDVDに焼いて起動し、リストアしてから数日経ちますが、問題は起きていません。
ただし、リストア直後、WindowsUpdateの設定が、実際には手動更新になっているはずにもかかわらず自動的に行うかのように表示される場合がありました。すぐ直りましたが。
4番目の(3番目もそうでしょうが)「今すぐインストール」と選択できる画面の左下部に「コンピューターを修復する」という選択肢を選択することで、1や2と同様な画面に遷移するので、そこでイメージからリストアすれば完了です。
windows8.1のインストールメディアがない人は、こういった方法もあるということで。
Windows8.1標準機能のベアドライブバックアップ wbadmin
Windows8.1の標準機能を用いてシステムごとバックアップを行う方法は二通りあります。
GUIによる方法とCUI(コマンドライン)で行う方法です。
このうち、GUIで行う方法はバックアップを行うたびに手動で操作が必要になります。
もちろん、要所要所で手動でバックアップしておき、データだけは自動でどこかにコピーしておけばいいわけで、これはこれで十分でしょう。
ですが、その要所要所ってのが実際にはあやしい。
要所に手を加えたということは、その変更が必要だったからで、なんで変更が必要になったかといえば仕事や遊びでも、その需要があって変更をしているわけですから、バックアップなんかに時間をとられるのもどうかなと。
ですので、こちらが意識せずシステム側で定期的に全体のバックアップを取ってくれていたほうがいいので、今回はCUIで行う方法。。。はどこにでもある情報なのでどうでもいいですね。
一応ふれておきますと、wbadmin.exeというコマンドを使います。
たとえば、システムがCドライブ、データがDドライブに入っているので、それをGドライブにバックアップしたいという場合は以下のよう記述にします。
wbadmin.exe start backup -backupTarget:g: -include:c:,d: -allCritical -vssFull -quiet
wbaadmin.exe というのがコマンド名です。
以下がそのコマンドに与えるコマンドラインですが、その中で、
-backupTargetというのがバックアップ先。ただし、CやDドライブと同一のハードディスク上にあってはいけません。また、ディレクトリは指定できません。ネットワークドライブでも構いませんが、リカバリ時に参照できなければ意味がないということは念頭に置いておくほうがよいでしょう。
-includeというのがバックアップしたいドライブ名。これもディレクトリは指定できません。
-allCriticalというのがシステムが起動するために必要な隠しパーティションを一緒にバックアップしてくれる、といった具合です。
これを、 「コンピューターの管理」にある「タスク スケジューラ」に設定して定期的に実行するだけです。
すると、GドライブにWindowsImageBackupというディレクトリが作られ、その中にC、Dドライブと(あれば)回復パーティションおよびEFI用パーティションが格納されます。
要するにWindows8のころの「Windows7のバックアップと云々」と同様な結果が得られます。
当然、作成されたディレクトリの中には丸々とドライブイメージが格納されており、イメージをマウントすれば個々のファイルにアクセスできます。
但し、世代管理やバックアップデータの圧縮はできません。
世代管理できないのも8からの劣化ですが、まあEUから締め出されるのも困るでしょうし、サードパーティー製品を買ってね、というところでしょうか。
ここまではよくある情報ですね。
次に知りたいのは、どうやったら復元できるか、です。
続きます。
GUIによる方法とCUI(コマンドライン)で行う方法です。
このうち、GUIで行う方法はバックアップを行うたびに手動で操作が必要になります。
もちろん、要所要所で手動でバックアップしておき、データだけは自動でどこかにコピーしておけばいいわけで、これはこれで十分でしょう。
ですが、その要所要所ってのが実際にはあやしい。
要所に手を加えたということは、その変更が必要だったからで、なんで変更が必要になったかといえば仕事や遊びでも、その需要があって変更をしているわけですから、バックアップなんかに時間をとられるのもどうかなと。
ですので、こちらが意識せずシステム側で定期的に全体のバックアップを取ってくれていたほうがいいので、今回はCUIで行う方法。。。はどこにでもある情報なのでどうでもいいですね。
一応ふれておきますと、wbadmin.exeというコマンドを使います。
たとえば、システムがCドライブ、データがDドライブに入っているので、それをGドライブにバックアップしたいという場合は以下のよう記述にします。
wbadmin.exe start backup -backupTarget:g: -include:c:,d: -allCritical -vssFull -quiet
wbaadmin.exe というのがコマンド名です。
以下がそのコマンドに与えるコマンドラインですが、その中で、
-backupTargetというのがバックアップ先。ただし、CやDドライブと同一のハードディスク上にあってはいけません。また、ディレクトリは指定できません。ネットワークドライブでも構いませんが、リカバリ時に参照できなければ意味がないということは念頭に置いておくほうがよいでしょう。
-includeというのがバックアップしたいドライブ名。これもディレクトリは指定できません。
-allCriticalというのがシステムが起動するために必要な隠しパーティションを一緒にバックアップしてくれる、といった具合です。
これを、 「コンピューターの管理」にある「タスク スケジューラ」に設定して定期的に実行するだけです。
すると、GドライブにWindowsImageBackupというディレクトリが作られ、その中にC、Dドライブと(あれば)回復パーティションおよびEFI用パーティションが格納されます。
要するにWindows8のころの「Windows7のバックアップと云々」と同様な結果が得られます。
当然、作成されたディレクトリの中には丸々とドライブイメージが格納されており、イメージをマウントすれば個々のファイルにアクセスできます。
但し、世代管理やバックアップデータの圧縮はできません。
世代管理できないのも8からの劣化ですが、まあEUから締め出されるのも困るでしょうし、サードパーティー製品を買ってね、というところでしょうか。
ここまではよくある情報ですね。
次に知りたいのは、どうやったら復元できるか、です。
続きます。
Windows8.1標準機能のベアドライブバックアップ まえおき
PCが壊れたためにWindows8にしたのですからバックアップ/リストア手段にはどうしても関心が向いてしまう。
本題は「その２」のほうにあります。
以下はすべて余談です。
Windows8から退化したものにベアドライブバックアップが不便になったということはあるでしょう。GUIの名前は変わる、場所は変わる、定期的に自動で実行してくれない、ってところでしょうか。
しかも、Windows8からのアップデートなのでインストールメディアもない。
リカバリDVDも作成不能で、USBのみときた。
作成するなら、せめてUSB接続のHDDなどの不揮発性のメディアにしたほうがいいですよ。
というのは、いわゆるUSBメモリってのは中身はフラッシュメモリを使った製品が過半でして、フラッシュメモリの特性として、製品寿命に関係なく記録した内容が一定時間で「揮発します」。
書き換え回数とはまた違う原因で揮発してしまいます。
誤解を恐れずに言うと、0と1のこの世界ですが、電子の皆さんが入っている部屋があるとして、その1の部屋、入ってないところを0の部屋と思ってください。
で、部屋は壁を設けて仕切ってあるわけですが、時間がたつにつれて壁から少しづつ電子の皆さんが漏れてしまうんです。
そして漏れて言った末に0なのか1なのか区別がつかなくなる状態になるので、結果としてデータが消えてなくなる、というわけです。
リカバリ用のメディアなんて、まさに「その日」がやってくるまでは引き出しの中にしまわれているものでしょうし、書き換えなんかしませんよね。
ですが、減ってしまった電子の皆さんに再度入ってもらうには、通電はもとより読み出しだけでもダメで、書き込みを行う必要があります。
ですので、USBメモリをリカバリ用として利用するなら定期的にリカバリUSBを作成するという運用をしなければなりません。
なお、リカバリUSBを作成するときはご注意。rescue用として利用するだけなら数百MBしか利用しないくせにUSBメモリ１本丸ごと全部フォーマットしてくださいます。
あまっている容量にリカバリ領域を作る、ということはできません。
どうしても他のデータと同居させたければ、リカバリUSBを作った後に再度データを保存する、という運用になるでしょう。
もちろんそんなことはマイクロソフトだってわかってやっているんでしょうが、いかんせん頭の中がタブレットでいっぱいなので、タブレットで一番使いやすいメディアといえばUSBメモリだわな、ということになるんでしょう。
まあ、それは冗談にしても、DVDでは容量が足りない人が出てくる、ということもあるでしょう。
回復ドライブとして使うにはDVDではとても不足ですし。
それに、タブレットだってそんなに長く使う人もいないだろうし、OSを売るサイクルを考えると、どんどん買い換えてほしいわけですからUSBメモリくらいが戦略上ちょうどいいのかもしれません。
ただ、PCの場合は５年、１０年と使い続けるのはざらでしょう。
新しい物にすぐなれて日頃の生産性をすぐ発揮できる、というひとはともかく、特に仕事で使っている人で機能に不自由を感じなければ、いざコトが起こった時に元に戻すことは考えても、いままでのはチャラにして新しく、なんていう人は少ないでしょう。
PCで使う人のことを考えると、メディア代の安さといい保存のしやすさといい、CDやDVDがリカバリ用メディアとして最も優れているとは思いますが、そもそもPCをゴリゴリつかって仕事をせざるをえない人とちょっとした情報の閲覧やメモ程度ができればPCである必要もない、という層は今後どんどん別れてゆくでしょうし、むしろ後者のほうが絶対数は多いでしょうから、Windowsは後者をターゲットにしているんでしょう。
で、私はいざというときに新しくしたくもないし新しい環境での生産性は著しく落ちますから、もとに復旧させるクチの人間です。しかもそういう時に限って急いでいたりするので、OSやアプリケーションの再インストールなんてこともしたかねえです。
なので丸々バックアップとリストアできりゃいいじゃんということになります。
システムを含めてすべてバックアップできてさえいれば、最悪でもデータだけでも復旧させることもできる理屈ですから一石二鳥です。
そういったことがwindows8まではGUIで簡単に、自動で定期的に行えるようになっていましたが、8.1からはGUIでおこなおうとすると手動になり、自動で定期的に行おうとするとGUIでは設定できなくなってしまいました。
ここまでが余談。
長すぎるのでつづく
本題は「その２」のほうにあります。
以下はすべて余談です。
Windows8から退化したものにベアドライブバックアップが不便になったということはあるでしょう。GUIの名前は変わる、場所は変わる、定期的に自動で実行してくれない、ってところでしょうか。
しかも、Windows8からのアップデートなのでインストールメディアもない。
リカバリDVDも作成不能で、USBのみときた。
作成するなら、せめてUSB接続のHDDなどの不揮発性のメディアにしたほうがいいですよ。
というのは、いわゆるUSBメモリってのは中身はフラッシュメモリを使った製品が過半でして、フラッシュメモリの特性として、製品寿命に関係なく記録した内容が一定時間で「揮発します」。
書き換え回数とはまた違う原因で揮発してしまいます。
誤解を恐れずに言うと、0と1のこの世界ですが、電子の皆さんが入っている部屋があるとして、その1の部屋、入ってないところを0の部屋と思ってください。
で、部屋は壁を設けて仕切ってあるわけですが、時間がたつにつれて壁から少しづつ電子の皆さんが漏れてしまうんです。
そして漏れて言った末に0なのか1なのか区別がつかなくなる状態になるので、結果としてデータが消えてなくなる、というわけです。
リカバリ用のメディアなんて、まさに「その日」がやってくるまでは引き出しの中にしまわれているものでしょうし、書き換えなんかしませんよね。
ですが、減ってしまった電子の皆さんに再度入ってもらうには、通電はもとより読み出しだけでもダメで、書き込みを行う必要があります。
ですので、USBメモリをリカバリ用として利用するなら定期的にリカバリUSBを作成するという運用をしなければなりません。
なお、リカバリUSBを作成するときはご注意。rescue用として利用するだけなら数百MBしか利用しないくせにUSBメモリ１本丸ごと全部フォーマットしてくださいます。
あまっている容量にリカバリ領域を作る、ということはできません。
どうしても他のデータと同居させたければ、リカバリUSBを作った後に再度データを保存する、という運用になるでしょう。
もちろんそんなことはマイクロソフトだってわかってやっているんでしょうが、いかんせん頭の中がタブレットでいっぱいなので、タブレットで一番使いやすいメディアといえばUSBメモリだわな、ということになるんでしょう。
まあ、それは冗談にしても、DVDでは容量が足りない人が出てくる、ということもあるでしょう。
回復ドライブとして使うにはDVDではとても不足ですし。
それに、タブレットだってそんなに長く使う人もいないだろうし、OSを売るサイクルを考えると、どんどん買い換えてほしいわけですからUSBメモリくらいが戦略上ちょうどいいのかもしれません。
ただ、PCの場合は５年、１０年と使い続けるのはざらでしょう。
新しい物にすぐなれて日頃の生産性をすぐ発揮できる、というひとはともかく、特に仕事で使っている人で機能に不自由を感じなければ、いざコトが起こった時に元に戻すことは考えても、いままでのはチャラにして新しく、なんていう人は少ないでしょう。
PCで使う人のことを考えると、メディア代の安さといい保存のしやすさといい、CDやDVDがリカバリ用メディアとして最も優れているとは思いますが、そもそもPCをゴリゴリつかって仕事をせざるをえない人とちょっとした情報の閲覧やメモ程度ができればPCである必要もない、という層は今後どんどん別れてゆくでしょうし、むしろ後者のほうが絶対数は多いでしょうから、Windowsは後者をターゲットにしているんでしょう。
で、私はいざというときに新しくしたくもないし新しい環境での生産性は著しく落ちますから、もとに復旧させるクチの人間です。しかもそういう時に限って急いでいたりするので、OSやアプリケーションの再インストールなんてこともしたかねえです。
なので丸々バックアップとリストアできりゃいいじゃんということになります。
システムを含めてすべてバックアップできてさえいれば、最悪でもデータだけでも復旧させることもできる理屈ですから一石二鳥です。
そういったことがwindows8まではGUIで簡単に、自動で定期的に行えるようになっていましたが、8.1からはGUIでおこなおうとすると手動になり、自動で定期的に行おうとするとGUIでは設定できなくなってしまいました。
ここまでが余談。
長すぎるのでつづく
nvidiaドライバのトラブルと自動更新 2
恥のつづき。
早速これまで使っていたドライバを削除し、古いドライバのインストーラを起動すると、なぜかデバイスのインストール中だからちょっと待てという表示が。
そこで、ちょっと待って再実行すると無事インストールが完了した。
なんだ、windows8用のドライバも使えるんじゃないか、とあっけない気分を味わいながら様子を見ていると、まったく症状が改善されない。
今度はデバイスマネージャからドライバを削除して標準VGAドライバに切り替わったことを確認後、再起動すると、再起動前はちゃんと低解像度になっていたのに高解像度の画面が表示された。
おや、8.1になってようやく他OSのように標準VGAドライバでも解像度だけは高くできるようなドライバになったのかな、とその時は深く考えずにインストーラを起動してみると、またもデバイスのインストール中だからちょっと待てと。
どうも変だ、とおもいつつ、再度ドライバのインストールを行おうとしてインストーラの表示を見ると、ドライバ以外のバージョンは314.22であるのに、肝心のドライバが327.23とある。
あれあれ?
どうもこりゃあ削除をしくじっていたか、と再度徹底的に削除して確認しまくって再起動すると、また起動直後は低解像度だったのに急に高解像度になる。
おかしい、おかしい、と考えていると、先ほどnvidiaのインストーラを起動した際にデバイスの構成中だからインストールは待ってね、という表示がされるということは、別のインストーラが 走っている?
Windows Updateが自動なのかな?とおもって再確認しても、自動更新にはなっていない。
昔から自動更新は何が入るか確認できないために切る習慣のため、Windows8.1アップグレード直後もすぐに「更新プログラムを確認するが、ダウンロードインストールを行うかどうかは選択する」設定にしてあるし、その時確認しても実際にそうなっている。
するとなんなのだ。。。とにかく他の要因があるのか、とコントロールパネルを目を皿のようにしてそのような項目がないか調べてみたけれど、とくに見つけられない。
ほとほとこうじはて、google様にお伺いを立てたところ、windows7からドライバが勝手にインストールされるようになったという記事が。
うはぁ。これだ、と思って記事を参照してみると、
コントロール パネル\システムとセキュリティ\システム
画面の左にある「システムの詳細設定」を選び、出てきた画面の「ハードウェア」タブのなかの「デバイスのインストール設定」というところで無効にできるということがやっとわかった。
WindowsUpdateを勝手に行わない、という設定をしていても「デバイスのインストール設定」でさらに設定しないと、ドライバだけはインストールされてしまうとは。
WindowsUpdateに関する設定があちこちにあるなんてのも盲点だった。
しかも、デバイスがインストールされたときに特に通知されていなかったような。
削除のたびに勝手にインストールされたはずだが、まったく気づかなかった。
早速無効にして327.23を削除後、改めて314.22をインストールすると、無事ドライバのバージョンが古いままとなった。
それから様子を見てだいぶたつが、一度だけwindows8時代にも起きていた「スリープ復帰時にエクスプローラの画面描画がおかしくなりフォルダが開けなくなる」という現象が発生したものの、モニタを見失うことはなくなり、安定している。
今回の場合、WindowsUpdateでnvidiaのドライバがリリースされれており、そのバージョンが327.23であったことで、それより古い314.22を入れると自動的にアップデートされるということを繰り返していたことになる。
親切でやっていても、あるいはユーザなんか管理できっこないからこっちでやってやんよ、と寛大にして優渥なるご立派な態度であったとしても、確認もせずにインストールされるとどうなるからわからないからWindowsUpdate自動更新を切っているのに、こう勝手にシステムに黙って手を加えられると、管理上非常に困る。
せめて実行前に問い合わせてほしい。
われわれ愚民どもを憐れむ偉大なる大マイクロソフトさま、お願いですからヤメテ。
知っていればどうということはない、まったく間の抜けた話だが、恥の記録として。
早速これまで使っていたドライバを削除し、古いドライバのインストーラを起動すると、なぜかデバイスのインストール中だからちょっと待てという表示が。
そこで、ちょっと待って再実行すると無事インストールが完了した。
なんだ、windows8用のドライバも使えるんじゃないか、とあっけない気分を味わいながら様子を見ていると、まったく症状が改善されない。
今度はデバイスマネージャからドライバを削除して標準VGAドライバに切り替わったことを確認後、再起動すると、再起動前はちゃんと低解像度になっていたのに高解像度の画面が表示された。
おや、8.1になってようやく他OSのように標準VGAドライバでも解像度だけは高くできるようなドライバになったのかな、とその時は深く考えずにインストーラを起動してみると、またもデバイスのインストール中だからちょっと待てと。
どうも変だ、とおもいつつ、再度ドライバのインストールを行おうとしてインストーラの表示を見ると、ドライバ以外のバージョンは314.22であるのに、肝心のドライバが327.23とある。
あれあれ?
どうもこりゃあ削除をしくじっていたか、と再度徹底的に削除して確認しまくって再起動すると、また起動直後は低解像度だったのに急に高解像度になる。
おかしい、おかしい、と考えていると、先ほどnvidiaのインストーラを起動した際にデバイスの構成中だからインストールは待ってね、という表示がされるということは、別のインストーラが 走っている?
Windows Updateが自動なのかな?とおもって再確認しても、自動更新にはなっていない。
昔から自動更新は何が入るか確認できないために切る習慣のため、Windows8.1アップグレード直後もすぐに「更新プログラムを確認するが、ダウンロードインストールを行うかどうかは選択する」設定にしてあるし、その時確認しても実際にそうなっている。
するとなんなのだ。。。とにかく他の要因があるのか、とコントロールパネルを目を皿のようにしてそのような項目がないか調べてみたけれど、とくに見つけられない。
ほとほとこうじはて、google様にお伺いを立てたところ、windows7からドライバが勝手にインストールされるようになったという記事が。
うはぁ。これだ、と思って記事を参照してみると、
コントロール パネル\システムとセキュリティ\システム
画面の左にある「システムの詳細設定」を選び、出てきた画面の「ハードウェア」タブのなかの「デバイスのインストール設定」というところで無効にできるということがやっとわかった。
WindowsUpdateを勝手に行わない、という設定をしていても「デバイスのインストール設定」でさらに設定しないと、ドライバだけはインストールされてしまうとは。
WindowsUpdateに関する設定があちこちにあるなんてのも盲点だった。
しかも、デバイスがインストールされたときに特に通知されていなかったような。
削除のたびに勝手にインストールされたはずだが、まったく気づかなかった。
早速無効にして327.23を削除後、改めて314.22をインストールすると、無事ドライバのバージョンが古いままとなった。
それから様子を見てだいぶたつが、一度だけwindows8時代にも起きていた「スリープ復帰時にエクスプローラの画面描画がおかしくなりフォルダが開けなくなる」という現象が発生したものの、モニタを見失うことはなくなり、安定している。
今回の場合、WindowsUpdateでnvidiaのドライバがリリースされれており、そのバージョンが327.23であったことで、それより古い314.22を入れると自動的にアップデートされるということを繰り返していたことになる。
親切でやっていても、あるいはユーザなんか管理できっこないからこっちでやってやんよ、と寛大にして優渥なるご立派な態度であったとしても、確認もせずにインストールされるとどうなるからわからないからWindowsUpdate自動更新を切っているのに、こう勝手にシステムに黙って手を加えられると、管理上非常に困る。
せめて実行前に問い合わせてほしい。
われわれ愚民どもを憐れむ偉大なる大マイクロソフトさま、お願いですからヤメテ。
知っていればどうということはない、まったく間の抜けた話だが、恥の記録として。
nvidiaドライバのトラブルと自動更新 1
Windows8.1にupgradeしたが、無知ゆえにまるで当然のようにトラブルに見舞われたので恥をメモ。
WindowsUpdateの自動更新をOFFにしていても、ドライバの自動インストール機能は別個に自動更新機能をOFFにしないと勝手にWindowsUpdateがかかりますよ、というお話。
長いです。
まず最初に引っかかったのは意図したデバイスドライバが入らない、というトラブル。
具体的にはnvidiaのvideoドライバ。
アップグレード直後はwindows8.1対応のドライバが1種類(327.23)しかなく、それを素直にインストールした。
しかし、スリープ復帰時に数回に一回、モニタを見失う(画面がブラックアウトする)という現象が発症した。
この症状は、スリープから復帰させた直後に一瞬画面が表示されるものの、すぐに「OSからのUSBデバイスを外した時のような音」と同時にモニタへの出力が停止されるというもの。PCそのものは稼働しており、vncviewerやrdesktopでリモートからPCへログインしてみると、ログインができる。
その際にNVIDIAコントロールパネルにて確認すると、本来であればモニタ名が表示されているはずのところへ、単に「デジタルディスプレイ」に接続されているように表示されている状況。
実は、この状況はwindows8.1へupgrade直後のログイン時に一回発生していたが、二回目には正常にログインできたため、インストール手順での何らかの初期化等によるものか、と考えていた。
しかし、スリープから復帰時のこの挙動では誠に困る。
色々原因を調査するために再起動等を繰り返していると、実はログイン時にも頻発することがわかってきた。
再起動やシャットダウンはめったに行わないためスリープからの復帰で顕在化したが、これはこのドライバがwindows8.1からの何らかの初期化などの信号を受けた時に誤動作するものだろうか。
windows8の時には発生しておらず、windows8.1にupgrade直後に発生した事象であるから、当初は8.1を疑って色々検索してみたが、特にそういった問題は検索に引っかかってこない。
実はwindows8の時も「スリープ復帰時にエクスプローラの画面描画がおかしくなりフォルダが開けなくなる」場合がたまにあるという問題は抱えていたが、エクスプローラの再起動で対応できるため放置していた。
もしかして、とドライバのバージョンで検索すると、どうも320番台は地雷だという評判が高いことがわかった。
しかし、windows8.1対応ドライバは1種類のみ。
どうにも困っていると、331番台がリリースされたため飛びついてインストールしてみると、今度はさらにひどい状況になってしまった。
ログインやスリープ復帰時からどころか、nvidiaコントロールパネルを開いて情報を見ようとしたり、nvidiaドライバについてきた添付ソフト(3Dなんとかとかexperienceなんとかとか)を試しに起動してみたりするだけで、例の「デバイスを外した時の音がして画面を見失う」という状況が発生するようになってしまった。
音が鳴っているのだからOSは画面を見失っているのを認識しているんだろう、と、イベントログを見ても何のエラーも警告もinfoも記録されておらず。何のためのイベントログなんだかさっぱりわからんログ出力思想だと毒づいてみても仕方がない。
二種類しかないドライバでどちらもダメだとなると。。。と暗澹としたが、もうやけくそでwindows8用のドライバを入れてみようと思い、8の時に使っていたバージョンをバックアップ先を調べてみると320.18を使っていた。
このバージョンは8の時もエクスプローラの動作がおかしくなるという問題があったため、さらにひとつ前の314.22を入れてみることにした。
ここから先はさらに恥の上塗りになるが、長くなったのでつづく。
WindowsUpdateの自動更新をOFFにしていても、ドライバの自動インストール機能は別個に自動更新機能をOFFにしないと勝手にWindowsUpdateがかかりますよ、というお話。
長いです。
まず最初に引っかかったのは意図したデバイスドライバが入らない、というトラブル。
具体的にはnvidiaのvideoドライバ。
アップグレード直後はwindows8.1対応のドライバが1種類(327.23)しかなく、それを素直にインストールした。
しかし、スリープ復帰時に数回に一回、モニタを見失う(画面がブラックアウトする)という現象が発症した。
この症状は、スリープから復帰させた直後に一瞬画面が表示されるものの、すぐに「OSからのUSBデバイスを外した時のような音」と同時にモニタへの出力が停止されるというもの。PCそのものは稼働しており、vncviewerやrdesktopでリモートからPCへログインしてみると、ログインができる。
その際にNVIDIAコントロールパネルにて確認すると、本来であればモニタ名が表示されているはずのところへ、単に「デジタルディスプレイ」に接続されているように表示されている状況。
実は、この状況はwindows8.1へupgrade直後のログイン時に一回発生していたが、二回目には正常にログインできたため、インストール手順での何らかの初期化等によるものか、と考えていた。
しかし、スリープから復帰時のこの挙動では誠に困る。
色々原因を調査するために再起動等を繰り返していると、実はログイン時にも頻発することがわかってきた。
再起動やシャットダウンはめったに行わないためスリープからの復帰で顕在化したが、これはこのドライバがwindows8.1からの何らかの初期化などの信号を受けた時に誤動作するものだろうか。
windows8の時には発生しておらず、windows8.1にupgrade直後に発生した事象であるから、当初は8.1を疑って色々検索してみたが、特にそういった問題は検索に引っかかってこない。
実はwindows8の時も「スリープ復帰時にエクスプローラの画面描画がおかしくなりフォルダが開けなくなる」場合がたまにあるという問題は抱えていたが、エクスプローラの再起動で対応できるため放置していた。
もしかして、とドライバのバージョンで検索すると、どうも320番台は地雷だという評判が高いことがわかった。
しかし、windows8.1対応ドライバは1種類のみ。
どうにも困っていると、331番台がリリースされたため飛びついてインストールしてみると、今度はさらにひどい状況になってしまった。
ログインやスリープ復帰時からどころか、nvidiaコントロールパネルを開いて情報を見ようとしたり、nvidiaドライバについてきた添付ソフト(3Dなんとかとかexperienceなんとかとか)を試しに起動してみたりするだけで、例の「デバイスを外した時の音がして画面を見失う」という状況が発生するようになってしまった。
音が鳴っているのだからOSは画面を見失っているのを認識しているんだろう、と、イベントログを見ても何のエラーも警告もinfoも記録されておらず。何のためのイベントログなんだかさっぱりわからんログ出力思想だと毒づいてみても仕方がない。
二種類しかないドライバでどちらもダメだとなると。。。と暗澹としたが、もうやけくそでwindows8用のドライバを入れてみようと思い、8の時に使っていたバージョンをバックアップ先を調べてみると320.18を使っていた。
このバージョンは8の時もエクスプローラの動作がおかしくなるという問題があったため、さらにひとつ前の314.22を入れてみることにした。
ここから先はさらに恥の上塗りになるが、長くなったのでつづく。
2013年10月3日木曜日
監視したい。とても。
監視したいんですよ。PCを。
なぜかって?
さあ。
本来PCを監視するっちゅうのは、たとえば無応答の端末にカツを入れたりレバーをすりつぶしたり手羽先をこんがり揚げちゃったりするのが目的。
でももう、肉が胃にもたれるお年頃の四十肩のわたくしにはそんなのどうでもいいわけです。
KFCは28日になると買いに行きたくなりますけど。(肉が減ってクリスピー増えましたね...)
で、まあ、業務用のをいろいろ作ってきた覚えはありますが、はっきり言ってあんなもんいらねえ。
確かに我が家にはサーバやらPCやらがゴロゴロしていますが、死ぬときは音もするしニオイもわかる。
その場にいなくてもアクセスして無応答ならすぐわかりますわな。
(ああ、あのコンデンサの破裂した時のかぐわしさといったら。)
だから、監視対象は死活確認とかそういうんじゃないわな。
グラフ化できるなにか
これだね。見て楽しむ。
原則放置プレイな*nix系OSにはいろいろあるんだけど、windowsが対象となると途端にだるくなる。
そらそーだよね。
ふつう、PCって放置プレイで運用するもんじゃないもんね。私はしているけど。
もっとも、最近じゃMRTGとかもwindows版があるみたいね。
でも核心は
グラフ化できるなにか
コレ。
windowsでもって一番お手軽なソレはタスクマネージャ。
でもこれ1分なんだよねえ。
パフォーマンスモニタ?
うーん。あれもねぇ。。。
せめて1年は記録を参照できないとツマンナイんだなあ。
と、いうわけで、そーゆーツールがrrdtool。こいつはただのデータベースじゃない。
そんなんだったらmysqlでもpostgresqlでもsqliteでもcsvでもいいわけよね。
それに別にround robinじゃなくたって、私が死ぬまでに毎秒記録していても使い切れない広大な二次記憶スペースが手に入る昨今、どおってこたあない。
何がｽｺﾞいか。
グラフ化できるなにか。なにか:=rrdtool
DBだけじゃないってことかな。しょうがないにゃあ。
データの管理と可視化を同時に行ってくれる、まさに夢のようなツールなわけです。
そいつにデータをストアしておいて、見たい時にｸﾞﾗﾌ化されてりゃいいってことになるわけですね。
ま、それのパッケージがMRTGなんですけどね。作者も同じですし。
でも、まあ、私の場合はHotSaNICでもって自宅サーバの監視を長年行ってきていたので(思えば21世紀初頭ですよ奥さん)、そいつに相乗りさせようということで前置きが終わります。
でもって、rrdtoolをHotSaNICからつかうんダヨネとか決定してみたわけですが、これはこれまで通り。ただデータ収集先が1つ増え、windowsになるということです。
HotSaNICそのものはデータを集めてきてrrdtoolに記録をお願いしたり、定期的にグラフを表示するためのホームページ用のｸﾞﾗﾌをrrdtoolにお願いして作っていただいたりしている(perlの!)デーモンなわけです。
ということは、windowsを監視したいンですけど。というときにすべきなのはwindowsからいかにして情報をせしめるか、というだけの話になるわけです。
収集した後は既存のフレークワークに従ってHotSaNICにお任せすればrrdtoolラッパも作る必要がなくなってみんな幸せになれるわけです。
そこで、PCにはそのサーバへのデータ蓄積・送信機能があれば、サーバがそのデータを収集しに来たタイミングで返事をすればいいという作りにしておけばいいということになります。
ここで、ｸﾞﾗﾌ化したら見栄えがいいデータの選定を行います。
まず温度。CPUとかHDD、GPUなんかの。これは見栄えがいいですよ奥さん。
CPUクロックなんかもいいかもしれませんね。
あと起動時間やメモリ使用状況なんかも見てくれがいいでしょう。
そこで、それらを収集することにします。
とはいえ、CPU温度・・・いきなり難問ですね。
OSはそういったことには関心がないようで、パフォーマンスモニタでも収集できません。
では、ということで外部ツールを探してみると、どれもこれも・・・と思ってvista導入時はやめちゃったんでした、わたくしは。
2007年のことでした。
しかし、今回は違いました。
http://openhardwaremonitor.org/
Open Hardware Monitor
このようなツールが見つかりました。
これのなにがｽﾊﾞﾗｼｲか。
それは、先ほど列挙した「ｸﾞﾗﾌ化したい」項目について常に簡単に取得できる仕組みが整っていたのです。
具体的には、WMI(Windows Management Instrumentation)という仕組みを通じて、このアプリケーションが収集したデータを取得できる、という点において、キラキラ光っているわけです。
というのは、WMIを通して、ネットワークトラフィックやCPU利用率、DISKIOなどのデータは取得できることはわかっていたからです。
つまり、問い合わせ先を統一できるということです。
BMI?標準体重?
いやいや、違います。
select文一発でなんだかよくわかんねえデータをとれちゃうんだぜ、という仕組み(WMI)がもともとwindowsにはあって、そこにCPU温度などのデータを公開してくれるヤツなんです。
このアプリさえ起動しておけば、あとはWMI経由で情報を取得して問い合わせ先に教えてあげるツールがあればそれで目的は達せられるというわけです。なんてｽﾊﾞﾗｼｲ.
しかし、残念ながらわたくしの環境ではHDDの温度がこのツールでは収集できませんでした。
そこらへんに転がっている文献ではWMI経由でSMART情報が取得できるとありますが、できませんでした。
一番壊れやすいHDDの温度管理情報は、ｸﾞﾗﾌ化するだけでもかなり有用な情報です。
それが取得できないのはどういうことなのか。
じゃあ、ってんで、speedfanやら類似のツールを試してみても、やはり取得できていません。
OpenHardwareMonitorでも取得できていません。
そこで、OpenSourceのありがたさ。
OpenHardwareMonitorのソースをとりよせて眺めてみると、アラC#。
四十肩にはツライよ。
ほとんどこの言語を使ったことがなかったのですが、眺めていると、なんてこたあない、普通にDeviceIoControl()で取得していました。しかも、ド定番な方法。
まさかとは思うけど、C#だとおかしいのかな?と思って自分でCで書いて実行すると同じように取れない。うーん。
でもソースがあるんだから、と、よくよく眺めてみると、ド定番な方法のほかの方法を試していません。
たとえばATA PASS THROUGHとか、SCSI_PASS_THROUGHとか。
もしかして、、、とおもって、そこまでやっていそうなsmartmontoolsをダウンロードして実行してみると、見事取得に成功しました。
結局、これもまたsmartmontoolsがopen sourceなのでｺｰﾄﾞを追ってみると、まさにATA_PASS_THROUGHな時に成功してSMART情報が読めていたのでした。
さすがだぜ!smartmontools!!
ここで一つの選択肢ができました。
OpenHardwareMonitorを改造して運用するか、smartmontoolsとOpenHardwareMonitorを併用して行くか、という選択肢です。
結果から言うと、サーバからの問い合わせに回答するプログラムを作り、その中で問い合わせ先を振り分ける、という実装にすることにしました。
というのは、いつOpenHardwareMonitorやOSそのものが対応するかもわからないし、改造版を動かすというのは改造元のアプリがアップデートされた場合のキャッチアップがだりぃということが理由でした。動いてんだからキャッチアップする理由もねぇんだけどな。気分だわな。
ということで。ここでSNMPを利用してWMIを参照する、とかいうだるい手法を採用する目がつまれました。
SNMPなみなさんは汎用性を目指すあまり重いしね。
やるこたあ一緒なんだけどね。エージェントが今回作るつもりのプログラムで、マネージャがHotSaNICなだけだけだからね。
つづく。
なぜかって?
さあ。
本来PCを監視するっちゅうのは、たとえば無応答の端末にカツを入れたりレバーをすりつぶしたり手羽先をこんがり揚げちゃったりするのが目的。
でももう、肉が胃にもたれるお年頃の四十肩のわたくしにはそんなのどうでもいいわけです。
KFCは28日になると買いに行きたくなりますけど。(肉が減ってクリスピー増えましたね...)
で、まあ、業務用のをいろいろ作ってきた覚えはありますが、はっきり言ってあんなもんいらねえ。
確かに我が家にはサーバやらPCやらがゴロゴロしていますが、死ぬときは音もするしニオイもわかる。
その場にいなくてもアクセスして無応答ならすぐわかりますわな。
(ああ、あのコンデンサの破裂した時のかぐわしさといったら。)
だから、監視対象は死活確認とかそういうんじゃないわな。
グラフ化できるなにか
これだね。見て楽しむ。
原則放置プレイな*nix系OSにはいろいろあるんだけど、windowsが対象となると途端にだるくなる。
そらそーだよね。
ふつう、PCって放置プレイで運用するもんじゃないもんね。私はしているけど。
もっとも、最近じゃMRTGとかもwindows版があるみたいね。
でも核心は
グラフ化できるなにか
コレ。
windowsでもって一番お手軽なソレはタスクマネージャ。
でもこれ1分なんだよねえ。
パフォーマンスモニタ?
うーん。あれもねぇ。。。
せめて1年は記録を参照できないとツマンナイんだなあ。
と、いうわけで、そーゆーツールがrrdtool。こいつはただのデータベースじゃない。
そんなんだったらmysqlでもpostgresqlでもsqliteでもcsvでもいいわけよね。
それに別にround robinじゃなくたって、私が死ぬまでに毎秒記録していても使い切れない広大な二次記憶スペースが手に入る昨今、どおってこたあない。
何がｽｺﾞいか。
グラフ化できるなにか。なにか:=rrdtool
DBだけじゃないってことかな。しょうがないにゃあ。
データの管理と可視化を同時に行ってくれる、まさに夢のようなツールなわけです。
そいつにデータをストアしておいて、見たい時にｸﾞﾗﾌ化されてりゃいいってことになるわけですね。
ま、それのパッケージがMRTGなんですけどね。作者も同じですし。
でも、まあ、私の場合はHotSaNICでもって自宅サーバの監視を長年行ってきていたので(思えば21世紀初頭ですよ奥さん)、そいつに相乗りさせようということで前置きが終わります。
でもって、rrdtoolをHotSaNICからつかうんダヨネとか決定してみたわけですが、これはこれまで通り。ただデータ収集先が1つ増え、windowsになるということです。
HotSaNICそのものはデータを集めてきてrrdtoolに記録をお願いしたり、定期的にグラフを表示するためのホームページ用のｸﾞﾗﾌをrrdtoolにお願いして作っていただいたりしている(perlの!)デーモンなわけです。
ということは、windowsを監視したいンですけど。というときにすべきなのはwindowsからいかにして情報をせしめるか、というだけの話になるわけです。
収集した後は既存のフレークワークに従ってHotSaNICにお任せすればrrdtoolラッパも作る必要がなくなってみんな幸せになれるわけです。
そこで、PCにはそのサーバへのデータ蓄積・送信機能があれば、サーバがそのデータを収集しに来たタイミングで返事をすればいいという作りにしておけばいいということになります。
ここで、ｸﾞﾗﾌ化したら見栄えがいいデータの選定を行います。
まず温度。CPUとかHDD、GPUなんかの。これは見栄えがいいですよ奥さん。
CPUクロックなんかもいいかもしれませんね。
あと起動時間やメモリ使用状況なんかも見てくれがいいでしょう。
そこで、それらを収集することにします。
とはいえ、CPU温度・・・いきなり難問ですね。
OSはそういったことには関心がないようで、パフォーマンスモニタでも収集できません。
では、ということで外部ツールを探してみると、どれもこれも・・・と思ってvista導入時はやめちゃったんでした、わたくしは。
2007年のことでした。
しかし、今回は違いました。
http://openhardwaremonitor.org/
Open Hardware Monitor
このようなツールが見つかりました。
これのなにがｽﾊﾞﾗｼｲか。
それは、先ほど列挙した「ｸﾞﾗﾌ化したい」項目について常に簡単に取得できる仕組みが整っていたのです。
具体的には、WMI(Windows Management Instrumentation)という仕組みを通じて、このアプリケーションが収集したデータを取得できる、という点において、キラキラ光っているわけです。
というのは、WMIを通して、ネットワークトラフィックやCPU利用率、DISKIOなどのデータは取得できることはわかっていたからです。
つまり、問い合わせ先を統一できるということです。
BMI?標準体重?
いやいや、違います。
select文一発でなんだかよくわかんねえデータをとれちゃうんだぜ、という仕組み(WMI)がもともとwindowsにはあって、そこにCPU温度などのデータを公開してくれるヤツなんです。
このアプリさえ起動しておけば、あとはWMI経由で情報を取得して問い合わせ先に教えてあげるツールがあればそれで目的は達せられるというわけです。なんてｽﾊﾞﾗｼｲ.
しかし、残念ながらわたくしの環境ではHDDの温度がこのツールでは収集できませんでした。
そこらへんに転がっている文献ではWMI経由でSMART情報が取得できるとありますが、できませんでした。
一番壊れやすいHDDの温度管理情報は、ｸﾞﾗﾌ化するだけでもかなり有用な情報です。
それが取得できないのはどういうことなのか。
じゃあ、ってんで、speedfanやら類似のツールを試してみても、やはり取得できていません。
OpenHardwareMonitorでも取得できていません。
そこで、OpenSourceのありがたさ。
OpenHardwareMonitorのソースをとりよせて眺めてみると、アラC#。
四十肩にはツライよ。
ほとんどこの言語を使ったことがなかったのですが、眺めていると、なんてこたあない、普通にDeviceIoControl()で取得していました。しかも、ド定番な方法。
まさかとは思うけど、C#だとおかしいのかな?と思って自分でCで書いて実行すると同じように取れない。うーん。
でもソースがあるんだから、と、よくよく眺めてみると、ド定番な方法のほかの方法を試していません。
たとえばATA PASS THROUGHとか、SCSI_PASS_THROUGHとか。
もしかして、、、とおもって、そこまでやっていそうなsmartmontoolsをダウンロードして実行してみると、見事取得に成功しました。
結局、これもまたsmartmontoolsがopen sourceなのでｺｰﾄﾞを追ってみると、まさにATA_PASS_THROUGHな時に成功してSMART情報が読めていたのでした。
さすがだぜ!smartmontools!!
ここで一つの選択肢ができました。
OpenHardwareMonitorを改造して運用するか、smartmontoolsとOpenHardwareMonitorを併用して行くか、という選択肢です。
結果から言うと、サーバからの問い合わせに回答するプログラムを作り、その中で問い合わせ先を振り分ける、という実装にすることにしました。
というのは、いつOpenHardwareMonitorやOSそのものが対応するかもわからないし、改造版を動かすというのは改造元のアプリがアップデートされた場合のキャッチアップがだりぃということが理由でした。動いてんだからキャッチアップする理由もねぇんだけどな。気分だわな。
ということで。ここでSNMPを利用してWMIを参照する、とかいうだるい手法を採用する目がつまれました。
SNMPなみなさんは汎用性を目指すあまり重いしね。
やるこたあ一緒なんだけどね。エージェントが今回作るつもりのプログラムで、マネージャがHotSaNICなだけだけだからね。
つづく。
不幸になりやすいwin8の自動ログオン化
サインインですか?そうですか。
管理者アカウントの自動ログオン化時の注意点。
なお、自動ログオン化を行うに当たって、管理者権限を持つアカウントがないシステムが出来上がる可能性がありますので、あらかじめ作業の前にもう一つ管理者アカウントをこさえておくと安心です。
管理者権限を持つアカウントがなくなった場合、復旧できません。
十分注意してください。
誰も助けられる人はいませんよ。
あまりにユーザビリティが悪いので気軽にやってはいけない。うっかりミスを誘うようにできているものと覚悟したほうがよい。
というより、管理者アカウントで自動ログインするってのもどうかともおもうけど。
一応検証結果の記録として。
ああ、サインイ(r
管理者アカウントの自動ログオン化時の注意点。
なお、自動ログオン化を行うに当たって、管理者権限を持つアカウントがないシステムが出来上がる可能性がありますので、あらかじめ作業の前にもう一つ管理者アカウントをこさえておくと安心です。
管理者権限を持つアカウントがなくなった場合、復旧できません。
十分注意してください。
誰も助けられる人はいませんよ。
- ファイル名を指定して実行で
netplwiz
を起動する。 - 自動ログオンさせたいユーザのグループを覚えるかメモしておく。
サインインですか?そうですか。 - 自動ログインさせたいユーザを選択してからプロパティを開き、ラジオボタンを「管理者」にして更新。これを確認しないままだと、一般ユーザにされてしまう。
少なくともwindows8 pro 64bit版のインストール直後に行った検証では何度やっても確実に一般ユーザにされた。
その後は不明。windows updateかなんかで修正されているかもしれない。
サインインですか?そうですか。 - 元のタブに戻り、ユーザが確実にAdministratorグループに属していることを指さして声を出して確認する。
- 一番上のチェックボックス「ユーザーがこのコンピューターを使うには、ユーザー名とパスワードの入力が必要」からチェックを外す。
- OKを押してパスワードを設定する。
この際、別のパスワードを設定してしまうとアカウントのパスワードがクリアされてしまうため、ネットワークアクセス時に空パスワードを許している場合を除いて変更しないこと。 - コントロール パネル\すべてのコントロール パネル項目\管理ツール\コンピューターの管理\ローカル ユーザーとグループ (ファイル名を指定してlusrmgr.mscを実行しても同じ)
で項番（２）で覚えておいたグループに再振り分けする。
(今回の検証では何度やってもグループの一部が削られたため)
あまりにユーザビリティが悪いので気軽にやってはいけない。うっかりミスを誘うようにできているものと覚悟したほうがよい。
というより、管理者アカウントで自動ログインするってのもどうかともおもうけど。
一応検証結果の記録として。
ああ、サインイ(r
2013年10月2日水曜日
windows 64bit版に32bit版アプリの参照するレジストリの保存先
恥の記録。
windows 64bit版で32bit版アプリの参照するレジストリの保存先はHKLMなら
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node
になる。
したがって、64bitOSでレジストリの内容をそのままリストアさせようとするとHKEY_LOCAL_MACHINE\SOFTWARE配下にそのまま登録されてしまうため、32bitアプリから参照できない。
言われてみればまことにごもっともで、32bitOSなんて使ってるの自宅のPCだけだったこともあって、思いつくまで悩んだ。
対応：
エクスポートされたファイルを置換するか、32bit版regedit.exeやreg.exeも用意されているので、そちらを使ってインポートする。
64bit版のregedit.exe,reg.exeは%systemroot%system32にあって、32bit版のそれは%systemroot%syswow64にある。
歴史的経緯とはいえ・・・
windows 64bit版で32bit版アプリの参照するレジストリの保存先はHKLMなら
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node
になる。
したがって、64bitOSでレジストリの内容をそのままリストアさせようとするとHKEY_LOCAL_MACHINE\SOFTWARE配下にそのまま登録されてしまうため、32bitアプリから参照できない。
言われてみればまことにごもっともで、32bitOSなんて使ってるの自宅のPCだけだったこともあって、思いつくまで悩んだ。
対応：
エクスポートされたファイルを置換するか、32bit版regedit.exeやreg.exeも用意されているので、そちらを使ってインポートする。
64bit版のregedit.exe,reg.exeは%systemroot%system32にあって、32bit版のそれは%systemroot%syswow64にある。
歴史的経緯とはいえ・・・
バックアップとリストア失敗
コントロール パネル\すべてのコントロール パネル項目\Windows 7 のファイルの回復
こいつを使うとベアドライブバックアップができると聞いて早速試す。
vistaではこういう類の奴はネットワークに対応しておらずに残念だったけど、windows7からネットワークに標準で対応とうれしい限り。
vistaやwindows7同様、バックアップイメージファイルは仮想ディスク形式なのは変わっていなかったため、最悪の場合でもファイル単位で取り出すことができる。こりゃいいや。
じゃあリストアしてみよう。
はい。できませんでした。
結論から言うと、UEFI経由で起動したwindows8上で「Windows 7 のファイルの回復」の「システム イメージの作成」(ややこしい)を用いて作成したバックアップイメージのリストアは、UEFI経由で起動したインストールDVD(システム修復ディスク)からでなければ行うことができない。
たったこれだけの結論を得るために苦戦した。
ウラシマってレベルじゃねぇな。
これはwindows8の問題ではなく、UEFIを採用したシステムへインストールできるwindowsすべてに共通する問題なんでしょう。
恥の記録をしておこう。
経緯：
だから何だと聞いてみても何の解決にもならないんだけどね。
実は買ったマザーはUEFI対応なんだそうで。
ただディスクイメージを書き戻せばいいんだよ。
ひたすら１バイトづつ丁寧に書き戻せばいいんだよ。
やってみたうえでダメならわかるけど、やる前から出来ないなんて言うんじゃないよ!!
何の解決にもならないんだけどね。こんなこと書いても。
長いけど項目わけてもあれだからこのまま続けてみる。
まず、UEFIとはなんぞや、というところから調べてみても、ディスクイメージを書き戻すにあたってUEFI経由で書き戻すプログラムが起動していなければならない理由を見つけることができなかった。むちゃくちゃ端折って言えばEFI用のブートファイルがEFI専用パーティション（FAT32)のどっかにありゃいいよ、ってのとパーティション構成が（もっと言えば順番が）あってりゃいいよ、ということだと理解した。
NVRAMにアクセスできないのかな?
出来なくて結構なんだけどな。
EFI用のパーティションもバックアップされているんだから。
リストアプログラムがリストアさせないのは、技術的な問題ではなくセキュリティ的な問題や政治的な問題から抑止しているのかも(かっぱらってきたイメージをそのまま焼かせない、とか、別マシンにリストアしたら動かねえよ、という苦情になんか対応したくない、とか）。
XPぐらいのころからつづくMS様の愚民政策のよーな気がしてならないひがみやさん。
ブートシーケンスも隠すようになって久しいし、何かトラブルが出ても理由は明示されないで、できません。つかえません。管理者にお問い合わせください。の一点張りのケースが増えている気がしてならないんだよねえ。。。
まあ、話は飛びすぎたけど、無理やりリストアするにはどうするか、という問題に対する解決への糸口にはなりそうだけど、OSから再インストールしたほうが早そうだわ。
ただし、この場合はハードウェア構成も変わっていない。
バックアップしてあるんだからそれをそのままリストアしたい。
再インストールとなると、アプリのDVDやらををとっかえひっかえしてインストールするのも大変だし、システムや各アプリの設定だって普段使ってる状態に戻すまでとても時間がかかるし。
リストアが必要って状況はもうかなりへこんでいる状況のはずだから、そんな忍耐力を鍛えるような修行をしたくない。
ていうかこないだvistaからの移行でやったばかりだからすぐバックアップとリストアの検証をしているわけで。
そこで手順を見直してみる。
どうも経緯の項番（５）が引っ掛かる。
レガシーってことはBIOSから起動ってことなんだよねきっと。
リストアプログラムのメッセージの日本語がおかしいんで(現にエラーメッセージがいうところの「システムイメージはEFIを使ったコンピューター」に対してリストアをしようとしているわけで)、このコンピュータはBIOSがどうのこうというよりBIOS経由で起動した場合はリストアできないというように解釈してやると、CSMを有効にしてはいけない、ということになる。
すると、どうやったらUEFI経由でDVDからブートすりゃいいの？という経緯の項番（４）に戻る。
今になって思えば、確かにDVDからは起動できたけど、BIOS経由ではなくてUEFI経由でDVDから起動する方法を問い合わせれば、違う回答が得られたんじゃないかと思う。
そのころにはまだUEFIの知識もなく実際にDVDから起動できているわけだし、聞きようもなかったんだけどね。
CSMを有効にしたり無効にしたり、試行錯誤しているうちに、ようやくわかった。
インストールDVDを入れた状態のままシステムをブートすれば、UEFI経由でインストールDVDを起動元に選択できるということに。
たったそれだけ。
そして実際、UEFI経由で起動したインストールDVDからリストアできた。
ブートメニューを出してから、インストールDVDを入れる、という習慣だったため、ブートメニューが表示されるまでにDVDが認識できてればUEFIからのブートが可能になるなんて思いもしなかった。
これが分かった瞬間、とてもぐったりした。
別の不安もよぎる。
DVDドライブの立ち上がりが遅い場合、ブートメニューが表示されるまでにドライブがスタンバイできない場合、UEFI経由でインストールDVDを起動できないってことだよね。。。
そして後日、windows8.1previewにはwindows 7 のファイルの回復がないということを知ったのであった。
めでたしめでたし。
(さらにその後、定期バッチにはできないけど8.1製品版には手動では行えるツールがつくという話も風のうわさで聞きました。wbadminも残るとか。
まあ、Microsoftアカウントとかいうのは持ってないし、当分縁はなさそう。)
こいつを使うとベアドライブバックアップができると聞いて早速試す。
vistaではこういう類の奴はネットワークに対応しておらずに残念だったけど、windows7からネットワークに標準で対応とうれしい限り。
vistaやwindows7同様、バックアップイメージファイルは仮想ディスク形式なのは変わっていなかったため、最悪の場合でもファイル単位で取り出すことができる。こりゃいいや。
じゃあリストアしてみよう。
はい。できませんでした。
結論から言うと、UEFI経由で起動したwindows8上で「Windows 7 のファイルの回復」の「システム イメージの作成」(ややこしい)を用いて作成したバックアップイメージのリストアは、UEFI経由で起動したインストールDVD(システム修復ディスク)からでなければ行うことができない。
たったこれだけの結論を得るために苦戦した。
ウラシマってレベルじゃねぇな。
これはwindows8の問題ではなく、UEFIを採用したシステムへインストールできるwindowsすべてに共通する問題なんでしょう。
恥の記録をしておこう。
経緯：
- リストアのためにインストールDVDから起動する必要があるといわれる。
- 起動が早すぎて?ブートメニューが出ない。
- よくよく調べてみるとwindows8は初期状態では「シャットダウン」を選んでも、実はハイバネーションを行う。言い換えでユーザを翻弄する作戦に見事に引っかかった。
昔Libretto70で苦労した思い出がむくむくとよみがえってくる。
ブートメニューを出すだけならば回避策はいろいろあるようだが、ハイバネーションする必然性が全くない。むしろ起動トラブルの元だし。退避先のファイルが壊れたらどうなるかわからない。windows8のことだから「初期化すりゃいいんじゃね?」とか鼻であしらわれて悲しい気分になりたくない。
それにメモリ量に相当する巨大なハイバネーション用のファイルも無意味に居座ることになる。
レジュームなんぞしなくても十分に起動は早いよもっと自信持てよ。
したがって、この無意味な労働からwindows8様を開放して差し上げる。
なお、従来の意味でのシャットダウンをwindows8様に行っていただくには：
コントロール パネル\すべてのコントロール パネル項目\電源オプション\「電源ボタンの定義とパスワード保護の有効化」
にて、
シャットダウン設定 → 高速スタートアップを有効化
のチェックを外して差し上げる。 - なんとかこれでやっとブートメニューを出せるようになっても「Windows Boot Manager」しか選べない（DVDが選べない）
- どうしてもわからなかったのでマザーのサポートに問い合わせると、BIOSにCSMという項目があるからそいつを有効にしなさい、とのありがたい仰せ。
ｳﾞｫｰｺｴｰ、DVDドライブも現代ではレガシーなのかBDじゃないとだめなのか!?
早速その項目を見てみると、レガシーデバイスを有効にするとある。
要するにこれを無効から有効に変更してみると、DVDから起動する選択肢を選ぶことができ、実際に起動もした。さすがサポート!心強すぎる。 - リストア用のプログラムも無事起動し、バックアップ元ﾌｧｲﾙも指定できたので、いざリストアをしようとするとEFIがどうのこうのとおこ。激おこ。
「 このシステムイメージはEFIを使ったコンピューターで作成されましたが、このコンピューターはBIOSを使用しています」
リストアできなかった。
だから何だと聞いてみても何の解決にもならないんだけどね。
実は買ったマザーはUEFI対応なんだそうで。
ただディスクイメージを書き戻せばいいんだよ。
ひたすら１バイトづつ丁寧に書き戻せばいいんだよ。
やってみたうえでダメならわかるけど、やる前から出来ないなんて言うんじゃないよ!!
何の解決にもならないんだけどね。こんなこと書いても。
長いけど項目わけてもあれだからこのまま続けてみる。
まず、UEFIとはなんぞや、というところから調べてみても、ディスクイメージを書き戻すにあたってUEFI経由で書き戻すプログラムが起動していなければならない理由を見つけることができなかった。むちゃくちゃ端折って言えばEFI用のブートファイルがEFI専用パーティション（FAT32)のどっかにありゃいいよ、ってのとパーティション構成が（もっと言えば順番が）あってりゃいいよ、ということだと理解した。
NVRAMにアクセスできないのかな?
出来なくて結構なんだけどな。
EFI用のパーティションもバックアップされているんだから。
リストアプログラムがリストアさせないのは、技術的な問題ではなくセキュリティ的な問題や政治的な問題から抑止しているのかも(かっぱらってきたイメージをそのまま焼かせない、とか、別マシンにリストアしたら動かねえよ、という苦情になんか対応したくない、とか）。
XPぐらいのころからつづくMS様の愚民政策のよーな気がしてならないひがみやさん。
ブートシーケンスも隠すようになって久しいし、何かトラブルが出ても理由は明示されないで、できません。つかえません。管理者にお問い合わせください。の一点張りのケースが増えている気がしてならないんだよねえ。。。
まあ、話は飛びすぎたけど、無理やりリストアするにはどうするか、という問題に対する解決への糸口にはなりそうだけど、OSから再インストールしたほうが早そうだわ。
ただし、この場合はハードウェア構成も変わっていない。
バックアップしてあるんだからそれをそのままリストアしたい。
再インストールとなると、アプリのDVDやらををとっかえひっかえしてインストールするのも大変だし、システムや各アプリの設定だって普段使ってる状態に戻すまでとても時間がかかるし。
リストアが必要って状況はもうかなりへこんでいる状況のはずだから、そんな忍耐力を鍛えるような修行をしたくない。
ていうかこないだvistaからの移行でやったばかりだからすぐバックアップとリストアの検証をしているわけで。
そこで手順を見直してみる。
どうも経緯の項番（５）が引っ掛かる。
レガシーってことはBIOSから起動ってことなんだよねきっと。
リストアプログラムのメッセージの日本語がおかしいんで(現にエラーメッセージがいうところの「システムイメージはEFIを使ったコンピューター」に対してリストアをしようとしているわけで)、このコンピュータはBIOSがどうのこうというよりBIOS経由で起動した場合はリストアできないというように解釈してやると、CSMを有効にしてはいけない、ということになる。
すると、どうやったらUEFI経由でDVDからブートすりゃいいの？という経緯の項番（４）に戻る。
今になって思えば、確かにDVDからは起動できたけど、BIOS経由ではなくてUEFI経由でDVDから起動する方法を問い合わせれば、違う回答が得られたんじゃないかと思う。
そのころにはまだUEFIの知識もなく実際にDVDから起動できているわけだし、聞きようもなかったんだけどね。
CSMを有効にしたり無効にしたり、試行錯誤しているうちに、ようやくわかった。
インストールDVDを入れた状態のままシステムをブートすれば、UEFI経由でインストールDVDを起動元に選択できるということに。
たったそれだけ。
そして実際、UEFI経由で起動したインストールDVDからリストアできた。
ブートメニューを出してから、インストールDVDを入れる、という習慣だったため、ブートメニューが表示されるまでにDVDが認識できてればUEFIからのブートが可能になるなんて思いもしなかった。
これが分かった瞬間、とてもぐったりした。
別の不安もよぎる。
DVDドライブの立ち上がりが遅い場合、ブートメニューが表示されるまでにドライブがスタンバイできない場合、UEFI経由でインストールDVDを起動できないってことだよね。。。
そして後日、windows8.1previewにはwindows 7 のファイルの回復がないということを知ったのであった。
めでたしめでたし。
(さらにその後、定期バッチにはできないけど8.1製品版には手動では行えるツールがつくという話も風のうわさで聞きました。wbadminも残るとか。
まあ、Microsoftアカウントとかいうのは持ってないし、当分縁はなさそう。)
Windows8のUACの切り方
コントロール パネル\システムとセキュリティ\管理ツール\ローカルセキュリティポリシー
にて
ローカルポリシー → セキュリティ オプション →
ユーザー アカウント制御: 管理者承認モードですべての管理者を実行する
を
無効
にする
(再度有効にする際にはコントロール パネル\ユーザー アカウントとファミリー セーフティ\ユーザー アカウント の「ユーザーアカウント制御設定の変更」もチェックすること)
にて
ローカルポリシー → セキュリティ オプション →
ユーザー アカウント制御: 管理者承認モードですべての管理者を実行する
を
無効
にする
(再度有効にする際にはコントロール パネル\ユーザー アカウントとファミリー セーフティ\ユーザー アカウント の「ユーザーアカウント制御設定の変更」もチェックすること)
理由
PCがマザーごとHDDも巻き込んで盛大にぶっ壊れた。
たまたまサーバも電源が死んでいてバックアップが取り出せない状態にあった。
いやになって一気にサーバとPCを買い換えた。でもまだ1台死んでる。
ついでにGbEHUBもぶっ壊れていた。
サーバのほうはすぐ復旧できた。こういう時はLinuxみたいなシンプルな構成は助かるなあ。
PCのハードウェアの進化があまりに激しいので、そのままバックアップをリストアしても動くわけがないことは目に見えていた。
案の定、vista導入時にPEで作っておいたリストア用DVDも起動できない。
ディスクIO用の適切なドライバがないからだろう。
やけくそでOSをvista 32bitからwindows8 64bitにしてみた。
あまりの勝手の違いに魂消た。私のPCの知識は2007年で止まっていた。
vistaからwin8という負け進路を選択した自分を誇らしく思った。
ついでに帰ってくることにした。
自分で管理するのが嫌だから間借りすることにした。
お世話になります。
たまたまサーバも電源が死んでいてバックアップが取り出せない状態にあった。
いやになって一気にサーバとPCを買い換えた。でもまだ1台死んでる。
ついでにGbEHUBもぶっ壊れていた。
サーバのほうはすぐ復旧できた。こういう時はLinuxみたいなシンプルな構成は助かるなあ。
PCのハードウェアの進化があまりに激しいので、そのままバックアップをリストアしても動くわけがないことは目に見えていた。
案の定、vista導入時にPEで作っておいたリストア用DVDも起動できない。
ディスクIO用の適切なドライバがないからだろう。
やけくそでOSをvista 32bitからwindows8 64bitにしてみた。
あまりの勝手の違いに魂消た。私のPCの知識は2007年で止まっていた。
vistaからwin8という負け進路を選択した自分を誇らしく思った。
ついでに帰ってくることにした。
自分で管理するのが嫌だから間借りすることにした。
お世話になります。
登録:
投稿 (Atom)