Zorba the Geek

Thanks for this clever tip that I have never read anywhere else. I tried it and it works! Here is my solution using the integrator. I have discovered that setup reads the paths in the DestinationDirs section of the installation INFs of Windows components and registers these folders somewhere as protected. It is not possible to remove these INFs from the source because they are signed by nt5inf.cat, and their absence would cause setup to be aborted half way through. My solution is to over-write these INFs with a dummy INF that contains a few lines in the Version section like this example [Version] Signature= "$Windows NT$" LayoutFile=layout.inf [DefaultInstall] and delete the INF late in the setup. I have tried this with Speech Support, Movie Maker, and internet Connection Wizard and it seems to work. Here is the latest addon that incorporates this technique. File: SpeechSupport_DeleteAddon.7z (Dropbox) File: SpeechSupport_DeleteAddon.7z (Google Drive) File: SpeechSupport_DeleteAddon.7z (4Shared) MD5: 86FF6CEE0B6E50FF0DE292B9CC9E6908 SHA1: 995DC283DCC585AB1F175933544AB621CCED46C4 Size: 339 KB Build date: 13/09/2025

Can anyone suggest a solution to the problem of orphan folders left behind when using the addons to remove Windows Components. I have empty folders in my system including Outlook Express, netmeeting, msagent, and usmt. These folders are locked by either Winlogon.exe or Explorer, or both, and if you use a utility like Unlocker to remove the handle to them and delete them they are recreated during boot time. Ideally one would be able to hack a Windows DLL that maps the paths to these protected folders, but I am not expert enough to do this. The only other solution I can think of is to execute an unlocking utility using the registry Run key so that the folders are deleted at each boot time. I know of three of these utilities that support commandline usage. Iobit Unlocker deletes files and folders fully, but shows a dialogue box saying "The operation completed successfully", because it does not have a silent switch. Unlocker moves deleted files to the Recycle Bin which rapidly fills up with empty folders. Lockhunter will delete files and folders fully, but it will not execute from the HKLM or HKCU Run key for some reason.

A post install uninstallation of Automatic Updates using a batch file is problematic because wuapi.dll, Wuauserv.dll and wups2.dll are locked by winlogon.exe and cannot be easily deleted in a batch file, although it may be possible using the Sysinternals handle.exe utility. That leaves the only other option of deleting them during a reboot by adding entries in the PendingFileRenameOperations value under thew Session Manager key. This cannot be done with reg.exe because the entries need to be modified as binary data. My first attempt at a resolution of this problem involved importing a .reg file into the registry, but this ,reg file is specific to a drive letter, so my dual boot system would require two versions of the update for the C: and D: drive. Since then I have been able to include Sysinternal movefile.exe to make the required registry entries. All that is required is to specify the path of the source file and make the destination path "" to delete the source. Here is my new Automatic Updates addon including movefile. File: AutomaticUpdates_DeleteAddon.7z (Dropbox) File: AutomaticUpdates_DeleteAddon.7z (Google Drive) File: AutomaticUpdates_DeleteAddon.7z (4Shared) MD5: F8B000B410F2BB9486B4743611780693 SHA-1: C1C1BAF8F85F3E8BF0B459A61C6DBF80F4992195 Size: 60 KB Build date: 26/08/2026

It seems to me that you have added items from Automatic Updates in the preset Last Session (2025.05.14).ini so that they are deleted from the source the same as the ObsoleteFiles directive does in the integrator. I note that wuapi.dll, wups.dll, wuaueng1.dll and wuauser.dll have not been added, and thus the Automatic Updates service will still be present in the final install. Also if wuweb.dll is removed from the source it means that it cannot be registered by syssetup.dll thus leading to an error message in setuperr.log and setuplog.txt. The batch file in my addon on the other hand does a thorough job of eliminating Automatic updates leaving no entries in setuperr.log. There must be a good reason why the removal of Automatic Updates is not an option in nLite. As far as I can tell the Automatic Updates files are not dependencies of a module that needs to be registered, so I assume that Automatic Updates must be required during Windows installation. It is a long time since I did an attended install, but I seem to remember that you are given the option of updating the setup files which might require automatic updates. Also the are no instructions for installing the Automatic Updates service in the inf files in the source that could be deleted, meaning that only a post install uninstallation of the service is possible.

