Angel Halo

再インストール完了から一週間。

何故か上手く動作しない

メインPCが起動不能となり、IRSTの罠に苦しめられつつも何とかデータの生還を迎え、システム再インストールから復旧を遂げた現メインPCだが、その後も継続してシステム再構築を進めている。
その中で、以前インストールしていたもののあまり使わなかったアプリケーションなどはその価値を見直し、インストールしないという選択肢を採ったり、或いは逆に新たに便利なアプリケーションへと置き換えたりして再構築しているのだが、結構この入れ替えというものに時間がかかっていたりする。
そうした使用するアプリケーションの見直しをしていく中で、これからも便利に使って行きたいと思っているにも拘わらず、上手く動作しなくなったアプリケーションなどもあったりして、何故同じアプリケーションなのに上手く行かないのか等、疑問が残る事も多い。
一番目に付いた問題は、動画プレイヤーである「MPC-HC x64」である。
最初起動させた時は、何ら問題なく動作していたように見えていたのだが、マルチモニタで使用した際「MPC-HC x64」をセカンドモニタにドラッグしていくと、動画が途中で止まり、プログラムが一部フリーズした状態になる事に気付いた。
動画そのものは再生している音声から流れているようだが、映像に関しては完全に止まってしまっていて、一時停止すると止まるものの、再生を再開すると今度は音声も止まって完全にフリーズする状態。
タスクマネージャで確認すると、応答無しになっているので、プログラム的には止まってしまっているものになるのだろうが、以前は発生しなかった問題がそのまま発生するようになってしまった。
また、先日Blogでも記載した「Janetter2」に関しても同様である。Twitterの認証は完了していても、リンク先に飛べないというそれだけの理由で利用する事ができなくなっている。これはプログラム本体だけでなく、認証した結果作成される個別データが存在し、これを移植できれば再認証というプロセスをすっ飛ばして以前と同じ使用感にする事ができる事が判明しているが、手持ちにこのデータが既に存在しないため、ノートPC等から対象データを探し出して引っ張ってくる必要がある。これはまた試してみようと思っている。

インストール前提？

そしてそうしたアプリケーションを見繕っていると、アプリケーションプログラムには2種類の挙動パターンがある事に気付いた。
一つはシステムに確実にインストールという行為を必要とするものと、実行ファイルさえコピーされていれば良いというものである。
前者であれば、確実にインストールという行為を必要とする為、システムにインストールした事実を記録しないと実行プログラムを起動させようとしても実行できない。
しかしインストールという事実が必要の無いものは、実行プムログラムが実行された段階でプログラムが走る。
どちらが便利かと言われれば、もちろん手軽な後者ではあるのだが、確実な管理という面で見れば前者の方が扱いやすい。
よくフリーのアプリケーションなどにインストール用のプログラムと実行プログラムのみパッケージ化したものの両方を提供しているケースがあるが、こういう場合はほとんどが実行プログラムだけで起動できてしまうプログラムだと思うが、これだと旧PCから移植した際、インストーラーを使ったプログラムだったのか、それとも実行ファイルのみを展開して配置したプログラムなのかが非常に分かりづらい。
これ、Windowsの昔からの仕様なので、今更どちらかに集約するのは難しいのかもしれないが、そうした不明点を無くす為にも全てインストーラー経由とかにしてくれた方がわかりやすいと思うのは私だけだろうか？

Continue reading…

ソルダリングの意味が薄いらしい。

第9世代Coreでの熱耐性

Intelが既に発表し、1モデルが発売された第9世代Coreだが、私はこの第9世代が発売される話を聞いたとき、その内容を見てIntelもついに本腰を入れたな、と感じたのだが、どうもその本質はIntelの語っている内容からは見えていなかったようだ。
今回の第9世代Coreが発表された時、私は3つの点でその素性の良さを判断した。
一つは8コア16スレッドの製品が遂にメインストリームに下りてきた、という事。
言うまでもなく、これでCore数はRyzen7と並んだわけで、処理能力で後れを取ることはなくなったと言える。
二つ目は以前見つかったMeltdown等のセキュリティ問題に、ハードウェアレベルで対応したというもの。今まではUEFI BIOS等でその投機実行命令を阻止したりする手段を執らざるを得なかったが、それらをハードウェアレベルで実装する事で、余計なソフト処理をしなくて済むようになる。地味だが確実に良い方向に向かっている証しでもある。
そして三つ目だが、コアとヒートスプレッダの間に使われる熱伝導素材がグリスからソルダリングに変更した、というものである。
当然、ソルダリングの方が圧倒的に熱伝導率が高いため、コアをいち早く冷却できるのはソルダリングの方だが、そのコストはグリスの方が安く、ここ最近のIntelコアは全てグリスが使用されていた。なのでCore i7-8700Kなどを使用している人の一部は殻割りというヒートスプレッダを一度剥がしてグリスを拭き取り、かわりに液体金属を入れてヒートスプレッダで閉じるという保証外改造をして冷却効率を高めるという事をしていた。
今回の第9世代Coreは、そのままのパッケージでソルダリングになっているという事で、大部分の人がその事を歓迎したが、どうも事はそんなに簡単に喜んで良い状態ではないようである。

