_★_BIOSアップデート後の P3B-F での処置

										（2002年４月　作成）

　　◆2002年６月４日 以降に　ここに記事を更新・追加した。
	　スキャナだけでなく、Ｎo.２の SCSIカードも故障していた事が判明した。（詳細は後述。）
	　
	◇【このページを最初に作成した時点で動いているWin98se】は、
	　故障しているSCSIカードを接続した状態でWin98seをインストールし、さらに　故障に気付かずに【田中式処置】を実行
	　した・・・状態の Win98se
	　である。
	　その時点で動いているWin98se↑ は　【田中式】を実行済みであるが、微妙な不満が残っていた。
	　　（このページを読み進めると理解できる。）
	　
	◇という訳で、
	　以下の このページの報告は、基本的に　上記の【Ｎo.２の SCSIカード（Rex-PCI30）の故障】に気が付く以前の報告である。
	　
	◇また、SCSIカードを故障させていなければ“微妙な障害”も起きなかった訳で、
	　【マザーボードBIOSをアップデートしたＰＣ】で 田中式処置を行なう場合の“工夫手順”としては、
	　以下の報告内容は　充分に有用である（作業手順も有効なハズ）。
	　
	◇このページは 【ＰＣＩデバイス認識の再構築】の解説ページではない。
	　
	　2002年６月 の初めに【ＰＣＩデバイス認識の再構築】を行なって成功し、
	　その成果として、
	　　　　　　　　　【処置後の “ＰＣＩデバイス認識の再構築”】 と 【田中式処置】 の意義
	　という解説ページを作成した。
	　
	　　　※６月４日の時点では　【ＰＣＩデバイス認識の再構築】によって Win98seは“最高にチューンされた状態”となっている。
	　　　　“最高チューン状態”の動作を確認できたので、【SCSIカード故障していたか？】について　最終的な結論を出せた。
	　　　　【SCSIカード故障】については微妙であり、メーカー側も『当方で実物をテストしないと〜。』としか回答しなかった。
	　　　　「故障である」と結論したのは 私個人の見解であり、ＨＰのビデオをダウンロードする人は納得できる。
	　　　　このビデオを録画（動作テスト）した日付は“2002年６月26日”である。
	　　　　動作テストも３日間（10数回）練習した挙句に 公開できるような録画ができた。

	◇【ＰＣＩデバイス認識の再構築】を行なう事を　2002年５月下旬に決意した。
	　実験的な意味合いも込めて、“いま動いているWin98se＋田中式”を　そのまま流用して改善しようという試みである。
	　そして、
	　その実験は 大成功を収めた。
	　【ビデオで公開した動作テスト】で動いているWin98se ＝ ↑この Win98se である。
	　即ち、
	　　【後述するような“微妙な不満”をいくつか抱えた Win98se】に対して、
	　　　　“田中式処置ミニチュア版”とでも呼べる作業
	　　・・を行なったのである。
	　不満のあるWin98se ⇒ 日本一？安定動作するWin98se　に化けてしまったのであるから、次のような言い方も出来るであろう。
	　即ち、
	　【１．故障を抱えてセットアップしたWin98se】⇒【２．故障に気付かずに“田中式処置”を実行】〜〜 ３．微妙な不安定あり 〜〜
	　　⇒【４．ＰＣＩデバイス認識の再構築】〜〜 超/安定化。
	　１〜３の段階でWin98seが内包していた“ウミ”の部分が、　４の作業によって 吐き出される形で “ＯＳの再構築”が成就した。


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


さて、以下は　2002年４月〜５月にかけての報告である。


●【P3B-Fマザーボード】のBIOSアップデート ⇒ 【田中式処置】実行。

　処置の報告　および　注意事項


P3B-Fマザーボードについて。
　　1999年８月購入。
　　'BIOSバージョン' ＝ アップデート前 ＝ 1.003
　　　　　　　　　　　　アップデート後 ＝ 1.006
　　'ハードウェアリビジョン' ＝ 1.03
基盤上のハードウェアは 一切いじっていません。'オーバークロック'等もしておらず、買った時のままです。
	FSBクロック＝100MHz。
	メモリ　128MB×２枚 （PC100　CL2。バルク品。エイサー製。1999年２月購入。）
	ＣＰＵ　PentiumIII 600MHz/256E（Cuppermineコア。バルク品。）

2940U2W（SCSIカード）の 'BIOSバージョン'について。 
　　　　アップデート前 ＝ 忘れました（一番古いバージョンらしい。）
　　　　アップデート後 ＝ 2.572

　　　SCSIカードの型番は AHA-2940U2W
　　　　　（起動ドライブ、Temp・スワップ設定のドライブを接続。）

　※この後の報告の話の中での【BIOSアップデート前＋田中式処置Ｗin98se】では、
　　起動HDD と Temp・スワップ設定HDD を接続したSCSIカードは
　　AHA-2940U2W ではなく　AHA-2940UW です。
　　かつ、【BIOSアップデート前での田中式処置】は ９８％が手作業によるもので、処置を行った時期は　1999年１０月頃です。
　　　（このＰＣに処置を施すのは それ以来 久しぶり。）

　※以下、単に【BIOSアップデート】と記述した場合、【マザーボードBIOSのアップデート】を指します。
　　（【SCSIカードのBIOS】も 同じ時にアップデートしていますが・・。）


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝



■■■ 【序 編】 ■■■


◆このマザーボードの特徴として ＜特記事項＞ が ４つあります。


１．【BIOSアップデート後、田中式処置前】の段階で　
　デバイスマネージャの "システムデバイス"一覧で 「マザーボードリソース」が２つ　存在します。
　これは　"ごみデバイス"・"幽霊デバイス" ではなく、
　通常モードのデバイスマネージャで表示され、それぞれが別の「ＩＯアドレス」を使っています。↓
　　（処置後も同様です。）
							【２つの マザーボードリソース】


