jaclaz

At first sight, you have both a ControlSet003 and a ControlSet004 which is not "standard", normally there are only ControSet001 and ControlSet002, I have seen Windows 2000 installs with several (up to 20 or so) ControlSets, but it is a sign of previous corruption of this (or that) ControlSet. The CurrentControlSet is one among the ControlSetxxx's depending on the value of the HKEY_LOCAL_MACHINE\SYSTEM\SelectSelect key, in theory (and AFAIK) a non-selected ControlSet should not normally be modified, yet the Nirsoft image you shared show that both #003 and #004 have changes. Cannot say if it is normal, but that site you uploaded files to attempts to make me download an executable, no good, only retrying I can get the actual files. The Regshot file "No arranca y ultimo winrescue para compartir.txt" has changes in ControlSet013! No idea as what could be the root cause, let alone about possible way to fix it for good, unfortunately. jaclaz

AFAIK transfer via Bluetooth is complicated and Bluetooth in my experience is unreliable (difficulties in pairing/dropped connections/etc.), there are built-in tools in both windows XP and Android (this may depend on the Android version and/or smartphone brand) and apps on the GooglePlay store, and if I recall correctly the XP built-in software allows one file at the time only There is a software house that makes both a PC-side program (XP compatible): http://www.medieval.it/blueftp-pc/menu-id-70.html and an Android app: http://www.medieval.it/blueftp-android/menu-id-68.html jaclaz P.S.: @Andalu Here is an article on transferring files from PC to ST via floppy disk: https://www.jamesfmackenzie.com/2016/01/30/use-floppy-disk-to-transfer-files-from-pc-to-st/ and here is one on connectiing a floppy disk drive to smartphone: https://liliputing.com/you-can-use-a-floppy-disk-drive-with-an-android-phone-if-you-really-want-to/ Unfortunately floppy disks are not easy to find anymore.

As a windows XP FTP client I can suggest (good ol') LeechFTP (discontinued/not updated since many years, but simple and working): https://en.wikipedia.org/wiki/LeechFTP https://www.leechftp.de/index.html don't worry, the program is in English by default, and it should work even on 9x/Me and NT/2K) If you want a different approach (mounting the FTP server as drive) I can recommend FTPuse: https://www.ferrobackup.com/map-ftp-as-disk.html jaclaz

did your CAPS LOCK key get stuck? jaclaz

SInce you are multibooting you could attempt an old-school defrag, i.e. copying everything to a folder on another volume, delete the contents of the old volume and then copying the data back, this way all files will be contiguous. Still, having a dd-like copy of the volume would be advisable. As said I find it queer that you are having this behaviour on two different computers (that both have filesystem or disk issues at the same time and that both create the same issues seems to me very improbable). Maybe you could compare the two Registries (the backup one that once restored allows to boot against the one that fails to boot) I think Regshot works also on 2000, the Nirsoft RegistryChangesView officially supports only starting from XP. Another attempt could be to try using ERUNT (and the NTREGOPT) to compact the Registry. BUt right now these are just shots in the dark, I have no idea what the actual issue could be. jaclaz

That disk has been partitioned or "touched" at some time on a later than XP System, the first (NTFS) partition starting at 0/32/33 (i.e. LBA 2048) is typical of a Vista or later system, on the other hand, somehow a partition starting at 0/1/1 (i.e. LBA 63) was created, spanning all disk, and by using the XP disk manager (there is a known bug) the Extended partition has been "normalized" to the XP standard, breaking the chain of EPBR's, the Extended partition starts on a cylinder boundary (3917/0/1) which is a sign that the original partitioning (at least the creation of the Extended) was made on a XP or earlier system, or anyway respecting cylinder boundaries. It is very possible that originally the disk had a single NTFS volume spanning the whole disk (starting at 0/0/1 and 97676802 in size) and that later it was re-partitoned creating the first Primary partition and the Extended one, and the logical volumes inside the latter. If you look at the 6th (the one before last) screenshot, you have a list of all found partitions/volumes (all marked as D - deleted). Of these, some are false positives, namely the first one (starting at 0/1/1 and spanning all disk) and the FAT12 one are almost surely artifacts. The issue is understanding which of the other ones are fine, and which should be fixed. The first "real" partition (the primary NTFS one, starting 0/32/33) might be either correct OR it could derive from the use of some other software (an XP one would start 0/1/1). Then most probably the Extended partition data is valid, but (due to disk manager messing with sectors before offsets) all volumes in it are now incorrect/wrong. From what I can see - and as you confirmed by the analysis of the (unnamed) data recovery software - the data should still all be there and the MBR and chain of EPBR should be all recoverable, but there is the need of some manual analysis and fixes. Although Testdisk -as said - is an exceptionally good software, it automagically detects partition(s) or volumes through an analysis searching/carving and provides results that include false positives but, more than that it doesn't specifies from where the data it retrieves comes from (bootsector, $Boot, $BootMirr, EPBRs, etc.) so it is not easy to separate the wheat from the chaff. A good thing would be if you could recall as much as you can of what happened to this disk, how many volumes there were, which file system they used, their size (approximate), etc. My Personal advice would be: 1) make first thing a forensic sound or dd-like image of the whole disk/physicaldrive ( you will need a clean disk, that since the failed disk is 500 GB will need to be a 750 GB or 1TB one) 2) no, really, you NEED to have this image, it is the only fail (or fool) safe provision you can make 3) run DMDE on this disk and see what it finds (you can use DMDE also to make the image) DMDE is not an automated tool and needs some understanding of the mechanisms of partition/filesystems, but with some support it can be used by anyone: https://dmde.com/ having a view of the TEBCFf indicators: https://dmde.com/manual/partitions.html would be important to understand what needs to be corrected or recreated. jaclaz

