|
前置きはどうでもいいんです。
ＰＣが起動しなくなる事ってありますよね？
誰でも１度は経験してると思うのですが…。
今日は その事について書いてみようと思います。
ＰＣが起動しなくなる原因はたくさんあります。
大別すると ハードウェアの故障の場合と ソフトウェアの設定エラーの場合があります。
ハードウェアに原因がある場合、それは【故障】そのもので起動できる筈がありません。
物理的に壊れているわけで、当然の事ながら物理的な修理が必要です。
そして修理が可能か否かは、その故障個所で決まります。
基本的には どんな故障でも物理的な修理を行えば、動作するようになるのですが…。
それは 飽くまでも電気的に動作可能になっただけで、起動が保証される訳ではありません。
まずハードウェアとして正常動作を保証できるようになっただけなのです。
コンピュータはソフトウェアを含めて動作するものですから、
絶対条件としてはハードウェアに故障が無い事ですね。
さて…。
ハードウェアに関しましては、一端 ここで打ち切ります。
問題はソフトウェアなのです。
まず 単純に考えてください。
Ａというプログラムはコンピュータの電源を切る処理を行います。（終了処理）
Ｂというプログラムはコンピュータの電源を入れる処理を行います。（起動処理）
マルチタスクなので、どちらも同じ優先度ならば同時に実行できる筈です。
さて、同時に実行するとどうなるでしょう？
簡単に言うと、「互いに矛盾する命令を同時に与える」という事ですね。
現実には矛盾を回避する仕組みがあって、どちらかの優先度を変更し、
結果を保証する仕組みになっています。
また現在のコンピュータはＣＰＵが複数搭載されていても、１個の 【主（マスター）】になるＣＰＵ と
複数の【従（スレーブ）】になるＣＰＵがあって優先度も決まっています。
ここにも矛盾を避ける仕組みがあって、同時に複数の命令は実行できません。
また 実行タスクが複数あったとしても、単一ＣＰＵでは同時に実行できる命令は1個だけなのです。
ＣＰＵが複数あったとしても、実行結果を制御するＣＰＵは１個なので、結果的に逐次処理となります。
という訳で、実行結果そのものがバッティングする事は無いのです。
と、先に理想論から書きましたが、現実には それが起こる場合があります。
いちばん稀なのは、周囲の電磁波や宇宙線の影響でデータそのものが書き換えられてしまう場合です。
逆にいちばん多いのが人為的ミスで、自動書き換えするデータを誤って手動で書き換えてしまうパタンです。
人為的ミスの場合は発見は容易です。 変数の変化を追えば良いのですから。
この手の多くは ポインタの操作エラーに起因し、存在しないメモリー範囲やアクセス禁止範囲に
データアクセスする事によって起こります。
大抵の場合、ＯＳが検出し、その後の処理をストップさせますが、
その範囲を超えると 俗に言う【ブルースクリーン】になります。
さらに ＨＤＤの起動セクタに誤って書き込んでしまうと起動不能になります。
現実に最も困るパタンはアプリ同士の資源の奪い合いです。
アプリは起動させた本人が内部仕様を知らないだけに、どこでコンフリクトが起こっているか分からないからです。
特徴的な動作なら見当は付けられても、内部動作は知りませんから修正のしようがありません。
問題が発生するアプリ同士を同時に使わない事でしか回避できません。
ここまでは ある程度原因を想定できる範囲です。
ですから 原因と思われるものを取り除けば 何とかなるものです。
また、ソフトウェアの破壊ですが、ハードウェアが壊れた訳ではありません。
ソフトウェアを正しく設定できれば元に戻ります。
ところが、今までに上げてきた内容とは全く別な原因で起動しなくなる場合があります。
それは最悪のパタンで、いわゆる【自爆】なのです。
そして、最も酷いモノがハードウェアの破壊です。
通常、ソフトウェアの異常による起動不能の場合、ＯＳを再インストールしなおせば元に戻ります。
ですが、ソフトウェアがハードウェアを破壊する場合もあります。
私は これを自爆と呼んでいますが、実際に有り得る事なのです。
「ソフトウェアにバグは付き物」 これは誰でも知っています。
実はハードウェアにもバグがあります。
コンピュータ内部にはＣＰＵ以外にも 様々な集積回路が使われています。
ＣＰＵとは異なり、特定用途に特化した集積回路なのですが、構造的にはＣＰＵと変わりません。
ＣＰＵを含めた集積回路では「レジスタ」と呼ばれる部分で命令を解釈します。
その命令は物理的に見ると スイッチ操作命令そのものだったりします。
ハードウェアでのバグ回避方法は、「ありえない命令」を拒否（無視）する方法で実装されます。
ですが、レジスタに書き込まれた以上は何らかの動作も伴ないます。
「処理を無視する」とは 他への影響を与えない という事なのですが、
ソフトウェアを作成する場合、通常は そのような命令自体を与える選択肢が無くしてあり、事前に回避しています。
言わば、そのような命令自体が使えなくしてある訳です。
ところが アセンブラなどで うんとミクロなコードを記述する場合、そういう使い方ができてしまいます。
ＬＳＩに与える命令セットなど特定パタンを禁じ、そのコードを与えると結果は不定になる場合があります。
不定 の意味としては「演算結果が保証されない」という理解でも良いのですが、
そのＬＳＩが動作を制御する物であった場合は話が違ってきます。
具体的には 「何が起こるか分からない」 という意味になります。
ＬＳＩ（デジタル集積回路）はスイッチの化け物 でもあります。
その特定の命令で巨大な電流が流れる結果になった場合、破壊が起こる場合もあると言う事です。
ハードウェアの１部品ですから、最低限の安全性は確認されていますが、壊れる場合もあると言う事です。
そして、そのような命令やデータを与えるのは 他でもないソフトウェアだったりする訳です。
経年変化で脆くなったハードウェアで、そのようなデータやコードが与えられた場合、
最悪 破壊 ⇒ 高温発熱 ⇒ 出火 となります。
もう今は あまり使われていませんが、シリアル通信制御ＬＳＩを触った事があります。
その取説には、 特定の値をレジスタにセットした場合、結果は不定になると書かれていました。
現在のＬＳＩは そのような仕様は有り得ないとは思いますが、
特定の機能以外は開発コストを下げるため、その機能は利用できても保証しない物もあるようです。
「使ってはいけない」という前提でソフトウェアを作りますから、そのような命令やデータは与える事はありません。
ですが 仮に与えてしまった場合には結果は保証されないどころか 壊れてしまう可能性さえあります。
という訳で、ソフトウェアがハードウェアを破壊する場合もある という事を知っておくべきかと思います。
そうなったら、起動しない どころではありませんけどね。
でも、現実には そういう場合もあるようです。
|
ゲーム