さらなる問題

海外の著名オーバークロッカーが、このCore i9-9900Kを殻割りしテストしてみた結果、単純にソルダリングをやり直したりしても、結果として冷却効率は上がらなかったらしい。
また、液体金属に置き換えたところ、9度ほどの温度低下が確認てきたらしいが、その結果と2コア増えた実装面積とを考えると、どうも能力が釣り合わない。
そこでいろいろ分析したらしいが、それによるとCore i9-9900KのダイはCore i7-8700Kのダイよりも厚みが2倍になっている事がわかったらしい。
通常、シリコンダイ上に形成される回路は、シリコンの底部に形成される。そこで発生した熱がシリコンの上に伝わり、そこでグリス(もしくはソルダー＝はんだ)→ヒートスプレッダへと伝わり、そこからグリス→CPUクーラーへと熱が伝わる。
シリコンに厚みがあるという事は、そのシリコンの熱伝導で冷却性能が落ちる事を意味していて、当然だがシリコンの熱伝導率はあまり高いとは言えない。
つまり第9世代Coreは、そのシリコン部の厚みが増している分、排熱状況が宜しくなく、内部に熱が残りやすい製品となっているというのである。

Continue reading…

やはりOptane Memoryは偉大だった…。

アクセス速度の決定的違い

今回のメインPC起動不能によるトラブルによって、私の中では一種「Optane Memory(IRST)は鬼門」という認識が根付いてしまった。
そもそも、OSが起動した上でのUIによってしか、その解除が出来ないという問題は危険極まりない事であり、万が一OSが起動できなくなった時の対処法がハッキリわからないという問題がある。
よって、個人的にはIRSTはもう使いたくない、と思っているのだが、ここ最近再構築を始めたメインPCを設定していると、どうしても気になる事が出てくる。
それは…HDDのアクセス速度がやはり遅いという事である。
少なくとも、Optane Memoryをキャッシュとして使用する事の意味の大きさはやはり存在していたという事であり、できるならIRSTを設定して速度向上を狙いたいところなのだが、トラブルに対しての対策を考えるとその危険性から導入したくない…と、メリットとデメリットの鬩ぎ合いに陥ってしまう。
実際、HDDのみで運用していると、以前ならアプリケーション側からアクセスしてデータを取りにいっても待つ事なく即座にデータを引っ張ってくるのだが、HDDだとワンテンポ遅れてデータを取ってきて、モサッと処理を開始する感覚になる。またプログラムによっては、即座の処理に間に合わせる事ができないのか、処理が一度止まり、そこから復帰すればまだよいが、復帰できないなんてものまである始末。これでは動作不良と言ってしまっても過言ではない状況である。
このように、取り扱いを迷ってしまうほど、Optane Memoryの速度的メリットは大きいわけである。

IRSTの問題

このように、できれば使って行きたいと思う技術がIRSTなのだが、トラブルを見越して使いにくくなってしまっている。とてももったいない話であり、であるなら、運用でトラブルが発生しても被害のないような使い方はできないか？ と模索してみると、そういう使い方ならアリかな？ と思う反面、問題は再構築時ではないのか？ と更なる確認が必要な部分とか見えてきた。
たとえば、消えてしまっても良いデータをあつめて、IRSTで高速化するHDDに保存し、IRSTで運用する。こうなると、データ損失の心配は全くなくなる。
一方、そうした消えても被害のないデータでIRSTを構築しても、万が一トラブルが発生した時、OSが起動しない→強制的にIRSTを解除する→Optane Memoryを問題なく再使用できるのか？ というところに問題がでてしまう。
というのは、どうもIRSTによって高速化されたSSD側には、RAIDを組んだという記録が残され、強制的にRAIDを解除しても、今度はそのOptane Memoryをそのまま再利用する事ができない。つまり、IRSTの総合メニューで解除してやらない事には、そうした物理的に解除してもソフト的にはRAID状態にあるので、新しいOSで認識させてもそのままの単一ストレージとしての利用が出来なくなるらしい。
まるで呪われたアイテムのような話である。

Continue reading…

いよいよメインPCの再構築を開始。

UEFIでもレガシー構成