２．BIOSをアップデートしただけで　ハードウェアは 全くいじっていない状態で
　　Ｗin98ＳＥをセットアップすると、
　　デバイスマネージャで表示される「システムデバイス構成」が　【i8xxチップセット】のマザーボードとソックリの構成となります。
　　違う点は ただ１点・・・「マザーボードリソース」が２つ存在する事です。
　　　　（デバイス名の６０％が日本語表示）
　　もちろん、「ＩＮＦアップデートユーテリティ」等の組み込みは行っていませんし、
　　Ｗinセットアップ時に インストーラが何かを要求してくる事もありません。【田中式処置】でデバイス認識の再構築を行っても同じです。

　このマザーボードは 【440BXチップセット】のマザーボードであり、
　発売時期から考えても　Detlog.txtの内容から考えても、完全な【ACPI対応マザー】とは言えないと判断できます。

　　　※２つ存在する「マザーボードリソース」のうち　一方が "クッション的な役割" も果たしているのでは・・と想像します。

　【ACPI】という規格は未完成であるだけでなく、それが正常に機能するためには「全てのハードウェアがACPIに対応」している事が条件です。
　この事を念頭において考えてみますと、
　BIOSをアップデートしただけで【ACPIマザー】として動作させるのは 少し無理があるのでは？・・・とも感じます。

　　※マザーボードのハード・BIOS・ACPI そしてWindowsの全てに精通していないと　安易に判断する事は出来ませんけど。



３．ＩＤＥ接続のＨＤＤにアクセスした時の　エクスプローラの【反応（立ち上がり)】が遅いです。
　この現象は【田中式処置】の前でも後でも同様です。

　　　※ただし、【処置】によってこの件で改善があったか否か--については不明です。
　　　　体感的には　少し改善されたようにも感じますが、　元々 「時間を費やした検証」をして報告するツモリはありませんので・・・。

　　※このページを最初にサイトアップしたのは 2002年４月ですが、その後　結論が出ました。
　　　この原因も　下記５で説明する【SCSI-BIOSアップデート直前の不始末】でした。
　　　スキャナの電源を入れたままで Ｎo.２のSCSIカードからスキャナ接続ケーブルを抜いた時、スキャナが故障したのですが、
　　　該当SCSIカードも故障していた事が判明しました。
　　　時々ですが、640MBタイプメディアにアクセス出来ない状況が発生しましたので、
　　　ＭＯドライブ・ＣＤドライブを Rex-PCI30から 2940U2Wに引越し、RexのSCSIカードを取り外し、
　　　その後　もう一度【ＰＣＩデバイスの再構築】を行ったら　この ３の現象は解消しました。
　　　下記４で説明する「ＭＯドライブの不思議な現象」も解消しました。
　　　　（上記の８行は 2002年６月４日に追加したものです。）
　　　いま述べた【ＰＣＩデバイスの再構築】の解説は このページにはありません。
　　　その解説は　こちら ↓ 。

　　　　　　※詳細については、 「【ＰＣＩデバイス認識の再構築】 と 【田中式処置】の意義」 を参照して下さい。

　３の現象が発生するのは　下記の【特定の条件】が揃った時だけのようです。

　・【My Documents】の中で、「長い名前のフォルダ」・「長い名前のファイル」が たくさん存在し、かつ
　　深い階層の「長い名前のフォルダ」にアクセスした時。
　　　　（特に「削除・リネーム」を行った時。）
　・この現象はＩＤＥのＨＤＤの場合だけで、SCSI のＨＤＤの場合は　一切 発生しません。
　・遅いのは「立ち上がり」だけのようです。
　　「継続的的なアクセス」に関しては　CPUの性能アップとHDDのフォーマット変更の分は 確かに高速化されているようで、
　　スキャンディスク・ウィルススキャンの動作ではかなり速くなったように感じます。
　　正確に測定していませんが、体感的には少なくとも１.５倍くらいに感じます。
　　　　※参考までに、
　　　　　ディスク処理については　SCSI-HDDの方は ほぼ２倍近い処理スピードとなっています。
　　　　　ただし、NETアクセスに関しては 【古いモデム ＋ ダイヤルアップ接続】が災いして遅いです。
　　　　　このモデムを組み込むと１９９３年のファイルが systemフォルダに突っ込まれるくらいですから、仕方ありません。
　・「立ち上がり」の遅さをカバーする目的で、
　　PathCache と NameCache を大きくしてやろう・・・と思いました。
　　システムのプロパティ⇒パフォーマンスで【ネットワークサーバー】に設定したら改善されました。
　　まだ余裕が無いので　原因も状況観察も不充分ですが、その原因についての「想像」はしています。
　　このマザーボードで　今時 【ATA３３】のＨＤＤを装着して、なおかつ BIOSをアップデートする人は かなり少数派でしょう。
　　だから　BIOSが ATA６６ もしくは ATA１００に最適化されているのかも知れません。
　　特に　私が装着しているＨＤＤは【初期のATA３３】の物ですから・・・。
　　ＨＤＤ自体に関しても、
　　　『【ATA100に最適化されたHDD】を ATA66のIDEコントローラに装着したら　急にＷinが起動しなくる障害が発生した』
　　との 例があります。



４．ＭＯドライブで、
　【２KBセクタタイプのＭＯメディア】を使った後で　【通常タイプのＭＯメディア】に刺し替えて使うと、
　Ｗin98ＳＥが「刺し替えを認識」した段階で ３〜４秒の間（２回）「Ｗinがオネンネ」します。
　その後 不具合は発生する訳ではありませんが、「一時的に鼻でもつまったのか？」という雰囲気です。
　この現象は【田中式処置】の前でも後でも同様です。

　　　※ただし、【処置】によってこの件で改善があったか否か--については不明です。
　　　　　（処置の前は 回数的に何回も何回も観察した訳ではない。）

