Dave-H

One other thing I've now found is that if I put the machine into standby, it appears to be impossible to wake it up again. I had to resort to holding the power button down until it reset. Also, and I've seen this several times now, if the disk check runs on boot, it appears to work OK, but then I get a 0x50 BSOD (PAGE_FAULT_IN_NONPAGED_AREA) apparently caused by dump_ntoskrn8.sys. It then restarts OK.

Thanks, I have to say that a lot of this stuff is way over my head! So when the UAA driver first starts on boot it presumably isn't seeing the Realtek device. However it does see it if it is then stopped and restarted, which seems very odd.

True enough, but back on topic now please guys.

Yes, it's not the KB88111 driver being missing. I found a source of it here, and the versions of the two sys files are the same as the ones I've already got.

Sounds like a similar scenario, but my 'Microsoft UAA High Definition Audio' device is apparently working all the time, but the Realtek audio device does not appear at all until the Microsoft device is uninstalled and reinstalled or disabled and re-enabled, at which point the Realtek device appears. I wonder if there are any alternative drivers for 'Microsoft UAA High Definition Audio'? As it's an Intel based machine I wonder if there is an Intel driver that might work better.

@Dietmar I've discovered something else with the sound on the Flex 10. You don't have to uninstall and reinstall the 'Microsoft UAA High Definition Audio' device to get the sound back. Just disabling it is enough. If I disable it and then enable it again, the Realtek audio device magically appears and the sound works, without any messages popping up! I'm wondering if this is a timing thing. The Realtek driver works through the 'Microsoft UAA High Definition Audio' device, so is it possible that the Realtek driver is starting first before the 'Microsoft UAA High Definition Audio' device is started, and therefore it can't load?

OK thanks. When I did the new installs, the machine would shut down OK, but hung on restart. With my old installation with the previous acpi.sys it was using, it would restart fine, and it would partially shut down, but with the "it's now safe to turn off your computer" message so I then had to actually shut down manually. With your latest acpi.sys, it now freezes on restart, but does shut down correctly, although it takes a while to do so. I can't quite see what the difference is between restarting and shutting down as far as unloading the drivers is concerned. Surely it's the same process, so why does one hang and not the other? I would more understand it if it would restart but not shut down, but it's the other way around!

@Dietmar@Mov AX, 0xDEAD@George King@daniel_k@Damnation Just a thought guys. Do you think I should move the posts here which are specifically about my Lenovo Flex 10 machine to this thread? They are possibly relevant to the general discussion about ACPI for XP on newer hardware, but I don't want to hijack the thread with my own specific issues.

@Dietmar Thanks. I've now tried just using your acpi.sys on my original Flex 10 XP installation. I just substituted it using Windows 10, and it still worked OK, and found a few more devices. Best of all, the warnings in the system event log on every boot about lack of resources for some devices have gone away! I've also managed to switch the machine to an ACPI Multiprocessor PC, with no ill effects, so it's now seeing both processor cores and is considerably faster. There are now two new 'unknown devices' in Device Manager with no drivers for them. It is now the same as the 'clean' installation, in that it freezes on restart (but not shutdown) and I cannot get the sound to keep working over a reboot. If these issues can be solved I will be a very happy man indeed!

@vinifera @D.Draker Stop this now both of you, or you will both be on the naughty step!

@Dietmar No apparent problem with partmgr here. 'Serial' is the only hidden device showing an issue, and that can't be started apparently because there are no devices associated with it (perhaps it's for a serial port?) I am very puzzled why the audio driver does not stay loaded over a reboot. I would have thought that once all the necessary registry entries were there for it, it would load OK every time. Here's the bootlog. ntbtlog.txt

Hmmm, seems like I celebrated too soon. When I reboot, the Realtek hardware has disappeared again, and no sound! I can get it back by uninstalling the 'Microsoft UAA High Definition Audio' device again and then rescanning, and it puts it all back again, but it doesn't seem to 'stick' over a reboot. I assume you're not seeing that @Dietmar? The only other serious problem still there is that the machine will shut down (contrary to what I said earlier) but it won't restart, it just permanently freezes on the 'Windows is shutting down' logo.

@Dietmar I tried installing again using this version of acpi.sys, and it seems the same as the last one I tried. I'm not sure what you mean with the sound. I have deleted the 'Microsoft UAA High Definition Audio' device, and then reinstalled it as you said, but nothing's changed, there is still no audio hardware in the 'Sound, video and game controllers' section. What else do I have to do? UPDATE! I've now realised that just rescanning with Device Manager isn't enough, you have to reboot after removing the device! It's now installed the audio devices, and they work with the Realtek driver, as you say. Sound at last!

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?