Start Me Up

Hello Windows 2000 fans, a while ago when WildBill was backporting security updates from Windows XP to Windows 2000 he noticed a flaw in Microsoft's implementation of the security fix in the function "_SetWindowWord". By now Microsoft released an update for Windows 2000 to fix the security problem so WildBill's backported version has been superseded. However, the flaw still exists in the newest versions of win32k.sys from Microsoft both in Windows 2000 and in Windows XP. The flaw causes problems in some applications which try to deal with their graphical user interface. In an extreme case it can cause the bluescreen "WINLOGON_FATAL_ERROR". The flaw has a pretty small security impact. There is an update available to fix the flaw: WINDOWS2000-OTSKB000004-V1-X86-INTL.exe Since the newest version from Microsoft contains the security fix already, this update fixes the flaw only. It's all that was left to do. There is more information available about this issue and this update in the article in the knowledge database: OTSKB.chm The patch updates the file "win32k.sys" from the version "5.00.2196.0004" to the version "5.00.2196.0005". Special thanks go to @dencorso for reporting the bluescreen "WINLOGON_FATAL_ERROR" (0xC000021A) in Windows XP and narrowing down the problem to the Windows update "Windows XP (32 bits)/KB981957" and @WildBill for further narrowing down the problem to the function "_SetWindowWord" and to the exact machine instruction within the function.

Well, I read the post a while ago but I don't have the hardware to reproduce the bug. Here are the files if you like to experiment.

Regarding the USB updates: To extract files there is the command line option "-c" for old updates and "-x" for new updates. With other words: Click "Start" Click run enter "cmd.exe" Drag and drop the update (the exe file) into the command prompt so the address is inserted. Then add a space and then "-x" and press enter. To integrate an update into a Windows installation CD: Insert the vanilla Windows CD into your CD drive. Copy all files to a directory with a short and simple path like "C:\cd". Use the command line option "-s:C:\cd\" to integrate the files into the CD directory. Now the vanilla Windows CD has turned into a custom CD. Burn it as bootable data disk. However, I don't think that the update "KB836111" has the command line switch "-s". But with the newer ones this should work. Regarding the main problem: Now that you tried basicly everything that both of us could think of, I think we have a problem that can't be solved easily. You tried it your way and you tried it my way and it failed anyway. So maybe you are forced to use Standard PC after all. Or some different hardware. But that's not quite what you wanted. Well, there were some outdated core component files that can be updated, but who knows whether this will get you anywhere KB2535512.7z KB2676562.7z Maybe you are right and the files from the updates haven't even been loaded yet when the hang happens. But they might still be nice to have.

About a year ago there was an announcement by a user who goes by the handle "Windows 2000 Warrior" about some work on ACPI support in Windows 2000. In his announcement he stated: @windows2 are you still around? Is there any news on this issue?