　この件について不思議に感じる事があります。
　このＭＯドライブは　このＰＣに最初に【田中式処置】を行った後で 購入したものであり、上記のような現象はゼロでした。
　処置後のＭＯ購入ですから　【田中式処置】を行う前の挙動については不明ですが、
　たぶん問題は無かっただろうと思います。
　　（そうでないとすれば　ドライブ自体にクレーム続出だったハズです。）
　とすれば、「BIOSアップデート」が影響しているとも考えられます。
　あるいは、【SCSI-BIOSアップデート直前の不始末】が影響しているかもしれません。（後述）



５．【SCSI-BIOSアップデート直前の不始末】
　この不始末によって 結果的に スキャナを故障させてしまいました。

　今回は色々と作業が多いので　作業手順書を作成して臨んだのですが、
【マザーボードBIOSアップデート】の直後、　2940U2W のBIOSをアップデートする直前に　Ｎo.２のSCSIカードを外していない事に気が付き、
　この時　あわてたために 
　スキャナの電源を入れたままで Ｎo.２のSCSIカードからスキャナ接続ケーブルを抜いてしまいました。
　このミスが原因で スキャナは故障しました。
　ミスの後 すぐに気が付いて　スキャナ単独で "電源ＯＮ" にしてみましたが、
　１時間経過しても２時間経過しても ウォーミングアップが終了しません。

　　　※あとでメーカーに状況を説明して確認したら "故障" したことに間違いないようです。
　　　　スキャナ接続ケーブルを抜いた瞬間に「あ、しまった。」と思い、以後　１度も接続していません。

　スキャナに電源を入れたまま接続ケーブルを抜いた "相手" のSCSIカードは　先のＭＯドライブを接続してあるSCSIカードです。
　この時の不始末が どの程度 影響しているかは　まだ判りません。


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝



■■■ 【本 編】 ■■■


本処置での「自動検出＋自動設定」は２回しか行われませんでした。
　【検出＋設定 の内容】は違いますが、検出プロセスを全部つなげれば 検出の密度とパターンは ほぼ同じです。
　　（間に入る'再起動'の回数が異なるだけ。）
ただし、↑これが 'クセモノ'で、検出プロセスで行うべき【人間側の対応】が 通常とは異なる部分がありました。
　　　（'Ｗin98ＳＥ標準ＣＤ'のみで全デバイスを認識しますが。）


◆第一回の処置作業は 「失敗したかな？」と思いました。

　　※困ってしまって、途中まで戻ってやり直す覚悟を決めました。
　　　困ったついでに『無茶なこと』をやりましたが、この内容は報告しません。



困った事として、要約して２点あります。


◆＜困った事　その１　（処置の最後の段階)＞

　２回目の検出で、
　【Intel 82443BX Pentium(r) II Processor to PCI bridge (with GART support)】の情報ファイルを求めて来ました。
　【正解_デバイスドライバの更新_画面.bmp】 の手順から入っても　自動でデバイス認識しません。
　　（ＩＮＦフォルダには 情報ファイルが置かれているハズですが。）
　これはいままでに無かったことです。

　★★★　重 要　★★★　（特殊な例）

対策としては、
最初は いったん【誤り_デバイスドライバの更新_画面.bmp】から入り、検索場所として　C:\windows\INF を指定してやれば大丈夫です。
　　　　　　　　（フロッピーの□のチェックは外しておく。）
　　こうしないと 情報ファイルの場所を Ｗindowsが認知できないようです。
　★これは　BIOSアップデートした特殊なケースであり、　通常は　【手順書】の指示に従って下さい。

他のデバイスでは　おおむね 【正解_デバイスドライバの更新_画面.bmp】 で大丈夫です。



　◇【要 領】：
　　基本的には【特定の場所〜】から入りますが、
　　「互換性のあるハードウェア」の表示欄が 空白で　【次へボタン】を押せない状況になった場合のみ、【戻る】で戻って、
　　【現在使用している〜〜（推奨)】から入ります。
　　あとは　検索場所に C:\windows\INF を指定してやれば大丈夫です。

このようになってしまう原因ですが、
　【BIOSアップデート】した事が原因で 【合いの子マザー】という認識となるのか、検出・設定のプロセスで　Ｗindowsが 多少迷うようです。



◆＜困った事　その２　（処置の最後の段階)＞

　　※'SCSIのＨＤＤ'と'IDEのＨＤＤ'の両方を接続している場合だけ　この困った状況に陥る・・と想像されます。


検出に伴う【再起動回数】が　通常の３〜４回よりも減った事によって、
【PCI バスマスター IDEコントローラー】の組み込みの直後に　一時的に【インストール元】にアクセス出来ない状況が発生します。
【BIOSアップデート済みマザーボード】で処置を行い、
この状況に遭遇した時点であきらめた方もいるのではないでしょうか？。

　　※通常、"検出・認識・ドライバ組み込み" が 正常に 完了していても　最後に 『完了していません』と表示される場合、
　　　これは 再起動をして 初めて そのデバイスにアクセス出来ます。
　　　【PCI バスマスター IDEコントローラー】が これに該当します。

話が複雑ですね・・。
つまり、【BIOSアップデートP3B-Fマザー】では　２回目の検出で　全デバイスの組み込みが完了してしまいます。
　（同じ'P3B-Fマザー'でも これは初体験で、なぜ　そうなるかは不明です。）
私の場合、【インストール元（Win98_ＣＤ)】をＩＤＥのＨＤＤに置いており、Ｗindowsにも そのように認識させて 処置を行いました。
ところが　起動ドライブがＳＣＳＩである事が理由で、
【PCI バスマスター IDEコントローラー】の組み込みの直後でも Ｗindowsが『HDDアクセスに支障を感じない』らしく、
Ｗindowsが【再起動 必要】と認識せずに そのまま先に進んでしまう事が原因です。
そのため、
次の "デバイス組み込み" からは【ＩＤＥのＨＤＤ】にアクセス出来ない状態になりました。
　（これは　マザーボードBIOSをアップデートした事が影響しているでしょう。）

