strel

EDIT: About encoding maybe you're wondering if I changed something on the .msi files to apply the transforms or so. That's not the case. For the next version some tricky operations changing encoding setting on the .msi files will be done to apply some transforms to langpacks, but encoding setting will be reverted inmediately after this. So I don't think this method is causing any encoding problems for the version you're using (nor for the next one), if any, may be there before. Nevertheless, I'm not a guru of anything. You should try in appdeploy.com message boards, sure there you'll get more detailed information about this, if any.

Are you using the latest windows installer for your OS? I'm reading the 3.1 version solves an issue about logging null characters used in a registry value marker or a service dependency.

AGP apperture size setting stablishes both: - the video card memory range -not dedicated to texture storage- with no adress translation and faster access - the rest of the memory range -dedicated to texture storage- with adress translation and slower access. Doesn't seems to be necessary a high setting, unless you're not using an texture instensive application.

I've tried to use this property without success before, but I may be mistaken. Don't forget /qn switch. Don't know if it would make a difference but you can try modifying it as system policy (REG_DWORD values): HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer\DisableRollback HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer\DisableRollback You can try to do it too with an .mst, setting the the property with a custom action of the required type, and inserting an instance of the custom action in the InstallExecuteSequence table, search a verbosity logfile for DISABLEROLLBACK property before sequencing, to get an idea of what position to use in the sequence. Anyway I'm dubious about the possibility of success. Tell us your progress.

skyhacker Sorry, I've just read your PM now. I'm confused you say you integrated an AIO 20090922 add-on with nLite. You say all frameworks got installed, but KB951847 is still listed in win/ms update. But you say too, no logs are present in %SYSTEMROOT% (20090922 bug when installed from T-13/nLite) nor in %TEMP%, and no framework version appear in add/remove programs. I'm wondering if actualy you got installed any framework at all. Can you check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{VARIOUS GUID FOLDERS}\DisplayName values for .NET versions installed? If there's frameworks installed you can use the command in the UninstallString value, on a command line to uninstall each framework or langpack; and then reinstall manually with SNMsynth installer (you'll find it in i386\SVCPACK folder in your windows source, or you can extract it from the nLite add-on), to get the install logs in %TEMP% and check what's happening with KB951847FIX. Raoul90 Glad to hear that.

I always keep languages to be able to open any web page in any language correctly. I don't see what could be causing your network problems, although your removal list seems too short to me for a 180 MB reduced source, besides, no services settings and tweaks are applied. May you be trimming a previously nlited source so not all components removed appear in the list?

I don't think they are language package files, but generic english installer localization files. They are removed intentionally, so don't worry. And thx for the information.

Then it won't wait to idle time, and there should not be negative effects, as neither there are not when you install .NET from original installers, it's just a compiling process, but it will slow down other tasks running, that's what this script avoids. But in your example you should run ngen executequeueditems

I don't see anything strange in the logs. 3.5 SP1 installs correctly, and you reboot 10 minutes after runonceex hangs and 1.1 install takes effect. What's failing should be after 3.5 install command in its INSTALL.CMD file, and the best candidate is ngen as Dumpy Dooby was suspecting, I don't think the rest of the commands are stopping execution in this manner. Don't know what's failing, but I have to suppose it has to do with something in your xp home source (the way you modified it or not) with 3.5, because ngen (if that's what's failing) is not hanging RunOnceEx when it is ran from 3.0 SNMsynth installer. If ngen is the culprit, this doesn't mean it is not finishing its work, if it didn't finish it before reboot, it will after reboot on idle time. You should check event viewer to see if any errors was produced by ngen or anything apart of .NET installing. If the error was caused by ngen, you can try to avoid this error by removing ngen command from 3.5 INSTALL.CMD script, this will cause the default .NET behavior of running it later at idle time, and surely then it won't break anything. Or you can use RunOnce or GUIRunOnce instead of RunOnceEx to still run it at logon, probably it's something with RunOnceEx and not with install time. And anyway, now you can too install all frameworks during GUI-setup as new SNMsynth versions managed to workaround the errors that 3.0 was producing in event viewer (actually it didn't harm anything) when installed at that time, surely it'll can finish correctly.