You came up with the theory that you need to make changes to the files "driver.cab" and "sp4.cab" for a second time now. I guess that the guide you mentioned but didn't bother to link is this one. It contains the approach to modify the file "driver.cab". I told you that you should not make any changes to them. I further explained that the file "driver.cab" is a back up storage for RTM files and the file "sp4.cab" is a back up location for service pack 4 files. I further added that people who don't know how the system file protection works mess with these files to destroy the mechanism to a degree that it doesn't work anymore because it has no source anymore to restore overwritten system files. Also, that you add additional problems to your system if you do so. Since I wrote this message just a few days ago, I don't think that you have forgotten about it So my theory is, that you ignored it because you are convinced that the information is incorrect but don't have any facts to prove your point. Since you said that this is an important point to you and I don't want to end up in an endless loop where I tell you that you are messing with the wrong files and you try to do it anyway, let's go through this. people who don't know how the file protection works mess with driver.cab and sp4.cab One of my claims is, that people, who don't know how the file protection mechanism works, mess with these files. You were asking which of the files in these cabinet files need to be overwritten and read a guide which documents how to modify the cabinet files. This indeed shows that you don't know how the file protection mechanism works while you are one of those persons who want to mess with the files so it is evidence that my point is actually correct driver.cab contains RTM files Another claim of mine is that the file "driver.cab" contains RTM files. Now that you inspected the content of this cabinet file you noticed that there are files with exactly the version numbers as I listed as RTM files. The only difference you found was with the file "usbstor.inf". You said, that you found the version "5.0.2138.1". Yes, this true for the english edition of Windows 2000. The english edition contains an outdated version of this file. The arabic edition, for example, uses the version "5.00.2195.1" as listed in one of my previous posts. This is strong evidence that my point regarding the content of the cabinet is correct. sp4.cab contains SP4 files Another claim of mine is that the file "sp4.cab" contains SP4 files. While you did your inspection you also checked out the file "sp4.cab". If you compare the version numbers you found with the version numbers I listed, you will once again notice that they are indeed SP4 files. This is strong evidence that my point regarding the content of the cabinet file is correct. driver.cab and sp4.cab should not contain anything else than what they already have Another claim of mine is that the mentioned cabinet files should not contain anything else than what they already have. Official post SP4 Windows updates install new files without changing the content of the 2 mentioned cabinet files. This is strong evidence that my point, that the cabinet files should not be changed, is correct. messing with driver.cab or sp4.cab can cause problems Another claim of mine is that when someone performs modifications to these 2 cabinet files then this can cause problems, like being unable to switch the HAL. It was quite a while ago but nevertheless there was a point in time when I discovered the directory "driver cache" and wondered what it was for. It contained the discussed cabinet files and some other files. At the end of the day it used up disk space and I did not know what these file were for. So I thought, since it is some kind of cache, it probably doesn't hurt to empty it. So I deleted the content. I think that went well for a while. But when I wanted to switch the HAL I couldn't do it anymore because the required files for the new HAL weren't available anymore. So maybe a better directory name would be "driver repository". At a different time I changed a file within one of the cabinets. I created a new cabinet file but of course it wasn't exactly the same as the old one. Maybe I used a different compression method or screwed up something else. Anyway, the result was, that I could not boot anymore. Now this isn't strong evidence for anything but it is still nonetheless some evidence that messing with these cabinet files can indeed cause problems. And these reasons and this experience I made lead to my viewpoint. Now I could still be wrong about my theory how the system file protection of Windows 2000 works and how an update of system files works, but what evidence do you have to support your theory that the cabinet files might need to be modified anyway?

I performed some tests on hardware of mine to reproduce the bluescreen you see. The test results after switching from Standard PC to ACPI PC are as follows: test system #1: processor brand name: Atom 230 processor manufacturer name: Intel BIOS brand name: BIOS setup utility BIOS manufacturer name: American Mega Trends Test result: No bluescreen, boots flawlessly. test system #2: processor brand name: Atom D525 processor manufacturer name: Intel BIOS brand name: CMOS setup utility BIOS manufacturer name: Award Software Test result: No bluescreen, boots flawlessly. test system #3: processor brand name: Atom D2550 processor manufacturer name: Intel BIOS brand name: ASRock UEFI setup utility BIOS manufacturer name: American Mega Trends Test result: No bluescreen, boots flawlessly. test system #4: processor brand name: Atom E3815 processor manufacturer name: Intel BIOS brand name: visual BIOS BIOS manufacturer name: Intel Test result: Bluescreen as follows: 0x0000001e: KMODE_EXCEPTION_NOT_HANDLED 0xC0000005: STATUS_ACCESS_VIOLATION 0xbffe1aaa: address of the code that caused the bugcheck 0x00000000: 0x00000010: address of the target that was accessed 0xbffd8000: base address of ACPI.sys, version 5.00.2195.6920 test system #5: processor brand name: Atom E3815 processor manufacturer name: Intel BIOS brand name: H2O BIOS manufacturer name: Insyde Test result: No bluescreen, boots flawlessly. test system #6: processor brand name: Atom N280 processor manufacturer name: Intel BIOS brand name: hp Thin Client setup utility BIOS manufacturer name: American Mega Trends Test result: No bluescreen, boots flawlessly. test system #7: processor brand name: Core i5-3337U processor manufacturer name: Intel BIOS brand name: H2O BIOS manufacturer name: Insyde Test result: No bluescreen, boots flawlessly. --- When you try to install vanilla Windows 2000 with service pack 4 and ACPI PC selected, does the setup hang like it does with your other iso?