@Dietmar So, putting together all the bits of info together, the "hive not found" is probably connected to the "overall fragmentation" of the whole filesystem, I imagine that there is somehow a "borked" implementation of NTFS reading routines with a cap (let's say a limited in size cache) to number of file fragments the can be counted, if a number of files are read before "reaching" the \system32\config\system AND if they are too fragmented THEN the loader fails. This would also make sense if "plain" install (from original CD) works and "custom" install (like the one via "Ramsey integrator") doesn't, as - likely - the overall filesystem, and particularly the \system32\ contents will likely be more "compact" in the former. Maybe just copying out the system32 and copying it back in (without defragging the system32less volume) would then be enough to allow booting. @Andalu Most probably, *somehow* a reference to firadisk.sys remains after uninstall/removal (whether it remains in one of the Registry backing files or *somewhere else* would be interesting to know). Could it be something related to CurrentControlSet? Maybe ControlSet001 and ControlSet002 differ (related to firadisk.sys) and NTLDR gets the "right" one while freeldr.sys gets the "other" one. Or maybe for some reasons it remains in some "special drivers needed for boot" list (only wild guesses, mind you). jaclaz

This seems "normal" to me, you deleted the file but freeldr still finds an entry for it in the Registry, but since the actual booting (from disk) does not need the firadisk driver to be loaded, you have just a warning message and booting goes on normally. jaclaz

@dietmar When you copy back the system32 folder you are effectively (in theory) rewriting the whole thing sequentially, so it is another way to defrag those files (in good ol' NT4.00 times we didn't have defrag - let alone contig or wincontig - so our Poor Man's Defrag was just to copy the whole volume contents to another one and then copy it back to the original after having deleted the original files). So, in two steps (running defrag on the "system32less" volume and then copying back the system32 you are doing a sort of very thorough defrag (at least for contents of system32). You could try doing the same (copy out/defrag/copy back in) but copying out - instead of the whole system32 folder - only the system32\config one. The placements of the two files (the one in 6 segments and the contiguous one) in extents are both within "usual" or "normal" limits, so it cannot be that the problem. What about the placement of the actual freeldr.sys? jaclaz

Is the disk and filesystem working? NTFS may have some (hopefully minor) corruption, that may prevent from accessing the registry backing file. What I would do personally would be: 1) make a forensic sound or dd-like copy of the whole disk 2) run chkdsk (in steps, once without parameters and if errors are found with the /F) 3) defrag the file system 4) re-reun chkdsk BUT - BEFORE that - what size is the system file (the one that won't load)? There used to be a size limit on "system" on 2000 OS, should be 16 MB: https://superuser.com/questions/271240/how-to-test-whether-a-windows-2000-registry-hive-is-corrupt or maybe it is 16 MB including system file and kernel size: https://social.technet.microsoft.com/Forums/windowsserver/en-US/bed7bb0b-f203-4e91-9cf2-92d361889e46/how-to-fix-windows-2000-server-registry-windirsystem32configsystem-limits-?forum=winservergen since it is happening to you on two systems this latter is more likely than two hard disks/filesystems failing at the same time. jaclaz

It sounds like a "queer" limit. When you happen to have another of these "Hive not found error", could you try running "extents": http://reboot.pro/index.php?showtopic=18570 and check where the not working file is? I mean - roughly - a normal XP install should be around 1.5-2 GB, even if you have (why?) a 4 GB pagefile, an "added" file should be at most around 6 GB distant from the PBR. There was an issue in early NT (3.5 and 4.0) that didn't allow boot volume larger than 7.8 GB: https://groups.google.com/g/comp.sys.ibm.ps2.hardware/c/O7H6_nk5FEs but even if you have a 128 (or 256) GB partition the freeldr.sys should anyway be well below 7.8 GB. jaclaz

It's not your personal feeling, it is what most people actually do (formatting/reinstalling), I suspect because if you ask or search about a problem you have on the Internet (with the rare exception of MSFN and a few more "friendly" forums) the replies usually amount to these (please choose one ): 1) That cannot be fixed, format and reinstall 2) It would take less time to format and reinstall 3) You should format and reinstall 4) Why don't you format and reinstall? 5) I had that same problem, I formatted and reinstalled and it went away. jaclaz