　　※【PCI バスマスター IDEコントローラー】を認識するまでは
　　　リアルモード用のＩＤＥコントローラで動作していますからアクセス出来ます。

　　※通常は、【PCI バスマスター IDEコントローラー】の認識・組み込みの後は　Ｗindowsが【再起動 必要】と認識して再起動を求めます。

　★★★　重 要　★★★　（特殊な例）

　◇【対 策】：
　　処置作業の【インストール元（Win98_ＣＤ) ⇒ ＨＤＤにコピー】の段階で、'SCSIのＨＤＤ'と'IDEのＨＤＤ' の両方にコピーして置く。

　◇【私の場合の対策】： 
　　【ＩＤＥのＨＤＤ】にアクセス出来なくなった事と　【検索場所に C:\windows\INF を指定】出来ずに 'スキップ'した事
　　の２点を除いては、
　　一応は デバイス再構築が完了したものの、やり直すことに決めました。
　　Ｄos起動し、【DEL_BACK.bat】で途中まで復旧しました。
　　この時点で　≪「デバイス認識の削除 完結」 の状態が 復元されていますので、
　　ここでＰＣを再起動すれば　'検出プロセス'が もう一度 始まるのですが、
　　この時の　ＰＣ再起動直前のＤos環境で 【IDE_HDDのインストールset】を SCSI_HDD にコピーし、その後で ＰＣ再起動しました。
　　この【中途やり直し】での検出でも、
　　【PCI バスマスター IDEコントローラー】の組み込みの直後に【インストール元】にアクセス出来ない状況になりました。
　　これが原因で SCSIカードのドライバ（*.mpd）の置かれた【インストールset】をＷindowsが欲しがります。
　　　（IDE_HDDにアクセス出来ない。）
　　そこで、IDE_HDDの代わりに　SCSI_HDD の【インストールset】を指定しました。
　　このスタイルで行うことによって 田中式処置を無事に続行できて　完了しました。



◆＜参考までに＞

　２回目の検出で、
　【Intel 82443BX Pentium(r) II Processor to PCI bridge (with GART support)】の情報ファイルを求めて来ますが、
　このドライバ情報は　Machine2.inf（1999.5.5）の中に含まれています。
　だから、【検索場所に C:\windows\INF を指定】できれば 問題ありません。
　因みに、
　先の【私の場合の対策】で 一応は デバイス再構築が完了した〜〜と書きましたが、
　『これで良し』と判断する人もいるでしょうが　それは甘いです。認識・組み込みの順番が変更されてしまっている事に留意する
　必要があります。



◆＜田中式処置による再構築　の結果・・特記事項＞

　【システムデバイスの構成】が　BIOSアップデート前と比較して　Ｗinセットアップの段階で 『全くの別物』に化けていました。
　i820・i815マザーのデバイス構成の内 60％を日本語表示した感じです。

　　　※このマザーは '440BXチップセット'ですが、
　　　　マザーボード上システムデバイス等の【デバイスの列挙ツリー】の構成は　i820・i815マザーの構成と酷似しています。

レジストリ内部での【デバイスの列挙ツリー】は
　HKEY_LOCAL_MACHINE\Enum\BIOS ではなく、　HKEY_LOCAL_MACHINE\Enum\ACPI の配下に構築されています。
　従って、【マザーBIOSアップデート】の後で そのまま Ｗin98を起動したら
　何か 微妙な障害が発生したのではないか・・とも想像できます。

【ＩＲＱ共有のためのホルダー】の認識名は、
　マザーBIOSアップデートの前では 【PCI IRQ ステアリング用 IRQ ホルダ】でしたが、
　マザーBIOSアップデートの後では 【PCI IRQ ステアリング用 ACPI IRQ ホルダ】　となっています。

マザーBIOSアップデートの前では　マウスユーティリティをセットアップしますと
　マウスのデバイス認識 ＝【Microsoft PS/2 IntelliMouse with IntelliEye (IntelliPoint)】　と変更されていました。
　（処置前も処置後も）
　しかし、マザーBIOSアップデートの後では　マウスユーティリティをセットアップしても　マウスのデバイス認識 ＝【PS/2 互換マウスポート】
　のままです。（処置前も処置後も。）
　なぜ こうなるのか　まだ解りません。　（想像できる事もあるが 後述。）
　【Micro〜〜Point】と認識されていた時と比べて、マウスの動作に 違いは全くありません。

マザーBIOSアップデートの前後での 様相の違いは　他にも ありますが、すぐに気が付く点・目立つ点は この位です。



◆＜BIOSアップデート〜Ｗinセットアップの直後・・動作の特徴（田中式処置の前）＞

　'シャットダウン'を行った時、シャットダウンに要する秒数が半分程度になりました。
　　以前のように【状況によって何秒もかかる】事はありません。
　　安定度については 少ししか報告できませんが、
　　【BIOSアップデート前＋田中式処置Ｗin98se】と比較しますと 【青画面】は改善された印象です。（フリーズは発生する。）
　【階層構造の深い 'フォルダ・ファイル郡'】をコピーした場合、フリーズします。
　ただし、どの程度の確率でフリーズするかまでは確認していません。

　　　※あまり何度もテストすると　せっかく新規にＷinセットアップしたのに　変調になってしまうのが嫌でしたので・・。
　　　　２度ほど試して『やっぱり・・』と感じた段階で レジストリを書き戻し、すぐに処置の作業を開始することにしました。



◆＜BIOSアップデート〜Ｗinセットアップ〜田中式処置　の後・・動作の特徴＞

　まだ処置が済んだばかりで 詳細を報告できる段階にはありません。
　　（これを書いている今も　まだ'標準ＶＧＡ'で動作。）
　一点だけ 動作報告できます。
　先のテストと同じ条件で【階層構造の深い 'フォルダ・ファイル郡'】をコピーしても、フリーズしません。