Let me address the USB regression first, since it is easier to deal with. It's just a lot of work on my side to gather the information. The issue you described sounds like the issue that was fixed with the Windows 2000 update "KB829759". This is a non security related bug fix for USB. The report on this update mentions 100% CPU load, unrecognized USB devices and the error codes 28 and 31 in the device manager. With a vanilla Windows 2000 installation and service pack 4 integrated or installed afterwards, you should have the following files on your computer: hidclass.sys - 2003-06-19 - 5.00.2195.6655 hidusb.sys - 1999-10-04 - 5.00.2142.1 openhci.sys - 2003-06-19 - 5.00.2195.6675 uhcd.sys - 2003-06-19 - 5.00.2195.6655 usb.inf - 2003-06-19 - 5.00.2195.6717 usbaudio.sys - 1999-10-12 - 5.00.2150.1 usbcamd.sys - 1999-09-27 - 5.00.2135.1 usbd.sys - 2003-06-19 - 5.00.2195.6658 usbehci.sys - 2003-06-19 - 5.00.2195.6709 usbhub.sys - 2003-06-19 - 5.00.2195.6689 usbhub20.sys - 2003-06-19 - 5.00.2195.6655 usbintel.sys - 1999-09-25 - 5.00.2134.1 usbport.sys - 2003-06-19 - 5.00.2195.6681 usbprint.sys - 2003-06-19 - 5.00.2195.6655 usbscan.sys - 2003-06-19 - 5.00.2195.6655 usbser.sys - 2003-06-19 - 5.00.2195.6655 usbstor.inf - 1999-12-10 - 5.00.2195.1 usbstor.sys - 2003-06-19 - 5.00.2195.6655 The report mentions that the bug was introduced with the following versions: usbehci.sys - 2003-01-15 - 5.00.2195.6655 usbhub20.sys - 2003-01-15 - 5.00.2195.6655 usbport.sys - 2003-01-20 - 5.00.2195.6657 And that the bug was fixed with the following versions: hidclass.sys - 2003-09-21 - 5.0.2195.6824 openhci.sys - 2003-09-21 - 5.0.2195.6824 uhcd.sys - 2003-09-21 - 5.0.2195.6824 usb.inf - 2003-10-08 - 5.00.2195.6863 usbd.sys - 2003-09-21 - 5.0.2195.6824 usbehci.sys - 2003-09-21 - 5.0.2195.6824 usbhub20.sys - 2003-09-21 - 5.0.2195.6824 usbport.sys - 2003-09-21 - 5.0.2195.6824 So the files from service pack 4 are affected by this issue. Some of these files are included in various Windows updates: hidclass.sys RTM - 1999-10-25 - 5.00.2163.1 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655 KB818129 - 2003-01-15 - 5.00.2195.6655 KB820759 - 2003-01-15 - 5.00.2195.6655 KB827675 - 2003-09-13 - 5.00.2195.6820 KB829759 - 2003-09-21 - 5.00.2195.6824 KB838989 - 2003-12-12 - 5.00.2195.6882 KB843503 - 2003-12-12 - 5.00.2195.6882 hidusb.sys RTM - 1999-10-04 - 5.00.2142.1 openhci.sys RTM - 1999-10-26 - 5.00.2164.1 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6675 KB818129 - 2003-04-23 - 5.00.2195.6739 KB819895 - 2003-05-08 - 5.00.2195.6743 KB820759 - 2003-05-08 - 5.00.2195.6743 KB823715 - 2003-07-22 - 5.00.2195.6789 KB827675 - 2003-09-13 - 5.00.2195.6820 KB829759 - 2003-09-21 - 5.00.2195.6824 KB838989 - 2003-12-12 - 5.00.2195.6882 KB843503 - 2004-06-11 - 5.00.2195.6940 KB843540 - 2004-06-11 - 5.00.2195.6940 uhcd.sys RTM - 1999-10-05 - 5.00.2143.1 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655 KB818129 - 2003-04-23 - 5.00.2195.6739 KB820759 - 2003-04-23 - 5.00.2195.6739 KB827675 - 2003-09-13 - 5.00.2195.6820 KB829759 - 2003-09-21 - 5.00.2195.6824 KB838989 - 2003-12-12 - 5.00.2195.6882 KB843503 - 2003-12-12 - 5.00.2195.6882 usb.inf RTM - 1999-12-10 - 5.00.2195.1 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6717 KB829759 - 2003-10-08 - 5.00.2195.6863 KB838989 - 2004-06-01 - 5.00.2195.6936 KB843503 - 2004-06-07 - 5.00.2195.6939 usbaudio.sys RTM - 1999-10-12 - 5.00.2150.1 KB891069 - 2005-01-10 - 5.00.2195.7019 usbcamd.sys RTM - 1999-09-27 - 5.00.2135.1 KB836111 - 2004-03-16 - 5.00.2195.6883 usbd.sys RTM - 1999-10-09 - 5.00.2147.1 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6658 KB818129 - 2003-04-23 - 5.00.2195.6739 KB820759 - 2003-04-23 - 5.00.2195.6739 KB827675 - 2003-09-13 - 5.00.2195.6820 KB829759 - 2003-09-21 - 5.00.2195.6824 KB838921 - 2003-12-12 - 5.00.2195.6882 KB838989 - 2003-12-12 - 5.00.2195.6882 KB843503 - 2004-05-28 - 5.00.2195.6935 KB838417 - 2004-12-07 - 5.00.2195.7008 usbehci.sys KB810090 - 2003-01-15 - 5.00.2195.6655 KB818129 - 2003-01-15 - 5.00.2195.6655 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6709 KB820759 - 2003-05-13 - 5.00.2195.6745 KB827675 - 2003-09-19 - 5.00.2195.6823 KB829759 - 2003-09-21 - 5.00.2195.6824 KB838989 - 2003-12-12 - 5.00.2195.6882 KB843503 - 2003-12-12 - 5.00.2195.6882 usbhub.sys RTM - 1999-11-12 - 5.00.2181.1 KB810090 - 2003-01-15 - 5.00.2195.6655 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6689 KB838771 - 2004-03-16 - 5.00.2195.6883 KB838921 - 2004-04-01 - 5.00.2195.6884 KB838417 - 2004-12-02 - 5.00.2195.7006 usbhub20.sys KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655 KB818129 - 2003-01-15 - 5.00.2195.6655 KB820759 - 2003-01-15 - 5.00.2195.6655 KB827675 - 2003-09-13 - 5.00.2195.6820 KB829759 - 2003-09-21 - 5.00.2195.6824 KB838989 - 2004-01-16 - 5.00.2195.6891 KB843503 - 2004-01-16 - 5.00.2195.6891 usbintel.sys RTM - 1999-09-25 - 5.00.2134.1 usbport.sys KB810090 - 2003-01-20 - 5.00.2195.6657 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6681 KB818129 - 2003-04-28 - 5.00.2195.6741 KB820759 - 2003-04-28 - 5.00.2195.6741 KB827675 - 2003-09-13 - 5.00.2195.6820 KB829759 - 2003-09-21 - 5.00.2195.6824 KB838989 - 2004-03-23 - 5.00.2195.6885 KB843503 - 2004-06-16 - 5.00.2195.6941 usbprint.sys RTM - 1999-10-26 - 5.00.2164.1 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655 KB883528 - 2004-08-17 - 5.00.2195.6968 usbscan.sys RTM - 1999-10-13 - 5.00.2151.1 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655 usbser.sys RTM - 1999-10-15 - 5.00.2153.1 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655 KB838417 - 2004-12-02 - 5.00.2195.7006 usbstor.inf RTM - 1999-12-10 - 5.00.2195.1 usbstor.sys RTM - 1999-09-30 - 5.00.2138.1 KB813432 (service pack 4) - 2003-06-19 - 5.00.2195.6655 KB823086 - 2003-07-11 - 5.00.2195.6773 KB817765 - 2003-11-06 - 5.00.2195.6871 KB841880 - 2004-05-27 - 5.00.2195.6934 KB890202 - 2004-12-10 - 5.00.2195.7009 Let me know if the USB problem still exists after updating the USB related files with the Windows updates. And if it does still exist, what changes you have made to usb.inf to fix the problem on your system. That would be helpful. Thank you. If I find some time again, I will look into the other problem, which is the real blocker for you at the moment.