skyhacker Don't know if you read my PM, it would be of great value to check the install logs for 2.0 3.0 and 3.5 and its related langpacks (which install ad-hoc KB951847FIX), if you don't find them, better you uninstall .NET and use the installer to reinstall them and generate the logs. As you probably used an all in one 1.1+2.0+3.0+3.5 add-on for nlite, you'll find the installer in i386\SVCPACK folder of your nlited source, or you can extract it from the add-on. Uninstall all .NET framework versions, and then execute the installer. %TEMP%\NETFX##install.log and %TEMP%\NETFX##LNGinstall.log files should be created. Logs for 2.0, 3.0 and 3.5 and its langpacks should reveal if KB951847 fixes have been correctly installed. Can you attach them? Are you installing over windows 2003? DarkShadows You can check %TEMP%\NETFX35install.log, if you used installers made with later versions, otherwise you can search for the related %TEMP%\MSI*.log by date. Can you attach it? DumpyDooby ngen pre-compiles .NET libraries to be used by .NET software, in the case of this script, not waiting to idle time to complete this process.

Seems like the same problem as 7yler, can you attach your NETFX##install.log files for 2.0 3.0 and 3.5? Due to another bug if you installed from T-13 (nlite add-on for example) you'll find them in %SYSTEMFOLDER%, instead of %TEMP%.

Probably you ran it without ADDEPLOY=1 property, the script uses. Maybe you have some framework version installed inadvertedly (apart of 1.1) blocking your install. I'd check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{VARIOUS GUID FOLDERS}\DisplayName values for .NET versions installed.

You can only do this for user accounts without password: - Press win+R and execute gpedit.msc - Go to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Policies\ - Change value of setting "Account: Limit local account use of blank passwords to console logon only", to Disable. I don't know if this eliminates the logon dialog, but you wouldn't need the password.

Try this: - Press win+R and execute diskmgmt.msc - Go to Actions\Rescan Disks.

YumeYao You now say WIC don't run spupdsvc.exe but on post #351, you don't say that, and WIC has this file in its folder, I think you were right first time. Dumpy Dooby I saw your new error in the YumeYao's method thread. Probably you cannot uninstall because all installer related files used on install are not on %SYSTEMROOT%\Installer folder, for some reason, maybe permissions, don't know why, they should be there. Probably you're getting this new error because, as it seems, the uninstall process are not finding required files, probably .mst files in %SYSTEMROOT%\Installer\{GUID} folder where GUID is the GUID of the component to uninstall, as you said you found the .msi (I'd check if it is the same filename as the uninstall regkey); so it is searching them in the original install folder, that is the temporal folder where the SNMsynth installer was extracted on install, now deleted as it seems. You can obtain GUID from the 3.5 SP1 uninstall regkey you mentioned "in the backgroud" on your YumeYao's method thread post. Once you get the GUID, you can create the GUID folder if it's not there, and copy the required .mst files, you'll find them inside the SNMsynth installer you used (you can check the script to see which of them were effectively used by 3.5 SP1 install process, because if it is a merged installer, where other framework versions reside, there could be .mst files not used by 3.5 SP1, though I don't think it is going to harm if you copy to GUID folder, extra .mst files). Once you have the required .mst files in the GUID folder and .msi in the Installer folder, uninstall should work. Hopefully for the next version, will be no problems if .mst files are not in Installer folder because they will be preapplied to .msi. But if for some reason all this doesn't work, because maybe your install got corrupted for some reason with all this trials (not so rare) you still can use: .NET FX Cleanup Tool. 7yler Don't know if you read it, can you attach your %TEMP%\NETFX##install.log (or in c:\ if you used SNMsynth installers from T-13, there's still a bug with that) files for 2.0 3.0 and 3.5 versions, you're getting on the problematic 2003 install (showing KB951847)?