Attempting to remove automatic updates by deleting source files caused the framedyn,dll and srclient.dll not found error at the end of the Windows setup. I cannot see entries in entries_del_shortcuts.ini for removing automatic updates. Certain folders of removed Windows components like msagent under the WINDOWS folder seem impossible to remove. I removed it's entry from txtsetup.sif and for good measure removed it with a batch file, but it reappears. When I attempt to remove it from the commandline I receive this output: > rd /s msagent msagent, Are you sure (Y/N)? y msagent\intl - The process cannot access the file because it is being used by an other process. The process cannot access the file because it is being used by another process. Unlocker shows that the folder is locked by winlogon.exe, as is the empty Outlook Express folder. I can use Unlocker to remove the lock by winlogon.exe and delete the folder, but it reappears after I reboot. I also tried adding an entry for the msagent folder in the PendingFileRenameOperations value to delete it after a reboot, but that does not work. I might try removing the entry for msagent in the DestinationDirs section of intl.inf in the addon, but I doubt that would make a difference. I see that the msagent section of your addon includes this line which indicates that nhelper,exe is used to permanently remove the msagent folder: If so why are you deleting this line from nlite.inf? NLITE.INF|HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce","nlite_post_11",0x00020000,"nhelper rd /q /s """"%SystemRoot%\msagent"""""<NEXT>||1

What you demonstrate here is the same as the instructions in the Defining Entries document, so what I must have done wrong is omit the leading space of the second line. Here is a typical entry in hivesys.inf HKLM,"SYSTEM\CurrentControlSet\Control\Nls\MUILanguages\RCV2\guitrn.dll","0",0x00030001,\ 52,04,28,0a,01,00,05,00,00,00,28,0a,01,00,05,00 and here is the correct entry in my entries.ini file; HIVESYS.INF|HKLM,"SYSTEM\CurrentControlSet\Control\Nls\MUILanguages\RCV2\guitrn.dll","0",0x00030001,\<NEXT> 52,04,28,0a,01,00,05,00,00,00,28,0a,01,00,05,00<NEXT>||1 As you can see there are five spaces before the beginning of the second line. The deletion now works.

I have made a new update pack to remove Automatic Updates. As Automatic Updates is required for the entire installation of Windows I have had to remove it after installation using a batch file called by an entry in the HKCU RunOnce key which means that you have to set up a user account during setup. There are two versions of this adddon depending if Windows is to be installed on drve C or drive D. I am not a Windows command scripting expert, but it ought to be possible to write au.bat so that it detects the the drive letter of the partition on which Windows is installed using an IF EXIST command maybe in conjunction with the GO TO command and imports the appropriate reg file to delete locked files during the next reboot . This would remove the necessity for two versions of the addon. If anyone has an idea how this could be done please let us know. File: AutomaticUpdates_DeleteAddon_C.7z (Dropbox) File: AutomaticUpdates_DeleteAddon_C.7z (Google Drive) File: AutomaticUpdates_DeleteAddon_C.7z (4Shared) MD5: 24172B42A960D82CC7D22DE689140E1 SHA-1: C5AE2C43B06C2741AB0442EEFB8376CD1A85406E Size: 2 KB Build date: 16/08/2026 File: AutomaticUpdates_DeleteAddon_D.7z (Dropbox) File: AutomaticUpdates_DeleteAddon_D.7z (Google Drive) File: AutomaticUpdates_DeleteAddon_D.7z (4Shared) MD5: E2B97417D9062791D50CDDAC02EB043A SHA-1: CB1A81E2C8DFEC8A870025FC6F429497E9E30D8F Size: 2 KB Build date: 16/08/2026

I have finished a second version of the Obsolete Drivers Removal addon which has had rigorous checking to ensure that no essential drivers installed during setup are removed. I have also retained legacy drivers required bu VirtualPC and Virtualbox. The Vmare Player and Workstation install their own drivers rather than use those in the Windows installation. I have ceased to use the Harkaz syssetup.dll patch because it prevents the %OEM% folder from being fully processed. File: Drivers_Removal_V2_Addon.7z (Dropbox) File: Drivers_Removal_V2_Addon.7z (Google Drive) File: Drivers_Removal_V2_Addon.7z (4Shared) MD5: 8173FA7A1381AA0B0ABAD59D19C1753B SHA-1: 484DDDD00789191657720797919359EC67F285FC SHA-256: 534C363B6578B341BACD69BFCC273D6E217E86C15A3823CAA6B9753F658F9BB6 Release date: 22/06/2025 Size: 376 KB