I am not 100% sure, but I think that this bluescreen does not come from ACPI directly but rather from a third party disk driver which can't handle the switching of the HAL. My theory is, that you used some kind of 3rd party disk driver to access your hard disk. Once you switched from ACPI to Standard PC the disk driver can no longer find the hard disk or thinks it found a different one or Windows decided to use a different driver (probably it's default driver) than the one it used before because it now has a "brand new" hard disk. When switching the HAL then Windows usually thinks the user just unmounted nearly every device and mounted new devices in the system because these new devices were never enumerated by the new HAL before. So they must be something "new". I think I once had this problem with UniATA but that was a long time ago. I have a similar situation with the graphics driver I once wrote: When the user installs the driver and then switches the HAL, then Windows will use the default graphics driver (vga.sys) again so he has to install my driver once again. The driver files are already in the correct directories of Windows but Windows needs to be told that it should use my driver with the graphics circuit for a second time. This problem would not happen if the user used the default driver in the first place and installed my graphics driver after switching the HAL. Do you get the same bluescreen with a vanilla Windows 2000 SP4 iso and IDE selected in your BIOS?

What is the second method? Did you get 2 different blue screens? --- Anyway, I looked up what the version 5.00.2195.6921 of acpi.sys is. It is a test version not ment for productive use. It seems to include a quick hack to suppress the bluescreen "STOP:0x000000A5 (0x0000000B, …)" and only this one. It does not seem to fix any problem. It seems, as it is rather an attempt to get those affected by the issue somehow through the setup. But I could be wrong, since there is only little information available. My source for this information: BlackWingCat's blog post from 2018 --- Maybe this site works for you to store the image somewhere.