　＜参考データ １＞：

　上記のテストでコピーした 'フォルダ・ファイル郡' は、ファイル数＝1305、フォルダ数＝249、ファイル総量＝822ＫＢ です。

　　※不思議に感じる事があります。
　　　フリーズするかしないかは、【ファイル郡の総サイズ】ではないのです。
　　　『階層構造が深い』事と『多数の'フォルダ・ファイル郡'』である事がポイントです。

　ファイル郡の内容は 【Favorites、スタートメニュー、デスクトップ】です。これは　以前から '退避フォルダ'にコピーしてあった物です。

　【処置を行った後】の場合の 'コピーテスト'では　もう１回行いました。
　２回目は、
　これに加えて【１Ｇバイトのファイル郡】も同時にコピーさせました。
　全ドライブの間で相互にコピー動作が起きるように コピーさせました。
　この場合、さすがに まだ'標準ＶＧＡドライバ'で動作していますから、
　コピー完了の後　エクスプローラをタスクバーで終了させた時、
　エクスプローラは反応しますが　画面表示が完全に通常状態になるまで　多少のタイムラグがあります。
　これは　今までの経験から判断して、専用のディスプレィドライバを組み込めば解消すると思われます。
　専用のディスプレィドライバを組み込んだ後で 徐々に もっと厳しいテストを行ってみるツモリです。
　単純なテストとしては　コピーよりも　実は 【削除（深い階層・多数のフォルダ郡)】の方が エクスプローラは'苦手'です。
　因みに、
　【期待した程の大きな効果は無かった】という報告を 一部のユーザーからフィードバックされていますが、
　その場合でも　このようなコピーテストでは改善されています。
　この種のコピーテストすら改善されない場合は　処置のプロセスにおいて、何かヤリ損ねている事を疑って下さい。


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝



◆＜今回の工夫＞ ： 


１．COMポート No.２
　今回は　処置前どころか Ｗindowsセットアップの段階から 【COMポート No.２】は　マザーボードBIOS で殺しておきました
　（使う予定が無い）。



２．ＵＳＢ
　ＵＳＢは 使う予定も無く、少しでも【ＩＲＱの空き】に余裕を持たせておきたい・・という気持ちもあって、
　処置での再検出が一応すんだ時点で すぐに【ＵＳＢを使わない設定】にしました。
　この設定を行ったタイミングは　【自動検出・自動組み込み】の終了後　ビデオカードとＤＭＡコントローラの認識を修正させる直前ですが、
　このタイミングは '今までの勘' で決定したもので、これが最善かどうかの検証は 今後の観察に委ねられます。
　このタイミングを選んだ事自体の効果は無いかも知れないし、【マイナス効果】かも知れません。



３．サウンドカード
　今回は　　【ビデオカードの専用ドライバ】の組み込みよりも先にサウンドカードを装着し、ドライバを組み込みました。
　　※サウンドカード装着した時に　Ｗinが【検出・組み込み】を行った時に ＩＲＱの割り振りが 再配置・変更される事が多い。
　　　ＡＧＰの従属スロットにサウンドカードを装着するツモリなので　この２つは同じＩＲＱを使うことになる
　　　であろうから、「変更されるのなら 先に変更させてしまおう」と　考えてみただけ。
　　　ただし、私のビデオカードは "キャプチャーカード" の類ではなく 通常型ですから
　　　ビデオカードのＩＲＱは「形だけ」に近く、やっただけの効果は無さそうとも感じる。
　　　ましてや、サウンドカードを装着していない現在　ＩＲＱの５番にアキがあるし、効果は無いだろうと予想したが、
　　　弊害が生じる事も無いだろうと考えた。

サウンドカードを装着していない段階で 'ＩＲＱの空きが無い'ようなＰＣでは 効果があるかも知れません。
　　※現在　このＰＣではＩＲＱの５番には 【PCI IRQ ステアリング用 ACPI IRQ ホルダ】だけが 充てられており、
　　　事実上　'空き'になっています。


　◆【参 考】
　　【PCI IRQ ステアリング用 ACPI IRQ ホルダ】の制御の対象となるデバイスである限り、
　　「ＷindowsのＩＲＱシェアリング」の対象となり得る。
　　ＩＲＱ独立使用のＰＣＩスロットに装着したカードであっても、
　　ＩＲＱが不足する状態になれば Ｗindowsが 勝手に「ＩＲＱシェアリング」を行う。
　　また、ＩＲＱシェアリングについては、
　　どうやら、特定のデバイスについて　ユーザーの側から「共有するな」・「共有させろ」の指定は　出来ないようである。
　　今回　このマザーでのＩＲＱ割り当ては　特に優良でもなく不可でもない状態となったが、
　　私が訪問して処置したＡ氏の【ＴＵＳＬ２−Ｃマザー】では
　　Ｗinセットアップ前に　【19160 SCSIカード】のＰＣＩスロット位置を変更しておいたのは正解だった。
　　19160カードは マルチチャンネルだし、後々 うんと働いてもらう事を想定して追加注文したものであるが、
　　納品時の装着スロットが（何番だったか）【ＵＳＢ】とＩＲＱを共有するスロットに差されていた。
　　少し面白くないと感じたので、【ＩＲＱ占有】と設定され易いスロットに差し替えた後で Ｗinセットアップした。
　　そして　処置がとりあえず完了した段階で、
　　まず　デバイスマネージャで　２セットの【ＵＳＢ】の内　１セットを「使用しない」という設定にし、再起動した。
　　　（ＰＣ所有者のＡ氏いわく「USBはディジ−チェーン出来るし、USBデバイスはせいぜい３〜４つしか使わない」との事。）
　　こうしておいてから　サウンドカードを装着し、
　　　　−−−中略−−−
　　完了。
　　最終的に【19160 SCSIカード】のＩＲＱは独立占有の形となり、「不自然なＩＲＱ共有」にはならなかった。
　　SCSIカードの追加購入を強く勧めた私の面目が立った。
　　ＩＲＱに関する調整について　後で 感じた事がある。
　　【440BX マザー】の場合は 何もしなくても「そこそこの状態」になるのに、
　　【i8xx マザー】では　こういう調整をしてやらないと　若干の不満が残る・・・ちょっと面倒である。