2 YumeYao. About SSIP, don't know what I was thinking, it's pretty obvious what it has to do, and is a better solution than the one I was using. I'll use it. Thx. About cached installer files renaming, I was introducing some confusion. You're right, cached installers are not getting actually the file names I'm using for renaming them in the script, when installed from redistributable package, nor when installed from KB951847 in a test I just finished now, so it seems renaming is not needed. Although I'm confused, and wondering: but if you're right, why did I include this renaming in the script?, and my answer is I'm sure at the time I included renaming I was getting always the same file names for cached files when installed from KB951847, and that's the reason why renaming is in the script. So I've compared dates when I included renaming, with last modification date for KB951847, and the framework installer subcomponent therein, has a later last modification date. So I think cached installers file names has changed, from fixed to aleatory, for KB951847 in the meantime, hence my confusion. I'm changing my mind about restoring DW regkey. Reason why it is removed from registry is that, as stated by Aaron Stebner, creator of this workaround, 2.0 framework installer (office11 debugger subcomponent supposedly) doesn't have permissions to write to it during setup. In addition he don't restore later this regkey, so I have to suppose it will be written when needed later. I have no reason to think office debugger installed from office 2k3 during setup (thing I've never tried) wouldn't have the same restrictions, and problems. 2 Dumpy Dooby You're right, typo I introduced somehow. I was not aware of it. Thx. And about your problems uninstalling sure they are caused by what's answered in YumeYao's method thread to this question. 2 7yler Don't know what's happening to you, for now. Always try to use latest version to check problems are still there, but if they are, and not on previous versions, now you have many previous versions ready to download in the changelog section, so you can test. EDIT: Can you post NETFX##install.log files for 2.0 3.0 and 3.5 frameworks you should have in %TEMP% folder? 2 Raoul90 So I suppose KB963676 restricted hotfix didn't solve your problems.

Hi YumeYao. I had no time last days to make tests I'm beginning now. About your proposals: 1. I'm using your fixed method to apply new update shell to WIC and XPS. You say "safer" to only use the update shell from this hotfix, probably, but is there something I should know? 2. Good point and very good point. EDIT: This last one not needed, see bellow. 3 & 4: - Well I'm splitting NETWUFIXES but I'm making it even more atomized, and scripts will not be touched. I'm trying to pre-apply all transforms also to avoid .mst extra files in the installer packages and later cached when installed. This means, that 3.0 langpack extra values you added methodicly (InstallSuccess and Version, resembling 2.0 langpack values), but not checked by win/ms update, will not be included. It can be expected update system will keep cheking the same values. And you're not applying those 3.0 extra values in the right regkey with your VBS scripts. Check Registry table of a 3.0 langpack installer to compare. About INSTALL.CMD script. (I only checked .doc version suppose it's equal to .docx) - About renaming the cached installer, this lines will be kept, as well as VBS ones. As I said before, original installers always use same file names for cached installers, and while you pointed right the update system don't check them and that you can manage new names, maybe other software could rely on them, and I'd like to keep as much as possible things untouched to avoid potential problems (I'm not referring with this to .msi installers and fixes applied obviously) EDIT: This is not correct, see below. - I don't know where this %VERBOSITYHOTFIX% come from, but I'll take it as you're referring to verbosity value for the installer. - I'm trying to make the INSTALL.CMD to check whether it is executing on GUI mode setup by detecting NetworkService profile folder, and thus managing issues around this, like %TEMP%. - About DNFWIN#.TXT ARP entries removal, you don't see the difference because your OS has an up to date windows installer 4.5. - About delaying 3.0 subcomponents install to logon, I'm using RunOnceEx entries instead of a RunOnce script, thus I'm able too to rise up its related dialog about what's installing, executing it first before any other software installing from there (unless rare regkey names applied), but only in case verbosity is not silent. And I don't get why are you relying on SSIP setting to switch to delayed installing. I understood from what you told, both XPS and WIC were executing spupdsvc.exe in every circumstance, so what SSIP has to do with this? I suppose you're not installing WIC, hence delaying it because your script is for XP SP3. I'm beggining my tests now, hope all the above can be achieved.

