Dave-H

Did you read my subsequent message? I did find a problem with the filesystem on the memory stick, and after chkdsk fixed it, it then seemed to be OK. 👍

OK, just an update. I now have three items with problems, the 'MBI Driver', the 'Intel Dynamic Platform & Thermal Framework Driver', and the 'Intel Dynamic Platform & Thermal Framework Processor Participant'. They all show code 39, driver missing or corrupted. I can't find a driver which works, and there are three entries in the system event log on every boot about these devices saying they are not valid win32 applications. There are no errors in the event logs now about resources, as there are on my normal installation, which looks good! The mystery is still the missing audio hardware, which still doesn't seem to be being seen by the system at all.

Thanks, good to know that I have the most recent version! I'm just trying again with the previous install, this time a ran a chkdsk on the memory stick first, and it found a few errors. Every time I plug it in using Windows 10 it tells me it needs scanning, but it never finds anything wrong when it does scan it, but I thought maybe I should eliminate that as a possible problem. This time there were no BSODs, so it could have been something wrong with the file system on the memory stick which may have prevented the acpi.sys being copied. Everything went OK this time, although the audio hardware still isn't being seen, and there are some errors in Device Manager that I'm working on resolving. The machine still freezes on shutdown. Much better result now though!

No, you shouldn't defrag any solid state storage device. There's no advantage in doing so as their access speed is not affected by fragmentation, and it will just put unnecessary wear on them and shorten their life.

I did the install again from scratch, and this time I said NO to replacing hal.dll. Exactly the same result, now can't boot again! The same thing happened with the setup as well @George King. The replacement acpi.sys file was definitely in the \sources\$OEM$\$$\system32\drivers folder, but again didn't appear to be used. Not only that, but the folder was empty after the setup, which would indicate that the file was either moved (presumably to the wrong place) instead of copied, or was deleted. I replaced it manually again, and the scenario was the same as before after that. Maybe I will try again using the Integral Edition. I have a version from December 19th last year, so I guess I need to download it again as presumably it's been updated since then. I'll also have a got with @Dietmar's acpi.sys.

So can I fix this HAL problem without reinstalling from scratch again, and if so, how?

That's exactly what I did with the new acpi.sys, but the setup didn't appear to use it. I have had this happen before, and sometimes the files get used and sometimes they don't, and if you remember sometimes they vanish from the folder as if they've been moved instead of copied, but it seems to be very inconsistent.

No more of this here please or I will put my moderator's hat on! I wanted to ask, as the main reason to use ProxHTTPSProxyMII Rev3e is that it apparently supports TLS 1.3, is there any way of confirming that this is working? I've tried a few test sites, but the results are inconclusive.

Presumably @George King's ISO which I'm installing from, would be OK. I seem to remember the business with different HAL versions is quite confusing, at least to me, as different files change their name and become hal.dll depending on what HAL you're using. I just want to get it to boot again without having to do the whole install again! It seemed logical to me not to replace a newer file with an older one, but in this case it was obviously the wrong thing to do!

OK, I tried that file, and got the same BSOD. I then checked in Windows 10, and found that the setup hadn't actually copied the new file to system32\drivers, it was still the original. I manually copied it, and the BSOD went away, temporarily! The setup continued, but on the next reboot the BSOD came back again, exactly the same. I then used the 'Last Configuration That Worked' option and it then rebooted successfully and carried on! The system does not restart, it freezes permanently on the 'Windows is shutting down' screen, and I have to do it manually. On the next reboot, the BSOD came back again, and I had to use 'Last Configuration That Worked' again. Setup then continued again and this time it carried on until the very last stage, when instead of loading the desktop, it just permanently froze. On reboot it loaded up OK. When installing devices, it said that hal.dll was being replaced with an older version and asking if I wanted to do it, and I said no. On the next boot I got a message that hal.dll is missing or corrupt, and I now can't boot at all! Should I try to restore it using Windows 10?

That's good to know! If this can be fixed without the risks involved with modifying the BIOS that would be amazing. I'll wait until the new acpi.sys is published and then try a new install with George King's installation package, using it. Thanks, Dave.

I have BIOS version 93CN55WW(V9.5) 64 bit. Are you saying that one of those other versions, which appear to be older, would work better for XP as they are?

I think the documentation is absolutely fine. My only very minor observation is that the installation instruction implied (at least to me!) that you have to copy the whole program folder to your desired location, keeping the same folder name. That isn't the case of course, you can just copy the sub-folders and files from the folder to a new folder with a different name, and it still works fine. Being very picky here I realise!

I second that, it's all working very well, and the menu looks great!

That sounds quite frightening, and I'm not sure if it's really worth the trouble, not to mention the risk of permanently bricking the machine if anything goes wrong!

No problem, I always knew it was going to be very difficult to get a complete install of XP onto this machine! What I have isn't actually too bad, the main annoyance is not having any sound as the audio hardware isn't being seen. It's also only seeing one core of the dual core processor. Everything else important does work. It does restart OK, but if I shut down in XP I get the good old "It's now safe to turn off your computer" message! I can live with that though.

OK, here it is! The numbers are indeed different, but I have no idea whether that's significant or not.

No joy I'm afraid, instant A5 BSOD on the reboot with all three versions.

OK, I'll try with those three versions of acpi.sys and I'll report back!

Checking with Windows 10, the acpi.sys file now on the Windows XP installation is version 5.1.2600.7777 with modified date 28th April 2022, which I think is correct. The created date is 14th April 2008. The properties' sizes match exactly with the correct file so I've no reason to think that it isn't the correct file.

OK, I tried a straight substitution, and to nobody's surprise I'm sure, I just got an A5 BSOD! I then tried a new install, putting the new acpi.sys file into \sources\$OEM$\$$\system32\drivers. Still an A5 BSOD on every option except 'Standard PC'. One strange thing though is that after the install, the \sources\$OEM$\$$\system32\drivers folder is empty. Shouldn't the file still be in there @George King?

At the moment the machine is an 'Advanced Configuration and Power Interface (ACPI) PC' in Device Manager. The only other option offered is 'Standard PC', but I do remember doing a registry hack before to return the other options. I'll give that a try first and if that doesn't work I will do another install from scratch with George's latest package.

I think we discussed this before @Dietmar. You had a modified BIOS for a Flex 10, but it wasn't compatible with my processor. I must say this does look very complicated!

OK, thanks very much. Do I have to do a complete new install, or can I just change the file on the existing installation and then try changing the machine type?