さて、ようやく復帰の目処がついたメインPCだが、復帰と言っても結局はOSの再インストールからの話なので、基本的にはほぼゼロ状態からの構築である。
ただ、ハードウェアとしては今回の失敗を教訓に、もっと単純な構成を執る事として、IRSTなどの高速化手段は採用しない。
ただ、それでも従来のBIOSではなく、やはりUEFIモードでのインストールとしたい為、OSインストールドライブはGPT形式のフォーマットを行うし、基本その他のドライブもすべてGPT形式を採用する事にした。
また、今回のトラブル発生に備えて、NVMe M.2 SSDと4TB HDDを準備したため、マザーボードに接続できる限りのストレージデバイスを搭載する事にした。
よって、以下のようなドライブ構成となる。

・NVMe M.2 SSD　…　Cドライブ(起動用)
・NVMe M.2 SSD　…　Optane MemoryだがRAMドライブの代わり
・NVMe M.2 SSD　…　前回のSSDを再利用。高速アクセスデータ用
・4TB HDD　　　　…　新品。今回のシステムのデータストレージ
・4TB HDD　　　　…　前回のデータストレージ
・SATA SSD 128GB…　予備高速アクセスデータ用

これをメインPCの中に全て載せ込む事にした。
データストレージは高速アクセスが必要なものとそうでないものに分けて、必要なものはNVMe M.2 SSDにインストール＆保存、高速アクセス不要のものは4TB HDDにインストール＆保存という事にした。
前回のデータストレージはとにかく今回のデータストレージにデータを移設していくが、終わり次第、新たなデータストレージへと再生させていく。
128GBのSSDは、前回FF14用として単一使用していたが、今回はNVMe M.2 SSDにFF14をインストールする予定なので、今回は予備の高速アクセスデータ用として使用する事にした。

迷うOptane Memory

Optane Memoryだが、正直使い方に迷っている。
今はネットからダウンロードしたデータの一時退避エリアとして使用しているが、これはもともとメインメモリの一部をRAMディスク化して使用していたものの代わりとして使用している感じなので、別に必ずしもそのように使う事を目的としているわけではない。
ただ、IRSTとして使用しないのであれば、まさに手動でキャッシュ的な使い方をする使い方しか出来ない容量(32GB)なので、今の状況と同じくネットデータストレージとして使用するスタイルで行く事になるだろう。
正直、もったいない使い方とも思っているのだが、復旧できるか分からないという状況を体験した身ともなれば、この恐怖を再び感じる事のないように使って行くしかないだろう。
まぁ…壊れる事前提にIRSTとして使用するという手もあるにはあるが。

Continue reading…

最後のあがきともとれるがやってみる。

コマンドプロンプトからの復帰

メインPCのシステムが動かなくなり、もうすぐ2週間が経過しようとしている。
ハッキリ言って、今までこんなにメインPCが稼働しなかった時間はない。
何故なら、今まではトラブルが起きても失うデータが大したデータではなかったからだが、今回はIRSTによって疑似RAID化したドライブに今まで蓄積してきたデータを入れていたという事もあり、その疑似RAIDを解除しない状態でシステムが稼働できなくなった事で、蓄積してきたデータを失う可能性が濃厚になった事で慎重にならざるを得なくなった。
いろいろIRSTの強制解除の方法など調べて回ったが、結局自分のシステムでは「Ctrl+I」というIRSTのROMをPost時に読み込むコマンドが使えない(本来は使えるらしいが、どうも上手く働かない)という事から、あわよくばUEFI BIOSから強制解除してシステムの再構築をする必要があるかもしれないという覚悟を決めたが、やはりそこは長年蓄積したデータが人質なので、今一つ踏ん切りが付かなかった。
そこで、ネットでいろいろ調べた最後の手段として、コマンドプロンプトによるシステム復帰を試してみる事にした。
具体的には、Windows10のシステム自動回復の画面を出して、そこからコマンドプロンプトでの起動を選んで、そこから直接コマンドを入力して修復を試みるという手段だが、使えるコマンドがいくつかある。
そこで「sfc /scannow」というコマンドを使ってみる事にした。
これは「システムフォルダ内に不正なファイル書き換えが見つかった場合、この機能で元に戻す試みをする」というコマンドである。すると…何と、一部ではあるが修復できたファイルがあるらしい。言い方としては「破損したファイルを見つけたが、それらの一部は修復できなかった」という事らしいが、多少なり望みは出たのではないかと勝手に良い方に解釈した。
実際に使用したコマンドは「sfc /scannow /offbootdir=c:\ /offwindir=d:\windows」というコマンドではあるのだが、これを何度か繰り返した後、もう一度再起動してみると事にした。