I have no idea what you are trying to do. Are you trying to manually replace system files? The device manager has a graphical user interface to switch from one hardware abstraction layer to another. Are we talking about the same procedure? Regarding driver.cab and sp4.cab: In driver.cab there should be old files. No new ones. driver.cab is for the RTM files. These are the files that existed before any service pack was released. In sp4.cab there should be the files that were introduced with service pack 4. Nothing newer nor anything other than files from service pack 4. The problem I have noticed is that people who don't know how the system file protection works place their new files in these cabinet files where they don't belong to prevent the system from overwriting their new files with old ones. They are basicly destroying the system to such a degree by overwriting any backup location that the system file protection mechanism gives up on trying to repair the system. But then other parts of the system don't work properly anymore like switching the HAL.

Well, at the end of the day you make the decision and you decide which approach you choose. I can throw some information in and voice my opinion so you know what I would have done in your situation but I am not in your situation. Since you already got quite some information, here is my opinion: The first thing I would do is switch to Standard PC and then use Standard PC. Standard PC is not worse than ACPI PC. There are good reasons why this HAL exists. If there was a good reason not to use Standard PC then I would use it anyway, make an installation, install update rollup 1 for service pack 4 and then switch to ACPI PC. If the system doesn't boot anymore then just format the hard disk again. This experiment costs you something between 30 minutes and 1 hour. Just consider how much time this discussion costed on your side plus mine. However, so far I have not read any good reason why it was necessary to use ACPI PC. You mentioned that Intel's driver was needing ACPI PC. However, when I was using a driver from Intel for a graphics circuit (not for Sandy Bridge), I noticed that the HAL does not matter. Afterwards I deinstalled Intel's driver again and used something better. Also, I would not use the Frankenstein version with all kind of components which were collected from different Windows versions. But my opinion is only of limited value because you need to be happy with your system and my opinion on how you set up your system matters only little. Btw: Switching the HAL in the device manager might not work properly if someone messed with driver.cab. At the moment we still don't know whether the problem you are facing can be solved by using a different HAL (like standard PC), whether it is just a bug in the setup or whether it is related to one of the unofficial files or whether the problem comes from a messed up integration of other stuff into the iso. So much guessing and so little tests done to narrow down the problem.