【Ｄos版のドライバ・Ｄos版のユーティリティ】は 組み込みませんでした。
　　（日本語Ｗindows環境では動作が保証されないので。）
サウンドカードの付属ユーティリティは 利用する予定も無いので　組み込みませんでした。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


　◆追加の報告です。

　＜参考データ ２＞：

　・【サウンドカード＋専用のディスプレィドライバ＋マウスユーテリティ】を組み込んだ後で
　　 'エクスプローラで削除テスト' を行ってみました。
　　先に【コピーテスト】でのエクスプローラの挙動を説明しましたが、
　　一般的に、コピーよりも削除作業の方が【エクスプローラ沈黙】になりやすいのです。
　　そこで、大量の削除作業を行いました。

　　削除ファイルとして 次のものを用意しました。
　　【Ａ】ファイル数＝1305、フォルダ数＝249、ファイル総量＝822ＫＢ
　　　　　（先の退避フォルダと同じ物（Favorites、スタートメニュー、デスクトップ）。）を２セット。
　　【Ｂ】現在の【Ｃドライブ全体コピー】を５セット。
　　まず、
　　【Ａを１セット＋Ｂを１セット】を一気に削除しました。楽勝です。
　　次に 【Ａを１セット＋Ｂを４セット】を一気に削除しました。
　　削除して１秒後くらい後で タスクバーでエクスプローラを閉じました。
　　これは すんなりと終了されますが、直後に デスクトップ画面表示が停止しました。
　　スタートメニューや [タスクバー・デスクトップのアイコン] は正常に動作しますが、
　　削除直後のエクスプローラの表示が "画面の残像"みたいな形で残っています。エクスプローラの右ウィンドゥはクリアされています。
　　『おや？』と思って 何もせずに眺めていたら　３〜４秒後に元に戻りました。
　　この状況を 以前と比較しますと、
　　【BIOSアップデート無しの 'Ｗinセットアップ直後'】よりは良い状態です。
　　　（Ｗinセットアップ直後の場合は ズ〜っと黙ったママ。）
　　　【BIOSアップデート無し＋田中式処置】の後よりは劣る状態です。
　　【BIOSアップデート有りの 'Ｗinセットアップ直後'】よりも良い状態です。
　　この３つの状態と 現在の状態を比べて見ますと、【BIOSアップデート】を行った結果は　必ずしも良い事ばかりではないようです。

　　　※BIOSアップデートをしないと ＣＰＵを PenIII６００MHzに交換できないので、仕方がありません。

　・同じ【田中式処置有りのＷin98】で 【BIOSアップデート】の有り・無しで比較をする事については
　　まだ '優劣'を判断できる段階ではありませんし、同じ条件での比較は出来ません。
　　ただし、ＣＰＵを交換した他に　今回は HDDを【16KBクラスタ】でフォーマットした事も原因か、体感的には相当な速度アップを感じます。
　　まだ ＩＥをセットアップしていませんが、インターネットアクセスにも期待します。



　＜参考データ ３＞：

　話が前後しますが、田中式処置の後の　
　【サウンドカード組み込み】と【ディスプレィカードの専用ドライバ組み込み】を行った状況を報告しておきます。
　　　※サウンドカード型番 ＝【Sound Blaster PCI１２８】
　　　※サウンドカードの装着スロットは　以前も今回も【PCI #1スロット】です。
　　　　（ＡＧＰスロットの'従属スロット'）

　今回も 'ディスプレィカードの専用ドライバ' の前に サウンドカードを組み込みました。
　即ち、処置の後　ディスプレィカードが【標準 PCI VGA】と認識されている状態のままでサウンドカードを装着し、
　ドライバを組み込みました。
　で、
　この サウンドカードのドライバ組み込みの直後 の状況が　【BIOSアップデート無し】と【BIOSアップデート有り】では 違いがありました。

　前回の [処置後の組み込み時] では　
　'サウンドドライバ'を組み込んだだけで【Legacy Device】もすんなり正常に認識されていました。
　何も考える必要はありませんでした。
　ところが、今回は 【Legacy Device】は すんなりとは認識されませんでした。【ＩＲＱ】が自動的には割り当てられませんでした。
　サウンドカード本体の【ＩＲＱ11】が ディスプレィカードと共有される事は予期しており、これは予想通りでした。
　（ハードなゲームはやりません）
　サウンドカード装着前に 【ＩＲＱ ５番】を空きにしておいたのに、
　デバイスマネージャの診断では　『【ＩＲＱ】が不足している事が原因で　Legacy DeviceにＩＲＱを割り当てられない』
　と説明されていました。
　手作業で【ＩＲＱ ５番】に設定しようとしましたが　駄目でした。

　Legacy Deviceは ＤＯＳ窓で'Ｄos版のゲーム'の時に音を出すための【仮想デバイス】ですから、
　私の場合 必要無いので、『使わない設定』にしました。

　　※デバイスマネージャの【Legacy Device】のプロパティで 「このデバイスを使わない」という設定にし、
　　　さらに
　　　サウンドカードのプロパティで『レガシーエミュレーション』を無効に設定すれば デバイスマネージャで【Legacy Device】が消えます。
　　　　（【Legacy Device】は 仮想デバイスです。）

　ついでに ジョイスティックも無効にしてしまいました。
　 （用はありません）
　音楽ＣＤも問題無く聴けますし、Ｗin98では何の問題もありません。また、サウンドカードの付属ユーティリティは組み込みませんでした。