Is this value getting 0 setting? If not set it. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}\SystemComponent And for the error you pointed on SNMsynth, thx, I was aware of it and a couple of minor bugs also, will be fixed on next version.

Apparently the extraction of the .msp files from hotfixes, could be failing. But this is not my case so I am confused. Are you using the latest 7za.exe version (link in the Instructions section)? Try with it. Tell us your experiences.

I repeated the process in a new folder with the inputs and settings you pointed before and 20090922 packet files and no extra files, running the script by double clicking it, and again couldn't recreate it. Try this: open _SNMsynth.cmd (20090922) and in the first lines of the script substitute this line: @ECHO OFF with this one: @ECHO ON Then open a command line in the folder you're working on, and execute: _SNMsynth > process.log 2>&1 When it finish, post process.log attaching it, for us to see it.

Don't forget to set BIOS in scan mode for IDE drives on boot. Check IDE buses are not deactivated from BIOS. Check if the drives power up when you switch on. Check the drives are properlly atached to the power supply, specially if you've done many drives plug/unplug operations with this power supply in the past, check cables have no damage in the junction with connector, even check the connectors (4 female in each one) and try to narrow slightly each one carefully by inserting a small flat head screwdriver between plastic and metal and applying a bit of presure with patience not to damage it. Check master/slave configuration with the jumpers, in the same cable 1 drive has to be master and the other slave. Be careful, some drives has a jumper master settin for a single drive master with no slave drive on a cable. Check your IDE cables are 80 wires cables (unless your IDE HDD are so old that don't support UDMA-66 (ATA 5) or higher mode) though this only affects speed and not detection. Put the master device in the connector at the end of the cable and the slave in the intermediate connector. Check IDE cable for defects specially in the junction of cable with the connectors. Try with other IDE cables. If the cables are large, try with shorter ones. Try putting the drive in another cable or with another drive in the same cable or with another jumper setting/position in cable. Dont' use drives larger that 137 GB for BIOS not supporting 48-bit LBA addressing (though this shouldn't be a problem for the BIOS to detect it, just to map the drive beyond that limit) Observe if drive makes strange noises when operating, it may be failing.

Read the KB article related to this KB963676 restricted hotfix. This article pretty resembles to some descriptions I read around about this error, and don't mention the specific fatal execution engine error. I'd give it a try. EDIT: In fact this is solving the problem.

This is the only official info I could find about that problem, unfortunately the hotfix associated is only for .NET 2.0 SP0. By the way, this seems to be an extended problem raising with a variety of different applications and .NET 2.0, so it seems somewhat undefined. If you do a google search you'll find people trying to debug the specific application causing the problem. Are you installing any .NET application on the same go?

Not my case. For 3.5 SP1 you can change the SystemComponent settign if this is what's causing the problem. For the rest of the versions don't know what could be the problem.

Many previous versions have been uploaded, you'll find the links in the changelog section. But for your case, what's failing has not changed since it was released. The log indicates KB963707FIX.mst transform file is having problems to get applied to the vs_setup.msi 3.5 SP1 framework install file. The transform file consist ONLY in changing one parameter of 1 line of the install file thus changing the place where the installer will search for the Firefox add-on to its real location (a bug that arises after applying KB963707 to 3.5 SP1 framework). But aparently, this line is not on your install file. And I still don't know exactly why this happens to you, I couldn't reproduce it, and apparently the building process has ended right with no errors. Can you try again with a clean work folder from scratch? Strange, I'll keep searching.