harkaz

@ PRB They don't need to release a hotfix to prevent the POSReady tweak. They need to change the detection algorithm of their Windows Update Servers.

It's just finished uploading. I accidently screwed up the original sfxcab installer, that's why I had to reupload the file. Looking forward to your comments...

New release - Beta 2 build now available

@ tapdrip I won't include the patch in the SP4 package. However, I'll try REing the patch and backporting it to XP from Server 2003 x86, after I'm done with this project.

I'm fixing a couple issues with MCE CD-ROM install and WDSearch OC, then I will reupload the Beta 1a build + Release notes. When testing please: - report errors with USB installs, if any. - check setupapi.log for "unsigned file" errors. - test qfecheck after an upgrade/repair installation - slipstream SP4 in a Windows XP 32-bit environment. Then use nLite/RyanVmi/anything else to integrate drivers, addons, etc. - OOBE startup will delay for about 2 minutes. This is normal and happens due to .NET FW 4.0 NGEN service.

@egrabrych The reason is a kernel exception.

Beta release now available (see first post).

Windows XP SP4 Beta build is being tested at the moment. The build is almost stable - from now on it's adding documentation and testing...

As for the "functionality issues" argument in M$ statement this may be true only with a very limited set of files. For example, an update containing kblchecker.dll (KB2686509) had been released seperately for normal XP and Embedded versions. I can't give you a complete list of such files, however, it's worth find the differences between these 2 KB2686509 updates - we might be able to make more general observations. If there are such updates in the future, the CAT signing method I have presented at RyanVM can be used to create the new update catalog files (after properly porting the patch from the Embedded-only update). As a reminder, the update catalog files are primarily used for SFC protection.

Updated the May 2014 hotfix installers with the latest update.exe patch. I also fixed a bug in the .NET FW 1.1 hotfix: an older version of package installer was used. I upgraded the installer to the latest version. You can download the latest files from my Drive folder.

The method also works in Windows XP Home-Based editions. I tested it on XP Starter. I will update the first post soon. The patched udpates are not a waste of time, we will find them useful if M$ decides to make WU more strict.

@Sebijk Excellent trick. I will test it on Personal SKUs of Windows XP to see if WU works then I'll update the first post. Let's hope that M$ will not add an extra requirement for the EmbeddedNT value. So far it works on MCE/Tablet PC/ Normal Pro SKUs. @ -x- It's easy to suppress these error messages. I will post instructions later.

@den, jaclaz Thanks for your suggestions, I updated the instructions. @Atari800XL You need .NET updates if you install .NET Framework on your system. Note that the .NET 1.1 updates found in my Drive folder have been ported from Windows Server 2003 by den. @Dave-H: I have found the latest (v12.9.5.2) symevent.sys, symevent.cat, symevent.inf files. I can send you these files via PM if you want.

tomasz86 patch is different. To apply my patch execute: ECHO>sfxcab.xsc REPLACE E8 02 BA 02 00 85 C0 75 41 BY E8 02 BA 02 00 31 C0 EB 41 START/WAIT xvi32.exe update.exe /S=sfxcab.xsc modifype update.exe -c DEL sfxcab.xsc

@den Not completely, because when I tested it in VM I was unable to reproduce the issue.

@Den I will reinstall Norton 360 to check for the symevent file. To everyone: By the way, did you have any problems with the new update.exe file? (if you've tested it)

Update.exe 6.3.13.0 or later patch - Brief description From IDA disassembly. The region to be patched is marked in red. Note the ValidateSingleFileSignature routine, it's used to check whether update.inf has been signed by Microsoft. Simply we force it to jump always and not only 'if not zero' to loc_104E033 routine (its address may differ in update.exe binaries created in other languages, but it's easily identified due to the UpdSpOpenInfFileA DLL import it contains). It's easy to understand that the main catalog file of the update is first installed in catroot, then the update.inf hash is comared to the catalog's hash table. In addition, the ValidateSingleFileSignature routine checks whether the catalog file used is signed from Microsoft Windows Component Publisher, by calling another routine (not shown here). Optionally, you can change the test eax, eax line to something more neutral like xor eax, eax (set eax register to 0). Don't forget to repair PE table checksum with tools like modifype; failure to do so may cause unexpected behaviour at runtime. UPDATE: To automatically apply the patch to any update.exe file v6.3.13.0 or later (for any langugage) run these commands:

@Atari800XL I will answer your question, but let's see first if the problem is fixed. Yes they're localized. I will give you a generic approach to patch update.exe.

Yes, I'd be interested to know as well where that later version of symevent that you mention came from. The latest version on the Symantec FTP site is 12.8.6.38, which I installed thanks to submix8c. If there is a later one I would want to install that of course, assuming that it is compatible with XP! A search for version 12.9.5.2 doesn't find any downloads available for it. It's from the latest version of Norton 360. I just tested the update.exe in VM with Norton Antivirus 2003. An older version (11.0.1.1) of symevent.sys works fine with the new update.exe. Here is the file: https://drive.google.com/file/d/0B7k-l_4omFECajNuQms0OGZObXc/edit?usp=sharing Please test it on your system, I've been unable to reproduce your problem so far.

There is a new update.exe I patched. It might fix the Norton issue in older symevent.sys versions. The latest version of symevent.sys (12.9.5.2) has no issues with the update.exe file.

Right now I'm working on the next Alpha build. I'm changing the execution order for some commands in the INF file. You will be able to test this build when it's ready (there many glitches to take care of in different scenarios).

Normally you should get 10 or 11 software updates. Which updates show up? The reason you still get updates is that XP SP4 is not finalised yet. The problem is you get that many of them.

The problem is most likely caused by the patched update.exe file. I was not sure at first but the issue seems to be present in any machine with Norton software installed. I will try to cook up a more "clean" patch which will not cause this memory address conflict. The update.exe file uses the standard IsInfFileTrusted patch. This patch has been used since 2005, when Gurgelmeyer created USP5. But there are other ways to achieve the same result. These patches may not suffer from this problem.

I saw a symevent.sys driver file in the Mini051614-02.dmp crash dump, which is releated to the crash, according to BlueScreenView. (It'[s marked red in the analyser). According to a quick Google search, symevent.sys is a Norton-related driver. I don't have any clue why this driver file is implicated. Maybe it's patched update.exe...

@den It should not be corrected for Windows XP x64 edition: All Windows XP x64 (Version 2003) post-SP2 updates are verified via this registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP Version 2003\SP3