[44395]  DOSパーティションのIPLについて質問
投稿者:くん さん   2002-12-08 22:34:15
Windows2000のインストールによって同一HDDにあるWin9xが破壊される問題?を
懸念して我が家では一応Win2000 => Win98SEという順番でインストールして、
・第1領域 Windows 2000 Pro (NTFS5)
・第2領域 Windows 98 SE(FAT32)
・第3領域 DOS6.2 + Win3.1(FAT16)
・第4領域 データ領域(FAT32)
という形態で、固定ディスク起動メニューからのマルチブートをしていたのですが、
とある時、Win2000の起動中にScanDiskらしきのをされた後、
第2、第3領域から起動できなくなってしまいました。
例のWin2000の、9x破壊問題と似たような事をやられたのかと疑っています。

症状としては固定ディスク起動メニューで領域選択の後に、
ブラックアウトしたままDOSにいきません。

機種はRa300とXv20の両方ともこうなってしまいました(^^;)
どちらもChanpon3でSCSI HDDから起動しています。
  1. くん さん   2002-12-08 22:34:32
    今更ながらOS起動までのプロセスを復習してみると、
    ・(1) : 本体のITF(BIOS)がHDDの先頭領域をブートセクタとして読込み、
        「MBR(PC9800ではこう言わないかもしれませんが)のIPL」が起動
    ・(2) : MBR内の「起動メニュープログラム」が起動 &「パーティションテーブル」を参照
    ・(3) :「パーティションの開始セクタのIPL」が起動
    ・(4) : 3のIPLが「パーティション内のファイルシステム」を参照してOSの各ファイル読込
    だと思うのですが、固定ディスク起動メニューでの領域選択が
    できている事から(1)は正常だと思われますし、

    FDDやSCSI接続のスマートメディア(2台目HDD扱い・笑)に
    システム転送して起動したDOS7.1やWin2000から
    HDDの第2領域、第3領域のファイルとも正常に読み書きできますし、
    パーティション情報も正常、という事で(2)も正常だと思うので、
    (3)の部分がひっかかっているのではないかと疑っています。
    (4)はWin9xのDOS7.1ではIO.sysですよね?IO.sys、Command.com、
    MSDOS.sysの起動ディスク(FDD)のものとByte単位のコンペアを
    行いましたが、同一でしたので書き換えられていないと思います。

    なお、第3領域のDOS6.2の方はDOS6.2のFDDからSys.exeで転送して
    復旧できたのですが、Win98SE側はSys.comでは多少違うのかダメでした。
    Win9xになってFormat.exeがFDisk.exeとに文裂した流れでしょうか?
    #DOS6.2のSys.exeを使ってSys.exe Win98SEのFDD HDD第2領域(Win98SE)
    #とかも試そうと思ったのですがこれはできませんでした(笑)

    よって、多分(3)の段階でHDD第2領域の開始セクタのIPLが壊されてしまっていて
    IO.sysなどを呼ぶ所までいけずにブラックアウトしているように思えました。
    原因がこれと断定できるわけではないのですが一応試したいので、MBRのIPLではなく、
    特定のパーティションにWin9x(DOS7.1)用IPLを書き込む方法はないでしょうか?
    #FDisk.exe /MBRなどは確かMBRのIPL&固定ディスク起動メニューだけでしたよね?
    #一応やってみましたがまったく変化無しでした(^^;)

    さすがにそんな1KBにも満たないIPLデータの変更のために、
    8GBのパーティションをFormat.exe /s するのもアレなので…(^^;)

    ご意見お待ちしております。
  2. くん さん   2002-12-08 23:44:34
    なお、まりもさんのRWMBRを使わせていただいて、固定ディスク起動メニューを含む
    8KBのMBRデータをファイルへ書き出して、一応バイナリエディタでみてみたところ、
    パーティション情報と思われる部分(0200h〜最大だと16領域で03FFhまで?)のデータの、

    第2領域の開始IPLのシリンダ数と思われる部分(0226〜7h、022A〜BhのそれぞれWord型)の値は、
    DOS6.2のFormat.exeのマップ表示で見たシリンダ数と同じ値であり、
    また、第3パーティションの開始IPLのシリンダ数と思われる部分(0246〜7h、024A〜Bh)も
    第2領域の最終シリンダ数と思われる部分(022E〜022Fh)より1だけ大きい数値だったので
    パーティションの開始IPLの参照シリンダ位置も問題ないようでした。
    やはりその参照先のDOS用IPLが破壊されているのか…(^^;)
  3. まりも さん   2002-12-09 00:35:30
    Win98(DOS 7.1)の起動FDで立ち上げて、SYS 対象ドライブ名: を走らせれば、パーティションの開始セクタのIPL(最近ではPBR:パーティションブートレコードと呼ぶことが多くなった)が修復されるはずですが。起動DOSバージョン、対応SYSプログラムのバージョン、転送先領域のDOSバージョン、これらが一致していないと、PBRは正しく修復されません。
  4. くん さん   2002-12-09 16:28:53
    まりもさんお返事ありがとうございます。Win98SE(DOS 7.1)の起動FDDで立ち上げて、
    Win98SE付属のSysコマンドにてSys 対象ドライブ名 : はやったのですが、
    症状は変わりませんでした。(やはり領域選択後、DOSにいかずブラックアウト)

    同様に破壊されたDOS6.2領域の方はDOS6.2付属のSys.exeでは修復できたので、
    DOSのSys.exeとWin98SEのSys.comは実は少し挙動が違うのでは?と思ったのですが、
    本来PBRはWin98SEのSys.comでも書き換えてもらえるものだとすると、
    PBRがおかしいという読み自体が外れているっぽいですね(汗)
    Unixのdd if=/dev/hda of=〜 bs=512 count=〜みたいに、デバイスの任意のセクタを
    ファイル化するソフトがあれば、領域の先頭シリンダ数から計算してPBRらしき
    セクタのインデックスを求めてそこを書き出して正常なDOS領域のPBRのIPLと
    比較できそうですし、ちょっとそのようなDOS用ソフトをさがしてみます(^^;)
  5. まりも さん   2002-12-09 19:07:17
    ヘンですねぇ。もしかして、起動FDによる起動ではだめで、HDDのWin98領域から起動して、そこでSYSコマンドを走らせて、壊れた別領域に転送でないとだめなのかも?。ちょっと試してみますか。

    ところでPBRをファイル化するソフトですが、拙作 drvcpy /b  ドライブ名   ファイル名でも出来ます。
  6. いーとん さん   2002-12-09 19:13:31
    以前同じ症状が出ましたが、復帰させるにはそのパーティションを再フォーマットする以外有りませんでした。
    ☆Win2000 でファイルを全救出した後フォーマットし、ファイルを全て書き戻しました。
     ゴミ箱の扱いが Win98 と Win2000 で同じでは無い様なので Win98 起動後に何か言われた記憶が有りますが...
  7. まりも さん   2002-12-10 07:46:58
    ええと、5.で書いたとおりみたいです。なんと、Windows98のSYSコマンドは、FDから起動したときは、ハードディスクの領域のブートセクタのコードをきちんと書き換えません。ハードディスクからの起動のときには書き換えます(ということは復旧にはWindows98の入った別のハードディスクか領域が必要)。いままで気が付かず、SYSコマンドを使えばブートセクタコードも含めてシステム転送できるものと信じていました(汗。
  8. バイザー さん   2002-12-10 11:26:39
    ゴミかもしれませんが一カ所気になったので・・・

    >どちらもChanpon3でSCSI HDDから起動しています。

    くんさんと同じ症状が我が家のRa20/N12+CHANPON3でも発生していました。
    同じパーテーション・OS構造でH/AがSC-UPCI系ですとか、IOI-A100U2Wですと発生しないの
    ですが、CHANPON3だと起きてしまいました。
    さらにFDでDOS7.1の起動すら出来ず(これは内蔵セカンダリIDEにCD-ROMドライブを接続
    することで回避)ずいぶんと難儀した覚えがあります・・・
  9. いーとん さん   2002-12-10 15:32:08
    > ハードディスクからの起動のときには書き換えます
    と言う事は、スリープ領域でFD起動と同じ環境を確保しておけば良いのですかねぇ。
    ☆スリープ領域さえ起動できなくなるなら別個体のHDDを繋がずに確保するしかないが...

    > H/AがSC-UPCI系ですとか、IOI-A100U2Wですと発生しないのですが、CHANPON3だと起きてしまいました。
    うちでは SC-UPCI系で発生(というかSC-UPCI系しか使ってないし)してますので SCSI H/A は無関係なんでしょうね。
  10. まりも さん   2002-12-11 00:21:16
    「Win98の起動ディスクで立ち上げてSYSコマンド打って…」などというありきたりの説明が間違っていたことが分かったというのは、結構重大ニュースなのでは(^^;)。ちなみにHDの領域からWin98を起動しているときに、フロッピードライブに対する sysコマンド適用でも、ブートレコード(FDのIPL)は書かれませんでした。この場合もformatをしないとだめなようです。

    HD上にWin98の起動可能な領域が一つしかなく、その領域のブートレコードが今回のように潰れた場合、全部バックアップしてformatしなおして戻すしか方法がないというのもちょっと困ったモノですね。sysコマンドかformatコマンド内にあると思われるブートレコードのIPLコードを吸い出して所定位置に書き込むプログラムが必要になりそうですねぇ…。書き込むだけならdrvcpy /b で行けますんで、吸い出しを考えないと。
  11. こういち@BD5B-RS さん   2002-12-11 02:25:19
    なるほどぉ、ということはこれ↓もそれことが関係していたのかもしれないですねぇ。
    http://www.cham-reo.com/logsearch/archive/stage_3/pc-98/sled20388.html
  12. くん さん   2002-12-11 04:29:44
    >い〜とんさん
    実はRa300の方はうちも同様にWin2000から丸バックアップ、
    再Format /S、その後またWin2000で丸コピーで修復したのですが、
    毎回やるにはあまりにナンセンスだと思えてきたので、Xv20の方は
    せめて理論的な解決方法を試みてみたいなと思いました(^^;)

    >まりも さん
    なんとWin98のSysコマンドはそのような仕様でしたか〜!
    相変わらずのすごい推察力に敬服いたします(^^;)

    今回、みなさんのレスを拝見した後、とりあえずFDDからのSysではなく、
    Win98SEのDOS7.1がいれてあるMCR-S + スマートメディア32MB
    (SCSI ID5で、固定ディスク起動メニューではSCSI固定ディスク #6として認識)
    からDOS7.1を起動し、Sys d: a:(この場合a:がPBRが壊れていると思われる第2領域です)
    をやったのですが、結果変わらずブラックアウト、でした。
     このSCSIカードリーダのSmart MediaはC/H/Sも内蔵HDDのような8*128ではなく、
    8*32で扱われていたようですし、表記はHDDでもFDD同様特殊扱いか?と思い、

     こんどはデータ用領域であった第4領域(FAT32)を、一時的にFDiskでブート可にして
    Win98SEのFDDからSysコマンドにて転送し生DOSが起動できるようにして、
    そちらで起動してからSysコマンドをHDDの第2領域へやったのですがこれもまたダメでした。
    これは完全に同一HDDの別領域から別領域へのHDD同士のSys転送のはずなので、
    もしかしたらこの問題はPBRの破壊という読み自体が違っている可能性もでてきました(汗)

     ただここで、うぬ?と思ったのは、本来データドライブだって第4領域に対して、
    フォーマットせずにそのままSysコマンドしただけでブートレコードがかかれた事です。
    #もしかして、今までに何らかのIPLがある領域の場合は上書きされない、というだけで、
    #まだIPLがない領域の場合はWin98SEのSysコマンドでもブートレコードが転送される??

     とまぁ、Win98SEのSysコマンドの挙動についての事もそうですが、
    とりあえず第2領域のブートしない原因について調べるために同容量HDDを用意し、
    まりもさんのHDDup98を利用させていただいて丸コピーしてた後に、
    片方の第二領域をFormat /Sし、起動しない方とFormat /SでDOSの起動だけは
    できるようになった方のPBRをそれぞれDrvCpy /Bにて書き出してから
    両方のファイルをバイナリ比較してみようかと思っています。
    #もしそれで完全一致していたらPBRのブートレコードが原因ではない??

    しかし、もしまりもさんが
    >sysコマンドかformatコマンド内にあると思われるブートレコードの
    >IPLコードを吸い出して所定位置に書き込むプログラム
    を作って下さるようであれば、
    今回の問題もブートレコードのせいかどうか判別できますし、
    Sys.comの変な仕様も問題ではなくなりますね。

    せめて問題の切り分け位はもっと自分でもできるようになりたいのですが、
    いつもまりもさんにはお世話になる一方で申し訳ありません…m(__)m

    いーとんさん、バイザーさん、こういちさんも貴重なご意見をどうもありがとうございます。
  13. まりも さん   2002-12-11 21:43:59
    >両方のファイルをバイナリ比較してみようかと思っています。
    ぜひそうしてみて下さい。ただし注意する点があります。このファイルの先頭から5Ahバイト程度(3Chかも)のところまでは、別のドライブから吸い上げたもの同士は一致しません。そこはIPLプログラムではなく、FATファイルシステムのスペックが書かれているところのため、容量やパーティション位置が一致していない限り、データは異なっています。
  14. くん さん   2002-12-12 00:02:09
    >FATファイルシステムのスペックが書かれているところのため、容量や
    >パーティション位置が一致していない限り、データは異なっています。
    との事で、容量もパーティション位置も完全にあわせてからやってみようと思います。
    Xv20はChanpon3にMAH3182MPを使っており、予備に全く同じMAH3182MPがもう一台あるので、
    現在HDDup98中です☆この後片方の第2領域だけをFormat /SしてからPBRを比較してみます(^^;)
  15. くん さん   2002-12-12 05:09:34
    HDDup98にてもとのHDDを完全に複写後、
    片方のHDDの第2領域のみをFormat /Sした所、ちゃんと起動できるようになりました。
    #あくまで第2領域にFormat /Sしただけで、各領域のサイズなどは元のHDDと完全に同じです。
    #2つのHDD(どちらもMAH3182MP)はシリンダ数まで同じである事も確認してあります。
    #異なるのはFormatによるデータ部分で、ブートセクタは異ならないと思います。

    Format/Sした方が起動できる事を確認した所で、DrvCpy /BにてPBRを書き出し、
    以前の起動しない方のPBRと比較してみた結果が以下です。
    16384Byte中13Byteが異なる結果になりました。
    #ディスクの空き容量なども領域の先頭に記載されているのだとしたら、
    #その辺かな、と思うのですが、とりあえず個所がややとんでいるので、
    #微妙に違うものであるのではないかと思いました。

    ・第1ファイル : HDD第2領域(OS選択後、ブラックアウトして起動しない状態)のPBR
    ・第2ファイル : 上記HDDをHDDup98にて複写後、第2領域のみFormat /Sで起動可能になったPBR

    □ ファイルサイズ : 一致(16384Byte) => 全データを比較
    ■ 比較結果    : 不一致バイト数 = 13Byte / 16384Byte
    ---------------------------------------------------------
    Address  0 1 2 3 4 5 6 7 8 9 A B C D E F
    ---------------------------------------------------------
    00000040 ・・ ・・ ・・ ・・ DC 19 ・6 29 ・・ ・・ ・・ ・・ ・・ ・・ ・・ ・・
    00000040 ・・ ・・ ・・ ・・ 09 08 ・C 15 ・・ ・・ ・・ ・・ ・・ ・・ ・・ ・・

    000003E0 ・・ ・・ ・・ ・・ ・・ ・・ ・・ ・・ 0A 2D 03 ・・ 15 26 ・・ ・・
    000003E0 ・・ ・・ ・・ ・・ ・・ ・・ ・・ ・・ A1 09 1C ・・ 53 00 ・・ ・・

    00000C40 ・・ ・・ ・・ DC 19 ・6 29 ・・ ・・ ・・ ・・ ・・ ・・ ・・ ・・ ・・
    00000C40 ・・ ・・ ・・ 09 08 ・C 15 ・・ ・・ ・・ ・・ ・・ ・・ ・・ ・・ ・・

    ただ、ここで書き出した正常な方のPBRを、
    こんどは異常な方のHDDの第2領域へDrvCpy /Bを用いて逆に
    書き込んでみたのですが、なんと起動しませんでした。

    念のためPBRだけではなく、改めてもう一度MBRも疑ってみて、
    起動しない方と起動する方のHDDのMBRをそれぞれRMBRで
    書き出してバイナリ比較したのですが、こちらは完全一致でした。

    つまり現状では
    ・ディスク自体の型番、シリンダ数においても(つまり容量が)全く同一
    ・MBRが完全に同一
    ・領域分割(開始・終了のシリンダ数)も全く同一
    ・その状態で正常な方のPBRを書き戻しても変化無し
    ・IO.sys、MSDOS.sys、Command.comの破損でもない
    といった感じのようで、後はどこを疑えるでしょうか(汗)

    でもやはりFormat /Sをする事で起動ができるようになっているのも
    やはり事実なわけで、どこかが絶対書き換わっているはずなのですが…(--;)
  16. まりも さん   2002-12-12 14:03:47
    Win9xの場合、先頭00h..3Dhまでがファイルシステム記述部です。ここは一致ですね。3Ehから1FFhはIPLコードですが、44hからの4バイトに不一致がありますので、やはりPBRに異常な変更が加えられたということです
  17. くん さん   2002-12-12 14:56:35
    まりもさんお返事ありがとうございます。
    DrvCpy /BにてPBRの吸出しを行ったら16384Byteのファイルができました。
    Nr300内蔵IDE + EX-IDE32GでChanpon1互換パラメータにしたIC25N040ATCS04と
    Chanpon3接続のMAH3182MPのどちらのWin98SE(FAT32)でも16384Byteになったので、
    上で1KB未満に満たない領域?などと書いてしまい、まずった?、と
    思っていたのですが、やはり本来は1セクタ(512Byte)のはずですか。
     という事は正常な方のPBRを書き戻したのはやはりFATの情報の一部なども含めて
    IPLコード以外の部分も置き換えられてしまったから、という感じでしょうか。
    帰宅したら今度は異常な方のPBRの44h〜のみをバイナリエディタで正常な方と
    同じ値にしてからDrvCpy /Bにて書き戻してみようかと思います。
  18. まりも さん   2002-12-12 19:00:26
    FAT32の場合は、PBRのセクタを含めた「予約セクタ」というのが32セクタ=16KBあります(FAT16だとPBRの1セクタのみ)。
  19. くん さん   2002-12-12 21:42:15
    なるほど〜、FAT32の場合はそうなのですね、勉強になります(^^;)
    ところで、異常な方のPBRの0044hから4バイトと0C44hから4バイトのみを
    バイナリエディタにて正常な方のPBRと同じ値にかきかえてから
    DrvCpy /Bにて書き戻してみたのですが、変わらずブラックアウトでした(苦笑)
    う〜〜ん………
  20. まりも さん   2002-12-12 22:18:28
    そうですか。ではこの問題は formatしか修復方法はないということで(笑)。
  21. くん さん   2002-12-13 17:50:26
    http://triaez.kaisei.org/~s-zouda/pc/fat32.html
    の記事をみるに、0043hからの4バイトは、フォーマット時にランダムに割り当てられる
    シリアルナンバーだったようで異なっていてむしろ当たり前だったみたいです(^^;)
    更に、03Exhの相違点も空きクラスタ容量と最終書き込みクラスタ番号らしいので、
    Format直後の空き容量だらけのドライブのPBRとは異なって当然でした(^^;)
    つまり、結果としてブート周りのIPLコードは完全一致していたというみたいですので
    このDOS7.1が起動しない問題はMBR、PBRの問題ではないといった結果っぽいです(汗)
    #最初の0000hからの3バイトがOS をロードするためのジャンプ命令らしいですが、
    #起動しない方も起動する方も変わらず、EB 5A 90ですし、ジャンプ先は5A 90で一致…
    #さすがにその先を追いかける技量・元気ともに今の自分には足りません(^^;)

    結局現状ではFormat /S後にWin2000側から丸コピーで復旧、で妥協するしかなさそうですね。
    また何か思いついたらあがいてみようとは思いますが、とりあえず今は一度諦めます(^^;)
    まりもさんいつもながらどうもありがとうございました。
  22. まりも さん   2002-12-13 20:36:23
    FAT32なのでドライブパラメータブロックの内容がFAT16と違うことを、書いておくの忘れました(ぉぃ。ちなみに C44hのほうは、200hで割るとセクタ6にあたり、ここはPBRの予備ということになっています。従ってセクタ0同一内容のはずです。
    MBR,PBR以外というとちょっと分かりません。
  23. higashi さん   2002-12-14 16:37:48
    すこし書き込むタイミングが少し遅かったですかね
    私も、同様な現象を5回ほど経験しました
    使用しているPCはXt16ですがパーティションの
    分割方法はほぼ同じです(NTFS-FAT32-FAT16)
    ファイルが消えている分けではありません
    FDから起動すると問題なくアクセスできます。
    CHKDSKコマンドやSACNDISKコマンドを使用しても異常なし
    SYSコマンドを使ってもだめ
    とりあえず、ファイルを全て退避しFORMAT /Sしてから
    ファイルを元に戻してやると問題なく起動できるようになりました
    これを4回ほど経験し、さすがに5回目が発生したとき
    だめ元で、Win98SEをインストールしている
    FATを見てみました、特に問題はなさそうだったのですが
    やたら、ファイルの削除後が有りました(E5で始まるやつ)
    追っていくと、FATの残り領域?が全て削除あとで
    埋め尽くされていました
    TOOLをつかって、削除あと(E5で始まるやつ)を全て削除(0にした)すると
    起動することできました
    どうも、FATが削除あとで埋め尽くされると起動できなくなる様です
  24. くん さん   2002-12-14 19:28:00
    Higashiさん情報どうもありがとうございます!
    まさかPBRではなくその後のFAT自体にあやしい部分があったとは…すごいです。
    ちょうどPBRの0Ehに記載してある予約セクタ数(20h)分進んだセクタから、
    ディレクトリエントリの手前までがFAT部分ですよね?
    明日からちょっと3日ほど留守にしてしまうのですが、帰宅後すぐに試させていただきたいと思います!
    FAT32に対応した、任意のセクタ書出/読込できるプログラムって何がおすすめでしょうか?
    本当に情報どうもありがとうございます☆
  25. まりも さん   2002-12-14 20:02:18
    >higashi さん
    おおっ、これは貴重な情報ですね、というか普通そんな所まで気がつかないです(^^;)。

    E5hで埋まっている部分があること自体は問題ではなく、ルートディレクトリ領域の終わりまでのどこかに00hで始まる32バイト行があればかまわないことになっています。しかし最終まで E5hで埋まっているのは反則ということになります。Windows98が、ディレクトリの終わりを00hで検出していたりすると、永久に見つからないということが起こりそうです。もちろんディレクトリの最大数を、PBRにある情報から探る(FAT16)か、FAT32ならFATから探せばよくて、それ以上検索しなければよいだけなのですが。Windows98ではそのへん、手抜きをしているのかもしれませんね(^^;)。

    察するところ、ルートディレクトリの最後をディレクトリ自身のデータから調べる必要がとくに出てくるのはFAT32の場合なので、おそらくWin98の起動領域がFAT32の場合にこの問題が起こりうるのではないかと思います。FAT16のWindows98の領域では問題が見つからないのではないでしょうか?(少なくとも私の所はオールFAT16で、この問題にあったことがありません)。

    >くん さん
    任意番地ダンププログラムはまあ探せば出てくるでしょうけど、drvcpy で バックアップファイル作成モードを開始してしばらくして[ESC]キーで中断させる手があります。先頭(PBR)からそこまでのデータは連続で取れます。

    >予約セクタ数(20h)分進んだセクタから、ディレクトリエントリの手前までがFAT部分
    その通りです。ただしFAT32の場合はルートディレクトリ領域が存在しません。一つのサブディレクトリという形をとります。しかし通常はクラスタ番地2にその入り口がありますので、この場合はFATのすぐ続きに位置します。
  26. くん さん   2002-12-14 21:54:10
    まりもさんありがとうございます。
    DrvCpyのバックアップをESC中断という形で吸い出したデータを
    今眺めていたのですが、どうもE5hで埋まっているような所がみあたりません。
    えっと、私のこのHDDの第2領域は約7192MBの領域でして、
    改めてPBRの先頭のBPB部分から得た情報を整理してみると、

    (1) 0020h[全セクタ数]      : 00C0E000h(14729216)
    (2) 000Eh[FATの開始セクタ番号] : 20h(32)
    (3) 0024h[1FATあたりのセクタ数] : 2238h(14370)
    (4) 0010h[FAT自体の数]     : 02h(2)
    //------------------------------------------------
    となっており、
    (1)より領域の総容量は、 14729216 * 512 = 7,541,358,592 Byte (7192MB)
    FATの開始位置は (2)より、32    * 512 =    16,384 Byte (004000h)
    FAT1つの大きさは(3)より、14370  * 512 =   7,357,440 Byte (704400h)
    FATは(4)より2つあるので、7357440 * 2  =  147,148,880 Byte (E08800h)
    つまり、
    1つ目のFATは 004000h 〜 7083FFh まで、
    2つ目のFATは 708400h 〜 E0C7FFh までという事になり、
    E0C800からがディレクトリエントリ、という
    認識をしているのですが間違っているのでしょうか?(汗)

    一応2つのFATの確認という事で、004000h〜の値と708400h〜の値を
    少し見比べてみたのですが、ちゃんと同じものが入っているようでしたし、
    E0C800からピッタリIO.sys、MSDOS.sysといった文字列がみえ始めるようになるので、
    FAT領域の認識はあっていると思うのですが、見方が悪いのでしょうか?(汗)
    FAT エントリにクラスタ番号が普通に記述されているようにみえるのですが…う〜ん
  27. まりも さん   2002-12-14 22:11:13
    E5hで「埋まる」というのではなくて、32バイトを単位とする1ファイルぶんのディレクトリ記述の先頭がE5hという意味です。E5hで潰すことで「削除済み」を意味することになっています。で、IO.SYSなどが入っているところはまさにルートディレクトリです。その後方のセクタのデータはどうなっているでしょうか。
  28. まりも さん   2002-12-14 22:17:36
    あ、もしかしてFAT領域の終わり付近を見ていますか?。
    higashi さんが書かれているのは、「FAT領域」そのものではなく、「ディレクトリ領域」のほうと思われます (広義に、両方併せてFATと言うこともあります)
  29. くん さん   2002-12-14 23:24:46
    >あ、もしかしてFAT領域の終わり付近を見ていますか?
    思いっきりみていました、すみません(汗)
    その直後のルートディレクトリエントリをみていると、
    確かにAutoExec.batなどに混じって*.tmpファイルの削除済みの残骸があり、
    20hごとに先頭がE5hになっているファイル群20個位はありました。(E0D7E0hの所まで)

    ……ここより上はE5で始まる〜.tmp系の残骸が結構続いてました。
    E0D7C0h E5 53 49 36 34 30 33 32 54 4D 50 10 10 53 B4 2E
    E0D7D0h 87 2D 87 2D 00 00 B5 2E 87 2D 72 4D 00 10 00 00
    E0D7E0h E5 53 49 36 34 30 34 34 54 4D 50 10 10 45 B9 2E
    E0D7F0h 87 2D 87 2D 00 00 BA 2E 87 2D 72 4D 00 10 00 00
    E0D800h 4D 5A 44 00 BA 00 00 00 49 04 01 00 FF FF 00 00
    E0D810h 00 00 00 00 00 01 00 00 1E 00 00 00 01 00 00 00
    E0D820h 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    E0D830h 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    E0D840h 32 33 32 33 4A 50 4E 51 00 A4 03 4E 53 43 4F 00
    E0D850h 03 06 00 16 00 1A 00 01 04 FF FF 48 03 02 00 56
    ……ここからはもうCommand.comの中身みたいなのがありました。

    MSDOS.sys等の上のエントリを見るに、FATでは先頭から11バイトをMS-DOS8.3ファイル名用に
    確保してあって、使わなかった文字の部分は20h(半角スペース?)で埋めてあるようですが、
    E0D800hは4D 5A 44(文字列にして"MZD")というファイル名は記憶にないですし、
    4D 5A 44の後も 00 BA 00 00 00…と20ではなくちょっと様子がおかしいので、
    ここがルートディレクトリの最後かな?と思ったのですが、間違っているでしょうか(汗)
    ただその下のE0D820hは確かに00で始まる行なので、
    Windows98が、ディレクトリの終わりをここで検出してくれるような気もするのですが(^^;)

    初心者の手探りで、長いスレッドになりご迷惑おかけしてすみませんm(__)m
  30. まりも さん   2002-12-14 23:33:51
    えぇと、その"MZ"(E0D800)はもう実行プログラム、つまりデータ領域にかかっていると思われます。ここはセクタ境界ですよね。ということは、その直前までE5先頭とする32byteブロックで埋められているわけです。

    higashiさんのお書きのことを実証していますね。

    私も気になってやってみた(Windows2000の自動chkdskやscandisk)んですが、どうもディレクトリ領域(複数のセクタからなる)のセクタ境界までをE5ブロックで埋めるようです。したがって、ディレクトリ領域の最後のセクタまで使わない状態、つまりルートディレクトリのファイルが多くない状態では、この問題は顕在化しない可能性があるということになりそうです。

    くんさんは、ルートディレクトリに一時的にしろかなりファイルを置いていたということはありませんか?。
  31. くん さん   2002-12-15 00:30:01
    そうでした!MZは実行形式のヘッダ(IMAGE_DOS_HEADER)でしたね、
    しかもアドレス的にみても確かにセクタの境界(^^;)
    こんな事にも気づかないとは…ぐふ。頭が弱っているようですみませんです(汗)

    とすると、この場合 E0D7E0h までのE5で始まる*.tmpの削除跡を
    32Byte単位で適当に0フィルしてからのリストアを試してみようと思います。
    (とはいえ、先頭の削除フラグらしきE5だけの方がいいのでしょうか?)

     自分としてはルートディレクトリに直接*.tmp系のファイルを
    おいた記憶はないのですが、*.tmpという事もあり、なんらかのソフトやパッチ等に
    一時的にそのようなファイルが生成された事はあったのかもしれません(^^;)

    #上記実験及び報告は数日後になります、スレッドが流れてしまっていたら申し訳ありません。
    #まりも様、Higashi様他意見をくださったみなさま本当にどうもありがとうございます(^^)
    # しかしながら今回はWin98SEのSys.com、Win2000のScanDiskの挙動といい、
    #なかなか自分の想像を越えていた事実で、トラブルとはいえ楽しくもありました(笑)
  32. Higashi さん   2002-12-15 12:06:27
    >まりも さん
    フォロー有り難う御座います。

    >くん さん
    FATを編集する時、
    失礼、ルートディレクトリを編集するときは
    は注意してください。
    編集方法を誤るとファイルが表示されなくなります。
    ファイルとファイルの間にある削除済みファイルは
    消さないで下さい。
    多分、それ以降のファイルが表示されなくなります。
  33. K.Takata さん   2002-12-15 13:50:17
    > FAT32に対応した、任意のセクタ書出/読込できるプログラムって何がおすすめでしょうか?
    お薦めできるほどのものではありませんが・・・。
    http://member.nifty.ne.jp/k-takata/mysoft/ddtx.html
    HDD BIOS を使って読み書きしているので、BIOS が認識しているドライブであれば、FAT32 だろうが NTFS だろうが未フォーマット領域だろうがお構いなしに読み書きできます。
  34. まりも さん   2002-12-15 14:42:34
    あぁそのソフトだとアドレス指定単位がHDDのCHSまたはLBAであって、DOSの論理セクタ番号(セクタ番地はPBR基準)でないので、アドレス変換を自分でやらないといけない点がとても面倒かと(^^;)。
  35. K.Takata さん   2002-12-15 17:09:19
    そこがお薦めできない理由の1つであります。(^^;
  36. まりも さん   2002-12-15 20:10:39
    FAT16の場合ですがテストしてみました。
    ルートディレクトリ領域の終わりまでE5hブロックで埋めてみましたが、Windows98は起動できました(^^;)。00hで始まるブロックがなくとも構わないようです。というより、普通にファイル削除をしても、E5hになるだけで、最後に00hブロックが置かれるということはないようです。

    となるとFAT32のときが問題なのでしょう。
  37. くん さん   2002-12-17 22:02:01
    伊豆から戻ってきました。早速K.TakataさんのDDTXを使わせていただき、
    ルートディレクトリエントリの最後のエントリ(32Byte = 2行)の先頭の
    E5hを00hにするだけで、我が家のWin98SEも無事復活いたしました!
    おかげさまでシリンダ/セクタの手計算も慣れてきましたし(笑)もしまたWin2000を
    使っていて再発してもDDTXを入れたDOS起動FDD1枚ですぐに修復できそうです☆

    結局はまりもさんの読みどおり、Windows98の検出ルーチンがFAT32の時のみ、
    ルートディレクトリ領域の終わりまで00hが検出されないとブラックアウトして
    起動できずに終わる作りであり、かつPC9821-Win2000のScanDisk周りが
    最後のブロックまで削除済み(E5h)にしてしまう可能性があり、マルチブート
    していると双方の仕様によりたまたま起こりうる問題であった訳ですね(^^;)

    修復方法をみいだし、教えてくださったHigashi様、
    いつもながら的を得た推測、各種ツールの公開、そして色々な事を教えてくださったまりも様、
    DDTXを公開してくださったK.Takata様、ならびにレスをくださった皆様。
    本当にどうもありがとうございました、解決できた上に勉強できました(^-^)
  38. くん さん   2002-12-18 04:17:21
    なお、最後に追加ですが、初症はWin2000のScanDiskだけではないようです。
    Win2000のデフラグもWin98SE領域に対してやってみたら早速再発しました(^^;)