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,    -- 1秒当たりの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

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を換装したりしてパーティションサイズを大きくしたくてもできなくなるということです。

2つあるのはどういうことだ、ということで、実際に回復ドライブとしてシステムに認識されているのはどちらか、あるいは両方か、と調べてみると、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ってのは、
  1. win8で作られた回復パーティション
  2. EFIシステムパーティション
  3. MSR
  4. システムドライブ(windows8.1が入ってるところ)
  5.  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であるかは重要です。
リストア時に起動するリカバリメディアの起動方法も同一である必要があります。

復旧用メディアから起動し、詳細オプションを選ぶと「イメージでシステムを回復」という選択肢が得られますから、それを選択することによってバックアップデータをリストアできます。

当然復旧先のディスクのサイズは、バックアップ時のものと同等かそれ以上必要ですし、同一のシステム以外にリストアしたところで動作はしません。

上記条件は以下に述べる手段で同一です。

以下の手段があります。
  1. ※未検証
    (HDD上にある回復パーティションから起動する)
    ま、そりゃそうですわな。
    OSが起動しなくなったが回復パーティションは生きているなどの場合、別メディアを使わずリストアできます。
  2. USBに保存した回復ドライブを使う
    「コントロール パネル\システムとセキュリティ\ファイル履歴」
    の左側に「回復」という素っ気もないメニューを選ぶと、回復ドライブが作れます。
    そこで作成したUSBデバイスから起動すると、1.と同様のメニューが起動します。
  3. ※未検証
    (Windows8.1のインストール用DVDから起動する)
    私はWindows8からのアップデート組なのでこれはできませんが、8.1を直接購入された方は一番オーソドックスな方法でしょう。
  4. Windows8.1Preview版のDVDから起動する
    実はこれが言いたかった。
2番目と4番目は先日、実際にやってみました。
(私の環境は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から締め出されるのも困るでしょうし、サードパーティー製品を買ってね、というところでしょうか。

ここまではよくある情報ですね。
次に知りたいのは、どうやったら復元できるか、です。

続きます。

Windows8.1標準機能のベアドライブバックアップ まえおき

PCが壊れたためにWindows8にしたのですからバックアップ/リストア手段にはどうしても関心が向いてしまう。

本題は「その2」のほうにあります。
以下はすべて余談です。

Windows8から退化したものにベアドライブバックアップが不便になったということはあるでしょう。GUIの名前は変わる、場所は変わる、定期的に自動で実行してくれない、ってところでしょうか。

しかも、Windows8からのアップデートなのでインストールメディアもない。
リカバリDVDも作成不能で、USBのみときた。

作成するなら、せめてUSB接続のHDDなどの不揮発性のメディアにしたほうがいいですよ。

というのは、いわゆるUSBメモリってのは中身はフラッシュメモリを使った製品が過半でして、フラッシュメモリの特性として、製品寿命に関係なく記録した内容が一定時間で「揮発します」。
書き換え回数とはまた違う原因で揮発してしまいます。

誤解を恐れずに言うと、0と1のこの世界ですが、電子の皆さんが入っている部屋があるとして、その1の部屋、入ってないところを0の部屋と思ってください。

で、部屋は壁を設けて仕切ってあるわけですが、時間がたつにつれて壁から少しづつ電子の皆さんが漏れてしまうんです。
そして漏れて言った末に0なのか1なのか区別がつかなくなる状態になるので、結果としてデータが消えてなくなる、というわけです。

リカバリ用のメディアなんて、まさに「その日」がやってくるまでは引き出しの中にしまわれているものでしょうし、書き換えなんかしませんよね。

ですが、減ってしまった電子の皆さんに再度入ってもらうには、通電はもとより読み出しだけでもダメで、書き込みを行う必要があります。

ですので、USBメモリをリカバリ用として利用するなら定期的にリカバリUSBを作成するという運用をしなければなりません。
なお、リカバリUSBを作成するときはご注意。rescue用として利用するだけなら数百MBしか利用しないくせにUSBメモリ1本丸ごと全部フォーマットしてくださいます。
あまっている容量にリカバリ領域を作る、ということはできません。
どうしても他のデータと同居させたければ、リカバリUSBを作った後に再度データを保存する、という運用になるでしょう。

もちろんそんなことはマイクロソフトだってわかってやっているんでしょうが、いかんせん頭の中がタブレットでいっぱいなので、タブレットで一番使いやすいメディアといえばUSBメモリだわな、ということになるんでしょう。
まあ、それは冗談にしても、DVDでは容量が足りない人が出てくる、ということもあるでしょう。
回復ドライブとして使うにはDVDではとても不足ですし。

それに、タブレットだってそんなに長く使う人もいないだろうし、OSを売るサイクルを考えると、どんどん買い換えてほしいわけですからUSBメモリくらいが戦略上ちょうどいいのかもしれません。

ただ、PCの場合は5年、10年と使い続けるのはざらでしょう。
新しい物にすぐなれて日頃の生産性をすぐ発揮できる、というひとはともかく、特に仕事で使っている人で機能に不自由を感じなければ、いざコトが起こった時に元に戻すことは考えても、いままでのはチャラにして新しく、なんていう人は少ないでしょう。

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自動更新を切っているのに、こう勝手にシステムに黙って手を加えられると、管理上非常に困る。
せめて実行前に問い合わせてほしい。

われわれ愚民どもを憐れむ偉大なる大マイクロソフトさま、お願いですからヤメテ。

知っていればどうということはない、まったく間の抜けた話だが、恥の記録として。

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を入れてみることにした。

ここから先はさらに恥の上塗りになるが、長くなったのでつづく。