奇跡は起きた

このコマンドプロンプトの修復を実施した後、再起動してみたところ、いつもと違う挙動になった。
今までずっと白い点がくるくるまわるだけの起動画面が、真っ青になったのである。…いや、ブルースクリーンだったらそれはそれで問題なのだが、ちょっと違うのは、左下に時刻が表示されているのである。コレ…ひょっとして起動画面じゃないのか？
というワケで、恐る恐るキー入力してみたら、パスワードPINの入力画面に突入した！
完全ではないものの、一部の機能が回復し、エクスプローラー等の機能が実行され、部分起動している事が判明した。実際、スタートメニューのキーを押しても何も起きないので、ほぼエクスプローラーと一部のサービスプログラムが起動した、というだけだったのかもしれない。
スタートメニューが表示されないので、プログラム起動はファイルから直接起動ファイルを指定して実行するしかない。
そこで「IntelSmartResponseTechnology」のフォルダを探し出し、UIの起動プログラムを立ち上げてみた。ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
画面がモアレだらけではあるが、IRSTの管理画面が立ち上がり、そこで高速化していた(RAID構成になっていた)ドライブの無効化が実行できたのである！

Continue reading…

実はまだ復帰させてない。

Windows RE

10月7日に起動しなくなったメインPCだが、実はまだ復帰させていない。
理由は…やってしまうと後戻りできないという事に慎重になっているという事と、単純に時間がないという事なのだが、実はいろんな側面から情報をかき集めているという事も理由の一つになる。
というのは、一度試して駄目だった、スタートアップ修復やシステム復元などのWindows7以降に搭載された修復システムについて、あまり内容を知らないからである。
スタートアップ修復とは、一体どういう事をしているのか？
セーフモードと何が違うのか？
そういった処理内容がよくわからないので、どういった対応ができるのかをもう一度知る必要があると思ったのである。
Windows10の「設定」内にある「更新とセキュリティ」からも入れるが、この中に「回復」という項目がある。この中にある「PCの起動をカスタマイズする」という項目で再起動をかけると、Windows10の起動時にトラブルシューティングに対応する回復メニューが出てくるようになる。
この回復メニューは、Windows10が2回正常起動しないと判断した時にも起動するようになっていて、この回復メニューから、前述の「スタートアップ修復」や「システム復元」などを選べるようになる。
で、いろいろ調べて見た。
「スタートアップ修復」だが、やっている事はものすごく原始的な事で、もともとWindows7以降はWindowsインストール時に「Windows RE(回復環境)」がインストールされ、起動できなくなるとこの「Windows RE」が起動して自動修復するようになっている。
もちろん、全ての問題を修復できるわけではないのだが、従来のセーフモードでも修復できない問題を修復するのが「スタートアップ修復」と言われるモードである。
これだけ訊くと「じゃあ、セーフモードで修復せずにスタートアップ修復使えばいいんじゃない？」となるのだが、これが違うのである。

自動回復

そもそも、セーフモードとスタートアップ修復で行う修復方法は内容が異なるもので、修復する対象も異なるというのである。
もっと明確に言うと「スタートアップ修復」と「システムの復元」と「セーフモード」はそれぞれ相互補完の機能なので、何か一つやれば良い、というものではないのである。
その中でも「スタートアップ修復」が修復するものは「Master Boot Record(MBR)」と「起動に関するシステムファイル」で、今までWindowsが苦手としてきたMBRを修復できるようになったのは意義としてとても大きい。
ただ、最近はUEFI環境の元でGPT形式でフォーマットするので、GPT形式を修復できるのかはわからない。まぁ、できるだろうと思うが、そうした原始的な問題を解決できる方法が「スタートアップ修復」なのである。
「システム復元」とは、Windows起動時に復元ポイントを作成しておけば、その時点での状態を回復するという機能なのだが、これは主にレジストリの回復手段と言える。もちろんドライバの更新などの情報も含まれるので、ドライバの影響による起動問題も解決できるのだが、基本的に起動時の設定修復という側面が強い。
ただ、これらの修復機能を使用しても、全ての問題を解決できるとは限らない。今の私の状態がまさにソレなのだが、ほとんどのケースで、修復作業は失敗しても数回実行する事が望ましいとされている。
というのは、修復しなければならない箇所が2箇所あったとして、最初の修復箇所は2つ目の修復箇所を修復した後でないと修復できない、なんてケースだと、当然1回の修復では直らないワケである。
なので、スタートアップ修復など、Windowsの自動修復は一度やってダメだと思っても、複数回やってみると回復する場合があるので、試す価値はあるだろう。
…私の環境ではダメだったが。

Continue reading…