Good, it's the newest, as far as I know. The version 5.00.2195.7006 is from the update rollup 1 for service pack 4. There is a non security related bug fix (KB896260) which updates the file to version 5.00.2195.7035. Then there is a security related bug fix (KB2535512) which updates the file to version 5.00.2195.7442. The version 5.00.2195.7392 is unknown to me. There is a security related bug fix (KB2676562) which updates the files to version 5.00.2195.7473. Good, they are the newest, as far as I know. The version 5.1.2600.5512 is no part of Windows 2000. It's a part of Windows XP and might not be compatible with Windows 2000. There is a non security related bug fix (KB897574) which updates the file to version 5.00.2195.7032. Good, it's the newest, as far as I know. The file with the date 2007-02-17 is not a part of Windows 2000 and might not be compatible with Windows 2000. There is a non security related bug fix (KB890579) which updates the file to the date 2004-12-28. Sorry, my list was not complete. Here are the newest files of this type that I am aware of: halaacpi.dll - version 5.00.2195.6988 halacpi.dll - version 5.00.2195.6988 halapic.dll - version 5.00.2195.6988 halmacpi.dll - version 5.00.2195.6988 halmps.dll - version 5.00.2195.6801 These versions are no part of Windows 2000 and might not be compatible with Windows 2000. Regarding files from Windows XP: Noone can tell whether any of them actually work in Windows 2000. Keep in mind that there are dudes out there who create Windows Frankenstein and when it doesn't instantaneously crash and burn on their computer then they claim that it works in general (for everyone). The version 5.00.2195.6921 was created by BlackWingCat and it is based on the newest official version 5.00.2195.6920. I read a comment by someone that BlackWingCat's version doesn't work on any of the systems he has. However, he didn't say whether the original version works for him. So I can't tell for sure whether he was reporting a regression or simply a "still not good enough". No, not that I am aware of. Windows chooses for you based on the location and the file name in combination with an inf file. --- Have you tried an original unmodified iso of Windows 2000 with SP4 integrated? Let me know if you need any official update.

Well, if the problem is related to the setup, then there is one thing that you could try in either way, whatever is more convenient for you: Install Windows 2000 on a different computer and use ACPI during the installation. Once the installation is complete and you are able to start Windows and shutdown successfully, unmount the hard disk drive and mount it into your Sandy Bridge system. Or: Install Windows 2000 on your Sandy Bridge system but with Standard PC selected. Once the installation is fully done switch to ACPI PC from the device manager. The probability that this will work isn't high but since your setup hangs you still got more than 0% chance for success. Edit: Once you booted to desktop with Standard PC or on different hardware you might also want to check whether some core components are of recent versions. Some bugs have been fixed since service pack 4 and therefore might help booting on your Sandy Bridge system: acpi.sys - version 5.00.2195.6920 mup.sys - version 5.00.2195.7442 ntkrnlmp.exe - version 5.00.2195.7473 ntkrnlpa.exe - version 5.00.2195.7473 ntkrpamp.exe - version 5.00.2195.7473 ntoskrnl.exe - version 5.00.2195.7473 fastfat.sys - version 5.00.2195.7075 ntfs.sys - version 5.00.2195.7050 udfs.sys - version 5.00.2195.7032 dmio.sys - version 2195.7058.297.3 ntldr - date 2004-12-28 These files can be updated with official Windows updates. Let us know if you need an update for any of the files.

Hello Windows 2000 fans, I noticed that there is another bug in the function "CreateXlateObject" in the file "win32k.sys". The execution order of 3 loops is incorrect which leads to the situation, that the static colors in a translation table (Xlate-object) is stored in the table but then are overwritten by dynamic colors directly afterwards. There is an update available to fix this problem: WINDOWS2000-OTSKB000003-V1-X86-INTL.exe There is more information available about this issue and this update in the article in the knowledge database: OTSKB.chm The patch updates the file "win32k.sys" from the version "5.00.2196.0003" to the version "5.00.2196.0004".

user57 you told us a couple of times how blazing fast your installer is. This is good and well and it is welcome progress. However, as I pointed out: Your installer faces the design problem, that you would need to re-release every update you like to speed up. This is something that cannot be done in a reasonable way. Also, NotHereToPlayGames pointed out that a simplified version of update.exe is not what the world needs.You need to implement the prerequisites checks and maybe even more stuff we haven't looked into. There is an official documentation about the inf file format for Windows updates but it doesn't cover all and everything. I am not sure whether you read it. That is why it might make more sense to find the root problem in the operating system itself. Well, I hope that the problem is in the operating system because if this is true, then it can be fixed with an unofficial patch for a specific API function. Are you able to narrow the problem further down so we know whether the problem comes from installing the files or whether it comes from installing the registry values?