後日　判明した事は、今回は【BIOSアップデート】が影響しているらしいのですが、
普通は　
ＰＣＩのサウンドカードを【ＡＧＰの'従属スロット'】に装着すると　今回のようになる事が多いらしいです。
　　※【PCI１２８】の前、私は【ISAの Sound Blaster 16】しか使った事が無い。

それが嫌なら　サウンドカードを別のスロットに装着するしかないらしいです。
私は　無用な【Ｄos版ゲーム】のために ＩＲＱを消費されるのは嫌ですから、このままで行く事にしました。


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


★マザーBIOSアップデートの後で マウスユーティリティをセットアップしても
　マウスのデバイス認識 ＝【PS/2 互換マウスポート】のままである事についての 想像。
　これは　古い【保存データ】と比較してみれば 判明するであろう・・・と思えます。
　（確実に有効なデータがあるかどうか・・？）

マウスユーティリティをセットアップした時に
"C:\Program Files\Microsoft Hardware\Mouse" フォルダが作成されています。
　　（2002年3月9日 22:43:56）
ほぼ 同じ時刻に　【MOUHID.VXD】というファイルが 更新されています。
　　（2002年3月9日 22:44:04）

　※【4.10.2222　99/05/05】⇒【4.10.2223　99/07/19】

これは　偶然 このタイミングで 'システムファイルチェッカー' を実行していたために正確に判りました。
システムファイルチェッカーによる【CRC一致】の判定は 『NO』となっています。
基本的に、
このマウスは【ＰＳ/２接続】しており、'ＰＳ/２マウス' として認識されますから、
【MOUHID.VXD】が更新される必然性は無いように思えます。
マウスを 'USBマウス'として認識・組み込んで動作させる場合に必要な'ドライバ郡'の内の１つとして【MOUHID.VXD】も含まれます。

USBデバイスが組み込まれて動作する時には、【HIDデバイス】として　Ｗindowsが認識してサポートされる必要があります。
そのため、
Ｗin98が USBデバイスを検出した時は 【HIDデバイスの動作】のために　レジストリのデバイス一覧の中に '仮想デバイス'も一緒に組み込まれます。
例えば、これが行われないと USBマウスは動作しません。
USBマウスを使っている方は　デバイスマネージャで【HID互換マウス】が表示されますが、これは '仮想デバイス' です。
【HID】というのは　'Human Interface Device' の略で、【MOUHID.VXD】の HID も同じです。
　（他にも関連事項として書くべき事はありますが　きりが無いので止めます）

【MOUHID.VXD】が更新された事から想像して、
Ｗindows か　マウスユーティリティのインストーラが迷ったのではないか？・・と想像しています。
そして 『インストーラが迷う』というところに【BIOSアップデート】も関連しているのではないか？・・・と感じています。

　　※無条件に【MOUHID.VXD】を更新してくるのか否か--に関しては　古い【保存データ】を調べてみれば判るでしょう。


『Ｗindows か　マウスユーティリティのインストーラが迷う』という表現は　コンピュータの世界では 実に不適切な表現に見えます。
ところが、ＵＳＢの場合は　これがあるのです。
３年ほど前　
このＰＣで このマウスを購入した時、最初は　ＵＳＢマウスとして組み込みました。
　（当時　このＰＣには【２つのＷin98 SE】を組み込んで 切り替えて運用していました。）

'全く同じマウス'を全く同じように組み込んだのですが、【このマウスに対する Ｗin98の認識名】が　２つのＷin98で異なるのでした。
不思議に感じ、
Ｗin98が【ＵＳＢマウス（HIDデバイス)】を組み込んで動作させるのに必要な'ファイル郡'を調べ、
その存在状況と一覧を ２つのＷin98で調べて比較してみました。
驚いたことに、その数と存在フォルダが 一致しないのです。
その時の状況は 非常に興味深かったので、レポート用紙10ページ程度に書き出し、
「組み込まれる時のＷindowsの挙動」と　組み込み結果としての「ファイル存在状況と一覧」などを記録してあります。
その時の【ファイル一覧】は次の通りです。（記述順と分類は無視）
usbhub.sys、 hidusb.sys、 hidparse.sys、 hidclass.sys、 uhcd.sys、 usbui.dll、
usbd.sys、 mouhid.vxd、 hid.dll、 hidci.dll、 hiddev.inf、 hiddev.cat
（他のＵＳＢデバイスの分は省略しましょう。）
　　※この辺に興味のある方は 【Windows98のリソースキット P.1509〜P.1524】を読むと面白いでしょう。

これらのファイル郡の内、
特定の幾つかのファイルが　２つのＷin98で 片方ではＷindowsフォルダに存在し、一方では systemフォルダに存在する・・・
という状況でした。
マウスの動作は どちらも正常でした。
これも また不思議に感じ、Microsoftに電話してみました。
回答は、
『他にも似たような報告を受けており、USBに関しては なぜなのかわからない。』との事でした。

その後まもなく　このマウスを 'USBマウス' として使うのは止めました。
ドライブ全体保存しておいた物で リカバリーし、ＰＳ/２マウスとして使う事にしました。
'USBマウス' として使うと　状況によっては マウスが『パッ、パッ』と素早く反応してくれないのです。
　（一瞬 遅れてから反応する）


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

　※《おことわり》

【BIOSアップデート後のP3B-Fマザー】について
いまさら　詳細な報告や 厳密な'効能テスト'をしてわかって頂くつもりはありません。
"こうすれば直るWin〜〜" の手順も　今後 頑張れば 70％程度までは自動化させる事はできると思いますが、
これ以上　馬鹿を相手にしても無駄です。
【ゲスの勘ぐり】をする人間には　どんな証拠を見せても無駄でしょう。
【ゲスの勘ぐり】をする人間は、どこまで行っても 【公平な判断】をしません。
彼らは、心の中で、一方的に　強引に【作為的な結論】に誘導するのが習慣になっています。
彼らにとっては、『自分自身の分析が正しく論理的であるか否か』〜〜は　どうでも良いのです。
判断基準は【損得勘定】だけであり、
その勘定で“得”をするためには、それらしい理屈を付けられれば 彼らの心の中では“完結”するのです。
だから、かつて ２ch掲示板で 田中式処置を批判した記事なども、
上級者が 冷静に分析すれば、そのほとんどが【こじつけの理屈】ばかりになっています。