Naaah, Testdisk is an extremely useful and usually perfectly working semi-automated tool, but often some manual intervention is needed, very likely it will work in this case, but before calling anything actually lost there is manual repair possible. When (if) something is not recoverable via DMDE (used by a somehow knowledgeable operator) then you might state that "most probably all is lost". jaclaz

The issue with most hex viewers is that they show you the hex but do not have a way to show the meaning of the hex, the possibility of having templates/structure viewers is important, Winhex is an excellent program but commercial and relatively high priced, here is a page listing many other suitable ones (depending on the OS): https://github.com/dloss/binary-parsing the extreme fragmentation (and lack of a standard of sorts) has led to a Tower of Babel and templates/structure viewers are mostly self-written (and never published), Kaitai: http://kaitai.io/ hopes to change the situation, but - besides being rather complex - it is too early to say if it will be (hopefully) more widely adopted. Tiny Hexer is discontinued, but it works and needs not updates, it simply does what is supposed to do, like hundreds or thousands other programs, updates - generally speaking - have some meaning in either programs that are affected by the outside world - like browsers - or that are an incomplete crappy mess, like most of what today are called "apps". jaclaz

Yes, it doesn't matter the source, the serial/license is what counts. This confirms that the issue was somehow some old driver installed for your "old" motherboard, the usual advice when transferring an XP (or a 2K) is to generalize as much as possible the current installation (though in some cases it is not easy/possible). I don't think you will be able to pinpoint the specific driver giving problems by directory comparing, you would need to analyze the two Registries (not easy at all). jaclaz

It is strange, the interfaces are anyway called "SATA". The manual: https://download.asrock.com/Manual/G41M-VS3.pdf at page 41 is not particularly understandable. I suspect that this particular motherboard/chipset (ICH7) may use some sort of "bridge" between SATA and PATA, but the reference in the manual to Windows NT should mean that it should be compatible (if Windows NT can be installed, then definitely Windows 2000 can). Could it be the setting of PCI IDE BUS MASTER (page 43 of the manual? Viceversa - could it be that your old motherboard (last on which that disk/OS was working) had some particular mass storage or chipset/bus driver installed? In the good ol' times there was a FixIDE script for BartPe to solve similar problems, and a mergeIDE.reg from MS, but those, were for XP, not 2000, maybe some info is valid also for 2000, but I don't know: https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/314082 I still think that you need to find a way to install a fresh 2K to that computer to see which drivers are actually used. jaclaz

So it cannot be the SATA (or AHCI) driver missing, in any case do check the BIOS for related settings. I wonder what it could be, 7b is typical of a mass storage device driver missing or mis-configured, other possible issues tend to give different errors. And when "transplanting" a NT OS the two things that usually tend to go wrong are the SATA/AHCI or the HAL/Kernel, but a "wrong" HAL would normally give another error, 0x0000000A if I recall correctly. If you have a second spare hard disk, it would be probably easier to attempt a new install from CD/ISO and compare which drivers and HAL are used by the new install (if it succeeds). jaclaz

0x0000007b is inaccessible boot device which translate to "I have no drivers for the boot disk", this is typical of a missing SATA driver. You can try uniata: http://alter.org.ua/en/soft/win/uni_ata/ No idea if it is compatible with your hardware, though, nor how exactly you can install it on an existing installed system (since you have not the CD anymore, you would probably need to check if one is available on archive.org[1]). jaclaz [1] this might do of you are looking for the Italian version: https://archive.org/details/windows-2000-italiano-raccolta-di-mrgass

