[Dumpy Dooby]

I use InstallShield to preapply the MSTs directly to the MSI files so that shouldn't be a problem. You did give me an idea, though. I'll try copying vs_setup.MSI file to %SystemRoot%\Installer\{GUID HERE}\. Or perhaps even try copying vs_setup.MSI to the installer folder and replacing the MSI that's generated by the installer itself. For good measure, I'll also try putting the MSTs in there too, just in case they're needed.

I have no idea if these tests will work, but I'll see what happens.

Also, thanks for the link to the cleanup tool. I'll try using that, but all of my tests have been on a perfectly clean install. I dunno, though. It might still make a difference. Thanks man.

This post has been edited by Dumpy Dooby: 02 October 2009 - 03:31 PM

[7yler]

@Strel

I'm was running SNM post install (not T-13), and it was 2003 (showing KB951847), XP was ok.

I tried SNM 20090922 this time and I'm having problems with it not installing at all (I am using the RESTRICTED HOTFIXES), so I cant get the logs to you at the moment.

I'm currently really busy, so I will retry later in the week when I get the chance.


EDIT: Just done a quick test on 2003 (XP is ok), and it looks like 20SP2/30SP3/35SP1 are not being installed at all, possibly RESTRICTED HOTFIXES causing the problem. Maybe a RegTweak is causing WU to think it needs KB951847.

Later in the week, I will try WITHOUT any RESTRICTED HOTFIXES. By the way SNM complains if KB971595/KB972251 are used.

This post has been edited by 7yler: 03 October 2009 - 05:07 AM

[YumeYao]

@strel
on the WIC issue:
its update.inf doesn't contain any entry calling spupdsvc.exe. This is also the first time i see such a hotfix with spupdsvc.exe yet doesn't call it.

here is also a simple test to prove it.
environment is xp sp2 chs.
 wictest.7z (5.46K)
Number of downloads: 2

@dumpydooby
I always do a test on perfectly clean system before I confirm all is working.

This post has been edited by YumeYao: 03 October 2009 - 06:20 AM

[7yler]

@Strel

I just done a test with no RESTRICTED HOTFIXES, just the basic patches, and it wont install on Win2003.

When I extracted the files, and run the MSI files from 20/30/35 I get following error.

Attached File(s)

•  Error.JPG (11.91K)
  Number of downloads: 7

[strel]

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.

This post has been edited by strel: 03 October 2009 - 09:01 AM

[skyhacker]

I'm kinda of a newbie here but I had a package made with the previous release with .net 1.1, 2.0 SP2, 3.0 and 3.5, that I integrated fine with nlite with no problems, now I made the same package with the new version and after windows install thw windows update ask's me for KB951847, can someone help with this one

thx in advance

[strel]

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%.

This post has been edited by strel: 05 October 2009 - 11:12 AM

[skyhacker]

I can't find the files you are asking, either in %SYSTEMFOLDER% or %TEMP%, I searched the system for log files and couldn't find it

[DarkShadows]

@strel Hey there. I wonder if you can help me trouble shoot this one. It's a head scratcher...

I downloaded your latest build of SNM Synth and created default packages (no .ini file changes) for each .Net Framework using all related updates currently listed in Microsoft Update (including the Firefox related one), but no language packs. I integrate them into my WinXP Pro SP3 XPCD as follows:

• DNF20.exe - installed from svcpack.inf
  
• DNF30.exe - installed from RunOnceEx
  
• DNF35.exe - installed from RunOnceEx
  
• DNF11.exe - installed from RunOnceEx

NOTE: All packages are fully updated with all their perspective SP and KB updates, I just rename them to shorter generic names.

On VirtualPC, Windows XP Pro volume installs correctly, which it has every time I have ever used your script or the original SNM by Tomcat76.

Today, I was rebuilding a PC with Win XP Home Edition OEM. And RunOnceEx fired off after the first user logged in and it started working as normal. However, when RunOnceEx got down to the .Net Framework 3.5 entry the installer unpacked and installed but the RunOnceEx process just halted afterward. There was no HDD activity, the mouse just sat there and RunOnceEx didn't progress to the next entry. After 30 minutes I pressed the PC reset button and rebooted it. After logging in as the same user again RunOnceEx continued on the next item after the .Net Framework 3.5 entry, which is .Net Framework 1.1. but the .Net Framework 3.5 entry was still listed. Then RunOnceEx completed as did the first user log in.

So I checked Control Panel - Add/Remove Programs and all four .Net Framework installations were listed as expected, despite the process hanging and the forced PC reset. So at this point, I rolled back to my XPCD to the previous .Net packages I created using an earlier SNM Synth build and started over (no other changes to the XPCD). I got exactly the same results.

This time I also downloaded and ran the .NET Framework Setup Verification Tool from Aaron Stebner's WebLog and all four .Net Framework installations checked out okay. So I looked in the %TEMP% folder and I see the unpacked 7zip temp folder with the .Net Framework 3.5 files still inside. I've zipped up all the files your script created in the root of that folder and attached them here.

But I have no clue what is happening or why it would work with Win XP Pro on VPC and not XP Home on a real PC. Any ideas?

Attached File(s)