また、今後　研究を続ければ Ｗin2000・ＸＰについても　同様の効果を狙った処置を考案できるでしょうが、
昔から　馬鹿は メーカーの目論見のままに財布を開くことになっています。
コンピュータを使うようになった今日も変わらない・・という事でしょう。


結果が出た事は 自分で判っていますし、ここで報告する理由は　以下のとおりです。
マザーボードが【合いの子】のような認識をされる事が原因のようで、
処置の作業で　検出に伴う人間側の応対を少しばかり変更する必要があります。


"BIOSアップデートを行う前の P3B-Fマザー" に対して処置を行った状況と　今回の状況の比較についてですが、
BIOSアップデート以前のP3B-Fについては 紙に書いた記録があります。
P3B-Fマザー と AX-6BC_typeRマザーでは 合わせて３０回ほど処置を行っています。
　（PIII-SCDでは３回）。知人所有の他のＰＣでは３回行いました。
AX-6BC の場合は、最初の２５回程度は【“田中式”の実験段階】ですから、処置の内容・手順は 今日のものとは隔たりがあります。
上記の全ての作業は 「○時△分、ｘｘｘｘｘ」という形で克明にメモしながら行っています。

これら上記のデータの内　P3B-Fでの最後の処置の記録だけは ポイントを抜き出して整理し、Ｂ４用紙４ページに書き写してあります。
これは 後日 ＨＰで公開したいとも思っています。
　　※今回 スキャナの電源を切り忘れてケーブルを抜いたので　スキャナが故障していれば出来ません。
　　　あるいは　【スキャナ接続の方のSCSIカード】も故障したかも知れません。
それ以外のデータは 処置前後のレジストリは 少し保管してありますが
「○時△分、ｘｘｘｘｘ」という形での記録は　どこに保管したか あるいは廃棄したのか覚えていません。
ただ、紙に書き出した内容は 人間 なかなか忘れません。

以上の記録と記憶に基づいての報告です。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


ここからは　少し古い時期の話をします。

★【以前のＰ３Ｂ−Ｆマザーボード (即ち BIOSアップデートする前）】での田中式処置について。
　　　　　　　　　（1999年８月購入。1999年11月に最終実験。）

　　※これは ＨＰに掲載していますから少し触れるに留めます。

P3B-F のＢＩＯＳバージョンは １.００３ です。（1999年８月購入。FSBクロック＝100MHz）
Pentium-II 350MHz・PC100メモリ256MB

SCSIカード（AHA-2940UW）に１０MB転送レートのFastSCSI_HDDを接続し、この SCSI_HDDからＰＣ起動。
Ｗin98ＳＥをクリーンインストールしますと　８〜10時間程度の使用で１日２回〜５回程度は 青画面・フリーズが発生していました。
フリーズに関しては使用状況次第で 時には もっと多くなる時もありました。


　※このＰＣに P3B-F を搭載して使用する前は 全く同じマシン構成で AX-6BC_typeR を搭載して使用していました。
　　この２つのマザーボードを比較して お話します。

　　AX-6BC_typeR に対して 田中式処置を“実行する前”はヒドイ状況で、半日の間に２０回近く青画面になった事もありました。
　　AX-6BC_typeR の青画面の半分は マウスクリックした瞬間に発生したものでした。
　　フリーズのタイミングは、皆さんが体験しているのと同じ状況でした。
　　マウスは【ロジクール３ボタン】で、相性も悪かったと思います。
　　
　　AX-6BC_typeR に対して 田中式処置を実行した後は 激変しました。処置後 ３ヶ月間 使用しましたが、青画面・フリーズはゼロでした。
　　性能そのものは P3B-Fよりも少し上ですから 実に快適でした。
　　ただし、このマザーは ＦＤ起動した時に、SCSIとIDEのドライブレターが HDD起動した時と入れ替わる点については 不満でした。
　　FDD起動すると ＣドライブがＣドライブでなくなってしまうのです。
　　“ＩＤＥ接続のＨＤＤの基本パーティーション”が 強制的にＣドライブ扱いとなるのです。
　　私は　通常は“ＳＣＳＩ起動”しており、SCSI接続のＨＤＤ＝Ｃドライブですから、FDD起動をした時に困ります。
　　“Windowsを起動している時のＣドライブ”が　FDD起動をした時には Ｃドライブとして認識されません。
　　　（ウィルスを食らった仮定して　AntiVirusで復旧する事も出来ません。笑。）
　　という訳で、
　　他のマザーボードでも 処置の効能を試してみたい気持ちもあって　P3B-Fに換装しました。

−−−−−−−−−−−−−−−−−−

余談ですが、2000年６月頃に２台のＨＤＤに【表面障害】が発生しました。
　（起動ドライブ と スワップ＋Tempのドライブ）
２台とも 1996.春の購入で FAT16フォーマットであり、同じ個所にばかり書き込みが行われますから　寿命です。
ＨＤＤは２台とも新品を購入し、SCSIカードは サブＰＣの AHA_2940U2W と入れ替えました。


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


★Ｐ３Ｂ−Ｆの 'マザーボードBIOS' をアップデートした時の経緯

　【マザーBIOSアップデート ⇒ SCSI-BIOSアップデート】と進め、
　【マザー電池交換 ⇒ ＣＰＵ交換】を行った後、１度も Windowsを起動しませんでした。
　そのまま　ＨＤＤをフォーマットし、Windowsを再インストールし、インストール後　田中式処置を行いました（2002年３月）。
　この時の作業と　その後の作業が、このページの先頭から記述してある報告です。

以上。