The Softpedia link should be still fine: https://drivers.softpedia.com/get/GRAPHICS-BOARD/INTEL/Intel-HD-Graphics-Driver-145605441-for-XP.shtml jaclaz

It's strange, Error 105 and that message is an InstallShield error message, and seemingly it is often connected with a corrupted file, but in this case it could well be another error (caused by the Windows 98) that has nothing to do with the issue on XP and 7, anyway it helps to identify the installer as Installshield, that has a whole lot of functions related to long path names, it is likely that (in the installer) some of this functions are incorrectly used and are "triggered" by a long enough (but not full 256/260 long) path. jaclaz

There is (was) a limit to 256/260 characters in paths, so-called MAX_PATH: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation https://learn.microsoft.com/it-it/windows/win32/fileio/maximum-file-path-limitation You can try using the \\?\ prefix in some cases, but this might or might not work specifically (i.e. if the call to a long path is from within an installer or whatever other program), BUT the long path you posted is much shorter than 256 characters, so the reason is *something else*, unless (since it is an installer) it tries to create a longer path to (say) decompress some files, like: C:\Users\cad2000\Desktop\ASUS_Q87M-E\Aggiornamenti_AutoCAD2000\risolve_stampa_autocad_2000\Plotupdate2000\Plotupdate2000\a_subfolder_inside_another_subfolder\that_we_will_use_for_temporary_files\temporary_file_folder\yes_really_temporary\ Permissions? It is NOT the OS version (as it works from another place). jaclaz

I pointed you to a file splitter (and re-joiner) that works in all Windows including 98, but if you just split the file, you can use the "plain" copy /B to join the parts: copy /b part1.ext+part2.ext[+partn.ext...] whole.ext But - if you want to use an archiver instead, you need to use one that is 98 compatible as the files are usually not simply split, and need to be decompressed by the same program that compressed them. With 7zip probably you can use the .zip file format, that should be compatible with older versions such as 4.xx, but it would be easier to use a program that runs (same version) both on your source PC and on the Win9x target, info-zip should do, the site: https://infozip.sourceforge.net/ is largely down, but you can find here: ftp://ftp.info-zip.org/pub/infozip/win32/ the needed file zip300xn.zip. but maybe it is a tad bit too complex in usage, being command line only and with an endless amount of options, the easiest would be to simply split the file "as is" with the given splitter, which is GUI: https://www.martinstoeckli.ch/splitter/splitter.html There is no practical limits on size of disk (in the sense that up to the 28bit-LBA, i.e. 137.4 GB you should be fine[1]), since the interface you have is very likely an IDE one, the issue might be to find an old IDE/ATA disk 3.5" disk, sized 120 GB or less, unless it is some sort of "old stock" such disks can only be found used (and of course they will be old) possibly you will need to find a 1-2-4 GB DOM (expensive) or a ATA/IDE to SD adapter or a IDE to CF card adapter (but lately CF cards are becoming scarce and expensive as well), there are also IDE to SATA adapters, but easily available SATA disks will be much larger than 137.4 GB, maybe a 120 GB SSD with such an adapter would do. jaclaz [1] https://tldp.org/HOWTO/Large-Disk-HOWTO-4.html

Do you mean you have a single floppy disk? A lot of archivers (compatible with Win9x) will allow to compress a file and divide the resulting archive in floppy-sized chunks. It won't be fast, but it used to work just fine. Or you can just split the .exe and recombine the chunks on 9x with copy /b, or use a dedicated program *like*: https://www.martinstoeckli.ch/splitter/splitter.html jaclaz

Side note, Avast has seemingly been bought by NortonLifeLock, after more than one year long procedure: https://investor.nortonlifelock.com/news/news-details/2022/NortonLifeLock-Completes-Merger-with-Avast/default.aspx they plan to change name: and probably (IMHO) technology from Norton will be poured over (ex-)Avast, thus (stiil IMHO) ruining the products for good. I think this can be good news for those people that have too d@mn fast computers and couldn't find an easy solution to slow them down. jaclaz

AFAICR it was a downloadable file called MSRDPCLI.EXE: http://www.wilsonalvarez.com/remotedesktop/index.htm for 9x and 2000, while it was included in XP. jaclaz