•  DNF35_SetupFiles.zip (24.78K)
  Number of downloads: 9

[Dumpy Dooby]

^ Did you check to see if there were hanging instances of MsiExec or anything? I'm not sure what Ngen.exe does, but you might consider looking for it as well.

It might also be looking for some sort of user interaction. To check this, rename INSTALL.CMD to INSTALL2.CMD. Create a new INSTALL.CMD with this:

@Echo Off
"%~dp0install2.cmd">>dotNET35SP1.log

That will direct all output from his script to the log file. So if the last line in the log is "Are you sure you want to..." or something like that, then you know why it's hanging.


That's what I'd suggest doing if you want to try troubleshooting it yourself. Otherwise you can wait for Strel and he might have some more useful tips.

[strel]

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.

This post has been edited by strel: 06 October 2009 - 05:28 AM

[DarkShadows]

strel, on Oct 5 2009, 07:09 PM, said:

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?

Since my last post, I attempted installing my XP Home OEM XPCD again, this time with the new .Net packages generated by the most recent version of SNM Synth (again using all .NET Framework updates actually listed in Microsoft Update). This time, not only did the installation hang, but the .NET Framework Setup Verification Tool report shows errors.

FYI, the older SNM Synth .Net installation packages that worked (after resetting the PC in the middle of RunOnceEx) were built by 20090514_SNMsynth.zip. The only other difference between those packages and newer ones is the new ones contain NDP35SP1-KB963707-x86.exe.

Here's a download link to the requested logs: SNM-Synth-Logs.zip. I've also included the log file generated by .NET Framework Setup Verification Tool as well as the temp files generated by your INSTALL.cmd.

Thanks for the help.

[strel]

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.

This post has been edited by strel: 07 October 2009 - 03:02 AM

[Dumpy Dooby]

What if he tried?:

Start "" "[path-to-ngen]\ngen.exe"

Then it won't wait for ngen.exe to finish, but it can still run in the background.

Would that have any negative effects?

[strel]

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

This post has been edited by strel: 07 October 2009 - 02:35 AM

[DarkShadows]

strel
I re-integrated an XPCD for Windows XP Home (OEM) and Windows XP Pro (Volume), both installing .Net Framework packages built with the latest SNM Syth build. Both install the .Net Framework packages from svcpack.inf in this order:

• DNF20.exe
  
• DNF30.exe
  
• DNF35.exe
  
• DNF11.exe

I installed the Windows XP Home to the actual PC, and Windows XP Pro to Virtual PC, and in both cases Windows Setup never hangs. It is still puzzling about why RunOnceEX would just hang, but it looks like the issue is safely worked around when installing from svcpack.inf (which I would rather install from anyway).

Now in both installations, the .NET Framework Setup Verification Tool still shows several errors of files missing. However, I can see now that they are files for languages other than English (all are named with 4-digit language codes and 1033, which is English is not reported as missing). Since everyone I support speaks only English, I do not install any language packs. So I'm guessing that the errors reported by this tool are not as big of a deal as I first thought.

Again, thanks for your help.

-DS

[strel]

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.

This post has been edited by strel: 07 October 2009 - 02:35 AM

[Raoul90]

My installer is working fine again.

[strel]

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.

[Dumpy Dooby]

[edit]
Let me preface this post by saying that it has nothing to do with your program. I'm merely using this thread as a public place to ask you a question, and I didn't think my question warranted a thread all to itself.
[/edit]

Hey strel, do you know if there is an easy way to override the rollback setting for the .NET Frameworks? The reason I ask is because the installation time could be decreased tremendously if we could get FASTOEM to work with these (I'd recommend making it conditioned on whether the user is running the installation during a system setup, i.e., from svcpack or first boot; on a live installation, you don't want to use FASTOEM). FASTOEM forces the installation routine to disable the creation of a rollback script. The .NET Frameworks look for the rollback script, and if it isn't there, they exit so as not to have a broken installation. Obviously there would be no such broken installation if it's being run from SVCPACK and the like. Additionally, disabling the rollback script also disables "commit custom actions," which is why .NET Frameworks are freaking out.

If there is a way to re-enable rollbacking via an MST or something, that would be wonderful.

These are the public properties that I set:

ADDEPLOY=1 ARPSYSTEMCOMPONENT=0 ARPNOMODIFY=0 ARPNOREPAIR=0 REBOOT=ReallySuppress FASTOEM=1 ALLUSERS=1 DISABLEROLLBACK=0 CURRENTDIRECTORY="C:\Test\Runtimes\dotNET20\" MEDIAPACKAGEPATH="C:\Test\Runtimes\dotNET20\" ROOTDRIVE=C:\

As you can see, I tried overriding FASTOEM's preference to disable the rollback script by manually disabling the DISABLEROLLBACK property, but that didn't work because FASTOEM is always processed last in the public property check.


In my above example, I was trying to do it with .NET Framework. As expected, the installer exited with an error, "You must enable rollback to continue with setup."


So any thoughts on this one? I'm thinking it's impossible because FASTOEM moves files instead of copying them, which means that a rollback script would be next to impossible to manage. But if you have any suggestions, I'm all ears.

This post has been edited by Dumpy Dooby: 09 October 2009 - 05:07 PM