Thanks for bringing the errors to my attention. In particular txtsetup.inf was a blooper that I should have spotted before releasing the addon. Of course removing entry 52 from WinntDirectories in txtsetup.sif should make a post install deletion of the msagent folder unnecessary. However, these folders for Windows components seem to be impossible to remove because they are locked by winlogon.exe. There is an Obsolete_Entries section shown in the RyanVM topic Defining Entries.ini. It's description is "This will delete the entries from dosnet.inf and txtsetup.sif that correspond to file names". There should not be a need to include this section with Obsolete_Files which is supposed to delete entries from txtsetup.sif and dosnet.inf. My investigation revealed that Obsolete_Files does not remove lines from dosnet.inf and txtsetup.sif, but rather marks these lines to be skipped during setup. I have also discovered that Obsolete_Files does not always do this as intended and file copying is halted with a message that a file cannot be found. I now no longer include all the file names in Obsolete_Files with the underscore to denote the cabbed version in the i386 folder I tried doing what you recommended for deleting double lines from HIVESYS.INF, but I could not get it to work. My conclusion is that the <NEXT> tag in ExtraFileEdits is only intended for the revised entry and not for the entry they replace. AGT.HLP.LGFiles.Arabic|INTL.INF should have been entered as AGT.HLP.LGFiles.Arabic. Another blooper, but not as bad as the first one. This could have happened because of a careless use of the find and replace function in a text editor. Sometimes if you click Replace All things are replaced that you don't want to be replaced. One possible solution is to mark the replaced text under Notepad++ so that you can see at a glance what has been replaced. There are no trailing spaces in the line including AGT.HLP.LGFiles.Arabic, but there are trailing spaces elsewhere such as INTL.INF|AGT.DLL.LGFiles.Arabic = 10,msagent\intl||1. I always include the spaces as they are on the original line just to be on the safe side, although it probably makes no difference.

I wonder if people could share their experiences of getting port forwarding to work under OpenVPN. First I would like to emphasize that port forwarding in a router using the usual rules does not work under OpenVPN and attempts to make it work using iptables to manipulate the routing table under DD-WRT, for instance, will probably reveal you IP address which defeats the whole purpose of using a public VPN. I have finally succeeded in getting port forwarding to work using PureVPN after they revamped their VPN servers and provided a number of servers dedicated to port forwarding. You have to buy a port forwarding addon in your members area of their website, and then obtain the appropriate OpenVPN config files from the Manual Configuration section of your members area. The selection of config files can be filtered by various types including QR (Quantum Resistant), P2P, OBF (Obfuscation*), and PF (Port Forwarding). P2P is basically port forwarding by servers in countries with permissive policies about file sharing. There is no need to configure NAT port forwarding in your router, but you do have to open this port in the firewall. The problem with this is that the TAP Windows Adapter is assigned a new IP address by the OpenVPN server every time you log in so you have to enter a probable range of IP addresses from the pool reserved by the server. I monitored the IP addresses assigned to my TAP Windows Adapter by the Netherlands server and entered a range of destination addresses in the firewall between 172.111.247.1 - 172.111.247.224. I use the PFPortChecker tool to verify that the port is open. *Obfuscation masks VPN traffic so that it looks like regular traffic and stays hidden from anybody trying to detect it.

Deleted

After some experimentation I have concluded that this problem is caused by data corruption at one of the stages before Windows is installed in a virtual machine. Repeating all these stages for my addon resolved the problem. Here are the stages that need to be repeated: copy contents of INF and INI files in addon/update pack to Notepad and save them from there Build new 7z or CAB archive Copy Windows source from from ISO Use Poweriso or similar to build the ISO rather than the built in ISO maker in the integrator.

I am one of three people that I know of who are still creating update packs and addons for Windows XP, and the framedyn.dll/srclient.dll not found error is a recurring problem during the development of my addons that I have never been able to get to the bottom of. When I do make changes that fix the problem I cannot remember what I did to make it go away. According to setuperr.log srclient.dll could not be registered because a specified module could not be found. This means that there is a missing dependency, which in this case is framedyn.dll. In fact framedyn.dll has not been copied to System32 for some reason In txtsetup.sif framedyn has not been assigned a destination directory which means that it's destination is defined in an INF file, but I have searched all the XP INF files using Notepad++ and it is not there, so what controls it's copying to System32 is a real mystery. Also msjava.dll is missing in the dependency tree, but it is not included in I386 or a standard XP installation. The same issues apply to dgnet.dll not being registered. eventcls.dll and swprv.dll were not registered and the only missing dependency is the non existent msjava.dll. According to setuperr.log mofcomp.exe could not be registered and investigation shows that it is not present in the wbem folder. I have received exactly the same setuperr.log entries multiple times during the development of various addons with the same missing shortcuts and missing wbem modules, which suggests that there is a single cause each time.

All I can see in your screenshot is a switch for automatic definitions updates, but there ought to be a switch for automatic program components updates. I opened a ticket with Adlice and this is the latest reply I have received