`Could not load SYSTEM.ALT hive!` after install nVidia driver

[ludufre]

Hi.

I'm creating a image from scratch because of language (I'm from Brazil).

After performing all steps, this includes the USBs with seven wizards to get Hub to work, I have installed the nVidia Go 7300 from 09/26/2006 and after restart I stuck in FreeLoader with message Could not load SYSTEM.ALT hive!.

I restarted from beginning three times (qemu, hddfix, efi files, pciide.sys, delete enum, reenumerate on boot, add missing things to regedit), and always when I install the nVidia I get this error on FreeLoader. If not installing nVidia I can restart everytime without issues.

I'm certain that the driver versions is correct because if i flash your image from Internet Archive the driver install with success.

There is some logs of any type I can grab to help investigate this issue?

[ludufre]

Inspecting the Hive with another XP machine I can see that the regedit it's okay...

[DistroHopper39B]

Can you try:
Add -v to Kernel Flags in com.apple.Boot.plist
Add /SOS to Options in freeldr.ini
That should get you more debug info. Seems like something’s up with FreeLoader when using non-English languages.

[ludufre]

Now I'm getting a funny screen.

Tried too:
Options=/FASTDETECT /SOS
Options="/FASTDETECT /SOS"
Options=/FASTDETECT/SOS
Options=/SOS

[ludufre]

I'll try with English ISO to confirm if I'm messing up or non-english issue

[DistroHopper39B]

Hmm. Can you try booting without /SOS? The first Options= thing you tried is the correct syntax by the way. You should see some lines beginning with (../boot/freeldr/freeldr appear in the top left, they might disappear after a second.

[ludufre]

With English ISO I have success. Installed nVidia Go 7300, Broadcom Wifi, Chipset and Realtek Audio. Everything works.

With pt-BR ISO I'm getting consistent related error. Using Slow-mo I get those logs:

[ludufre]

One thing I can't urderstand: I have system.sav and not system.alt longside system in C:\windows\system32\config. Maybe the name is wrong in freeldr?

[DistroHopper39B]

One thing I can't urderstand: I have system.sav and not system.alt longside system in C:\windows\system32\config. Maybe the name is wrong in freeldr?

That is correct. I think system.alt is correct for ReactOS, but I'm not sure.

[DistroHopper39B]

This is definitely an issue having to do with how FreeLoader interacts with non-English Windows. It might be a fixed bug but my version of FreeLoader is based on a quite old codebase. Either way, it should be investigated.

[ludufre]

So, I think I managed to solve it.

I’ve been trying repeatedly since yesterday. I only slept 4 hours. I even filmed myself installing XP in both English and Portuguese, watching almost frame by frame to see if I was doing something differently between the two. And the English version always works fine after installing the Nvidia driver, while the Portuguese version has the Hive issue.

I noticed that the English version also shows the message “err: Using LBA48 addressing mode,” so that’s not the cause. I think the message appears with the “err” prefix because in the source code, it’s inside a TRACE() method.

Even on the verge of losing my sanity, I also noticed that the 3.3V battery was completely dead. Obviously, that wouldn’t be the cause, but I replaced it anyway, and of course, the problem persisted.

The interesting thing, which I hadn’t mentioned before—and honestly, hadn’t even noticed—is that after installing the graphics card and rebooting, the system starts normally with full graphical acceleration and everything. However, this time, when shutting down or restarting, Windows no longer freezes; the screen actually turns off.

So I started wondering: could Windows be failing to shut down properly, leaving the disk in an unexpected state? I’ve seen cases before where a hibernated Windows, for example, can’t be mounted as Read-Write in Linux. Could this be something similar?

While researching, I read about the disk Write Cache. I disabled it in Device Manager, and when shutting down, the behavior remained the same—the screen turned black instead of freezing. On the next boot, FreeLoader loaded normally without complaining about SYSTEM.ALT.

The interesting part is that I can consistently reproduce this issue (shutting down after the first boot with the graphics card installed), but if I disable the disk Cache, I can reboot infinitely without any problems with FreeLoader.

Here’s a 10GB image with device enumeration already completed. Just authenticate with the password “sandman” and install the graphics driver. [my fiber internet is offline. I'm using 4G right now and is very slow. Later I'll upload de image] (After installation, it will boot again without issues; the problem occurs on the next reboot.)

I can’t say exactly what’s happening. I’m not sure if my theory makes sense, but if I re-enable the Disk Cache later, the system restarts and works normally as well.

At this very moment, I redid the entire installation from scratch. This time, I used a 40GB image (to avoid needing to extend the partition). I started QEMU with network support (before the Enum deletion step), installed Legacy Update (http://legacyupdate.net/), installed all 129 updates, including DirectX, the latest Microsoft Security Essentials update, and continued with the steps. Everything is working perfectly.

Again: I have no idea if I actually solved it, if it was just luck, or something else…

[ludufre]

So… It was just luck after all. I have a disk image that works correctly (I can restart it 100 times successfully), but when I tried following the steps again, it failed after the second reboot following the video driver installation.

This time, I tried:

• Disabling Write Cache on the disk,
• Running powercfg /h off,
• Setting the power profile to “Always On”,
• Setting HackFlags = 0x000001 in HKLM\SYSTEM\CurrentControlSet\Services\PCI.
• Setting PowerDownAfterShutdown = 1 in JKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

I still think that Freeloader isn’t able to access the disk, which is why it fails to read SYSTEM, and then SYSTEM.ALT, since it doesn’t actually exist…

I even compared the SYSTEM file from the working image with the failed one and didn’t find any significant differences.

I’m completely in the dark.

[ludufre]

I’m exploring the possibility that FreeLoader is actually accessing the disk but failing to read the SYSTEM (maybe it’s dirty? I don’t think it’s corrupted, since I can boot normally in QEMU using the disk image).

Opening both SYSTEM files—the one from the disk that fails to read SYSTEM.ALT and the one from the disk that, luckily, has no issues in Registry Explorer—I noticed that the faulty one has some invalid entries (Unassociated deleted values):

[ludufre]

Here’s a 10GB image with device enumeration already completed. Just authenticate with the password “sandman” and install the graphics driver. [my fiber internet is offline. I'm using 4G right now and is very slow. Later I'll upload de image] (After installation, it will boot again without issues; the problem occurs on the next reboot.)

Finally fiber optic back.

https://drive.google.com/file/d/1acR36zvEH-t3LIvKjEKImgADUqgbwEJ4/view?usp=sharing

This image is pt-BR after enumerated in Apple TV. No drivers Graphics, Wifi, Audio, chipset, installed yet.

Steps do reproduce:

• Password: "sandman"
• Install nVidia Driver (enable Full acceleration)
• Restart or Shutdown (freezes as normal)
• When restarted with graphics and acceleration restart again (this time not freezes the screen turn black)
• Fail on FreeLoader to load SYSTEM.ALT

[DistroHopper39B]

Thank you for all the research you did. I think I know now what is causing the reboot issue if disabling Disk Cache fixes reboot. I do an ugly hack to avoid a limitation of the FreeLoader IDE driver. I think I’ll setup the system to undo this hack after disk access is no longer required. The screen turning black on NVIDIA is expected, I guess I just forgot to document that.

I’ll check out your image later.

I’m exploring the possibility that FreeLoader is actually accessing the disk but failing to read the SYSTEM

This is most likely the correct explanation. The SYSTEM hive isn’t the first thing FreeLoader attempts to load - if the HDD was completely inaccessible, FreeLoader wouldn’t be able to find freeldr.ini after all.

Is it possible that you are unplugging/replugging too soon? I usually left 5-10 seconds after the freeze.