MSFN Forums > Silent .NET Maker synthesized 20091105

Full Version: Silent .NET Maker synthesized 20091105 - W2K/XP/2K3 x86

MSFN Forums > Unattended Windows Discussion & Support > Application Installs

Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12

YumeYao

Sep 20 2009, 06:27 AM

T-13(svcpack.inf) installation behavior suggestion:

make any windows hotfix delayed, such as KB971276(or XPS Printer), WIC, XPS-LNG. This is because spupdsvc.exe, which is executed by them, will take effect on those actions that are planned after reboot(or here specific, first logon to desktop). This issue can be serious in quite a large scale of customed XP/2k3 installations.

so, at T-13, you can copy them to some temp folder, and then write a cmd file by echo>>SOMEWHERE\DNFstub.cmd, the content may looks like:

CODE

Start /wait SOMEWHERE\(WIC, XPS, XPS-LNG)\update\update.exe /quiet(or /passive) /nobackup /norestart
rd (WIC, XPS, XPS-LNG) /s /q
del %~f0

Then add this cmd to RunOnce(HKLM\software\microsoft\windows\currentversion\runonce).

maybe a vbs is better but i'm not able to write a vbs without examples or documents, so there is no example. The pros of a vbs is it won't show up a black box. But I'm not sure whether a vbs can delete itself like a cmd does.

Additionally, you can apply .NET 3.0 font cache fix MST only when it's at T-13.

Cheers.

EDIT: I was too fast to make this post. Let me ensure that .NET installations(msi) themselves don't break the delayed action of windows.
EDIT: ok, seems not.

YumeYao

Sep 20 2009, 08:06 AM

about blocking strategy:
I choose always block all language packs:
.NET 2.0 install ---------> Blockalllp.vbs BlockKB951847.vbs BlockPT-BR.vbs(on PT-BR system)
.NET 3.0 install ---------> do nothing
.NET 3.5 install ---------> do nothing
.NET 3.5 uninstall ---------> reblock KB951847 BlockKB951847.vbs
.NET 3.0 uninstall ---------> reblock KB951847 BlockKB951847.vbs
.NET 2.0 uninstall ---------> remove all blockings, but keep a language pack registry entries if it's really installed. Blockall_Undo.vbs
.NET 2.0 LP uninstall ---------> reblock .NET 2.0 LP if .NET 2.0 is installed. Blockalllp.vbs
.NET 3.5 LP uninstall ---------> reblock KB951847(LP) if .NET 2.0 is installed. Blockalllp.vbs

PT-BR system checking is not included in the vbs.(same as yours)
All other conditions are included in vbs.
Click to view attachment
I'm not very familair with vbs, so please review them.

EDIT: I suggest you make 3 sperate msts.
one for .NET 2.0 (Blockalllp.vbs BlockKB951847.vbs BlockPT-BR.vbs for installing, Blockall_Undo.vbs BlockPT-BR_Undo.vbs for uninstalling)
one for .NET 3.0 and .NET 3.5 (BlockKB951847.vbs for uninstalling)
one for .NET 2.0 LP and .NET 3.5 LP (Blockalllp.vbs for uninstalling)

strel

Sep 20 2009, 08:34 AM

This is the final file set, unless errors detected, what's possible though I browse all them 2 or 3 times:
UPDATED 2009 09 21 16:18 UTC : Updated with changes proposed in the next post.
If anybody find and error, specially in 3.5/3.5 SP1 languages slimming files, please report.

REMOVED, go to the first post to get and donwload the script packet to get them

YumeYao

Sep 20 2009, 08:52 AM

wow, hard work.

I only viewed .NET 2.0 SP2, .NET 3.5 SP1 and .NET 3.5 SP1_cn.

Nothing serious, only if you like, you can make this cleaner.
Click to view attachment

0d14r3

Sep 20 2009, 10:02 AM

2 strel
No mensages at building installers, NETWUFIXES.mst is in the same forlder as INSTALL.cmd but dont found HKLM\SOFTWARE\Microsoft\DevDiv\URT\Servicing\1.1\RED\1046\Install
I have exported this URT reg entries

CODE

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\URT]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\URT\Servicing]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\URT\Servicing\2.0]
"SP"=dword:00000002
"SPIndex"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\URT\Servicing\2.0\STD]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\URT\Servicing\2.0\STD\1033]
"Install"=dword:00000001
"InstallerType"="MSI"
"SP"=dword:00000002
"SPIndex"=dword:00000001
"SPName"="SP2"

strel

Sep 20 2009, 10:33 AM

0d14r3

Can you please try to use the previous copy of NETWUFIXES.mst with the new installer?. In other words, uninstall 2.0 SP2 and its langpack, extract the new installer, substitute the copy of NETWUFIXES.mst with the one last modified 2009 07 30, run INSTALL.cmd, and last check the reg value I told you above. This way we can discard or not an error in the fixes file. But do this with an installer that don't include 3.5. I suppose you have the outdated copy of the fixes file, I can send you one if not.

Thx

strel

Sep 20 2009, 01:19 PM

QUOTE (YumeYao @ Sep 20 2009, 02:27 PM)

make any windows hotfix delayed, such as KB971276(or XPS Printer), WIC, XPS-LNG. This is because spupdsvc.exe, which is executed by them, will take effect on those actions that are planned after reboot(or here specific, first logon to desktop). This issue can be serious in quite a large scale of customed XP/2k3 installations.

What does this mean? First, I'm looking for info about this file but I don't get light, I understand that this file triggers an update check on reboot, right? I think you're meaning that this check is made only over new (updatable) components installed, but only if this process is called. And it seems you're saying that all possible updatable components that install before logon, among the wide load of hotfixes and software someone could use in his unattended project, are not calling spupdsvc.exe except those you name. This is what I don't get, is that correct?

QUOTE (YumeYao @ Sep 20 2009, 02:27 PM)

Additionally, you can apply .NET 3.0 font cache fix MST only when it's at T-13.

I don't get this neither. This fix executes everytime SNMsynth 3.0 SP2 is installed/uninstalled under any circumstance, I think.

0d14r3

Sep 20 2009, 03:16 PM

2 strel
The langpack to 2.0 sp2 is not installed.
I try remove 2.0 sp2 and ocurr this error:

CODE

Microsoft .NET Framework 2.0 Service Pack 2 cannot be uninstalled because it will affect otherapplications that are installed. For more information, see http://go.microsoft.com/fwlink/?LinkId=91126

Please send me files I have deleted the dir with old versions of SNM few days before.

Thanks for your help and by continuous development of SNM.
0d

strel

Sep 20 2009, 04:32 PM

Bug fixed, check new version.

YumeYao

Sep 21 2009, 11:28 AM

I don't know how to make it easy to understand, but you know that there are some post-reboot actions made by an installation due to various types of causes, such as replacing file-in-use, delayed services start, etc. So does a windows hotfix.

a windows hotfix may prompt you to restart your computer, for example, it's a hotfix that contains a newer version of shell32.dll, which is in use, so you have to restart your computer to replace it. But here we say, Anyway, this type of hotfixes is not what causing problems at T-13(svcpack.inf).

There is another type of hotfixes, they may not require a reboot, but they have some post-install commands, therefore they may call spupdsvc.exe to perform these commands AT ONCE. WTF spupdsvc.exe doesn't know which delayed commands are scheduled by this installation and which are by others, so it executes every thing.

This is quite ok on a living system, but on a setup-in-progress system, it may be fatal. if you ever have a look at Windows Setup timeline(although it's quite out-dated it does something to this issue), you'll know that all steps are scheduled in order for a windows setup. One mistake may lead to the change of all the timeline after it. However, on a untouched system, this issue is so slight that can be ignored. But on a customized system, this issue may lead to quite a lot of customized actions fail. EDIT: and windows setup is so fragile that even a small fault may lead to global fail.

There once was a thread in RyanVM.net that discussed about all these, if I don't make it wrong, it was because a guy who made a T-13 switchless installer that executes some inf files to perform certain installation. Unluckily, his installer met some condition that make windows perform something similar to spupdsvc.exe, then it corrupted windows setup. (The situation was more complicated than what I described here.) This issue made us(I mean active RyanVM.net members at that time) realize such an issue. I have tried to find it out, but failed, sorry for this.

I have modified your install.cmd script and I'm now doing some windows setup tests in VM to see how it works. I have modified a lot so it's hard to tell what changed in short, I'll later post here anything I find.

0d14r3

Sep 21 2009, 04:59 PM

2 strel
No changes in the reg key, WU ask for langpack to Microsoft .NET Framework 2.0: x86 (KB829019)
Do you have a old _SNMsynth without reducing to send me?

0d

strel

Sep 21 2009, 06:43 PM

0d14r3

Bug fixed, check new version

strel

Sep 22 2009, 04:46 AM

QUOTE (YumeYao @ Sep 18 2009, 03:42 PM)

for KB971276, I have modified it again. now it's totally ok in XP SP2/SP3 and 2003, expect for a tiny bug in XP. However this bug is fixed and the attachment shows all(extract KB971276, modify it, generate bug-fixer as a cmd file for later use).

put the attachment in .NET 3.0 working dir, which includes XPS printer.
This attachment will also replace windows hotfix update shell in WIC and XPS lng pack with that in XPS printer, that ensures a smaller 7z archive.

So here you are removing the inf files that define the update branch, and copying the .NET 3.0 update shell files (for maximum compatibility, I suppose) to W2K3KB971276 for making it able to install on XP SP2, but I suppose this is making it too OS version and SP# level independent (among XP/2K3 supported), what's great.
But I think there's an error in your draft, and correct if I'm wrong, you say update shell from .NET 3.0 framework should substitute the one in the .NET 3.0 langpack, right?, and I think this is redundant.
OK, I see the point, you're downgrading this files.

QUOTE (YumeYao @ Sep 21 2009, 07:28 PM)

There is another type of hotfixes, they may not require a reboot, but they have some post-install commands, therefore they may call spupdsvc.exe to perform these commands AT ONCE. WTF spupdsvc.exe doesn't know which delayed commands are scheduled by this installation and which are by others, so it executes every thing.

This is quite ok on a living system, but on a setup-in-progress system, it may be fatal. if you ever have a look at Windows Setup timeline(although it's quite out-dated it does something to this issue), you'll know that all steps are scheduled in order for a windows setup. One mistake may lead to the change of all the timeline after it. However, on a untouched system, this issue is so slight that can be ignored. But on a customized system, this issue may lead to quite a lot of customized actions fail. EDIT: and windows setup is so fragile that even a small fault may lead to global fail.

There once was a thread in RyanVM.net that discussed about all these, if I don't make it wrong, it was because a guy who made a T-13 switchless installer that executes some inf files to perform certain installation. Unluckily, his installer met some condition that make windows perform something similar to spupdsvc.exe, then it corrupted windows setup. (The situation was more complicated than what I described here.)

I'm working in the option to allow components running spupdsvc.exe to install at RunOnce. But I would like to understand the problem, at least to document it properly in the guide. I think you're saying that OS hotfixes running over GUI-Mode setup are scheduling its delayed actions to be executed by spupdsvc.exe at 1st logon RunOnce; but at this time spupdsvc.exe is making a mess with the all delayed actions it has to apply, that would lead to some customizations scheduled to be applied by the user at that time through spupdsvc.exe too on his unattended source fail, because they need to be applied in a specific order. Am I right? Thus, a user with this requirements would delay all OS hotfixes installing from GUI-Mode Setup to RunOnce, so that delayed actions for that hotfixes would schedule to be run by spupdsvc.exe on 2nd logon RunOnce. Have I understood it right?

If affirmative, let me say that in my opinion the user better should seek another method to apply his customizations.

strel

Sep 22 2009, 08:13 AM

New update released!

It's NOT the release you're waiting for with the whole YumeYao's slimming method yet. This one will come soon.

In this one a couple of bugs are fixed:
1. The one causing 0d14r3 and brazilian users not to block KB829019 that was inserted in 20090912. Something copying .mst files to .msi folder and executing them from there not worked; plus doing all this as a workaround for Karoly67 problems avoid removing of fixes applied on uninstall for this case, and only masks the real problem.
2. The one causing YumeYao and everyone, not to block KB829019 when removing only 2.0 SP2 langpack while keeping framework, and in general causing not removing the fixes applied correctly on uninstall. This bug was a typo inserted in inlay fixes removing scripts in NETWUFIXES.mst since 20090818.

YumeYao, finally your KB829019 prompt was caused by not having installed the langpack while the fix is still applied. I've reviewed you Block script proposals they wouldn't work, NETWUFIXES.mst does the work very well, but yes probably I'll split it.

0d14r3

Sep 22 2009, 06:52 PM

Thanks, strel.
New version works fine.

0d

YumeYao

Sep 23 2009, 09:05 AM

First I'd say sorry I am again busy in real life. Er..... and I think I may have a cold(one f*cking guy of my roommates keeps motorfan running but it's already 3 days raining in a row.), so I decide to postpone my effort on this project to this weekend.

QUOTE (strel @ Sep 22 2009, 06:46 PM)

Yeah it's OS/SP# independent, so it's totally OK to be installed on XP/2K3.

For the statements in red, you get the wrong idea.
For the definition of these totally 6 files, KB898461 describes it. Although they vary in version, and even files in same version may vary(due to different compile dates causing different build times in PE header), they are doing the same job. They are similar to 7zip sfx module, how they work all depend on the configuration files(just like 7zip sfx config.txt) and contents(just like 7zip sfx 7z archive). Only that maybe a higher version provides more features.

So, here, I want: use highest version of the copy of these 6 files for any installation in hotfix form. The reason is because 7z archive same files only once, hense making the output size smaller. And the hightest version must be downgrade-compatible(there are enough proofs for us update pack makers) so it doesn't curropt the original functions at all.

I'm acturally upgrading not downgrading

, version in .NET 3.0 is 6.3.13.0, in 3.0 LP is 6.2.29.0.
BTW, the shell for 3.0LP have renamed spmsg.dll to spmsg2.dll. Just FYI.

QUOTE (strel @ Sep 22 2009, 06:46 PM)

Sorry you make it wrong again. (I think I have to improve my ablity of expression.

)

Continueing with the previous topic, I said that there are totally 6 "update shell files". Actually for most windows hotfixes/updates, there are only 5, spupdsvc.exe missing. spupdsvc.exe is not DELAYING jobs for next reboot at any time(this part can be simply done by registry), instead it always makes DELAYED jobs start right now. It's not odd that you can't reproduce it. For most delayed jobs, they are safe to be executed at once, that's the reason of spupdsvc.exe's existing. M$ uses this file to do certain post-hotfix-install routines including making delayed jobs execute.

For an untouched windows install source, there are some delayed jobs that can't be executed at once when the progress is T-13, but the problems they're causing are so slight that most people would ignore them.
An example is if you use nlite to crack syssetup.dll, nlite will make a delayed schedule at Pre-T-13(registry process stage) to restore syssetup.dll on next boot(move sysback.dll to syssteup.dll). Then a spupdsvc.exe executing at T-13 will break this.(it try to move sysback.dll to syssetup.dll but syssetup.dll is in use so sysback.dll is deleted and syssetup.dll is left as it was.)

Because as I said, most hotfixes doesn't contains spupdsvc.exe so it doesn't need the user to delay hotfixes to RunOnce and nlite can handle this correctly.

Off the topic, I suggest direct integration of hotfixes, or what's better, an update pack(as the maker will consider everything through).

QUOTE (strel @ Sep 22 2009, 10:13 PM)

New update released!

thanks for this.
For my blocking scripts, yes they were not working correctly. Blockalllp.vbs is always working as expected, BlockKB951847.vbs was not working and I have fixed it(removed "(" and ")" for function WriteRegKeyIfNotExists in line 6,7,8). Blockall_Undo.vbs is still not working and I can't figure out where the error is.

Do you know any editor or tool that can assist a vbs editing?

EDIT: I've found a tool named PrimalScript, 45 days free-trial, it should be enough for me. thanks anyway.

EDIT2: Just see that you are woking on spupdsvc.exe fix. I have accompolished a modified version of your install.cmd, which including this fix. I'll put it here later in a word document(do you prefer .doc or .docx or .rtf?) with colored comments. Then all you need to do is convert them into your script(adding echo>>install.cmd and adding %, ^ and such special symbols.)

mooms

Sep 23 2009, 06:01 PM

When i run the installer at T-13, i have 6 log files left at the root of my system drive (see pic) is this normal ? i think previous versions didn't do that.
I have used 20090913_SNMsynth. installed all frameworks (except 1.1 ) and french langpacks in merged installer.

0d14r3

Sep 23 2009, 06:18 PM

Its normal for last versions.
I have eight log files in my root, all dotNET mergeg in one installer.

0d

YumeYao

Sep 23 2009, 06:52 PM

replying from my mobile device.
this log issue is because environment variables are not assigned at T-13. strel specified log path to "%temp%\logname", resulting "\logname", which means logname in the current root.
I have locally fixed it by adding this line to install.cmd

CODE

if not defined temp set temp=%cd%

strel

Sep 23 2009, 07:01 PM

I've got a solution, I have to test it. About the error with the log files there are environment variables at T13, but not %TEMP%:

QUOTE (GreenMachine @ Nov 28 2003, 05:27 PM)

Here is the result of the SET command, run at the T-13 minute point:

CODE

D:\$OEM$>SET
ALLUSERSPROFILE=C:\Documents and Settings\All Users
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=NEWXP
ComSpec=C:\WINDOWS\system32\cmd.exe
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS
ProgramFiles=C:\Program Files
PROMPT=$P$G
SystemDrive=C:
SystemRoot=C:\WINDOWS
Upgrade=False
USERPROFILE=C:\Documents and Settings\Default User
windir=C:\WINDOWS
__PROCESS_HISTORY=C:\WINDOWS\system32\setup.exe

stephan_bauer

Sep 24 2009, 10:29 AM

Hello,

I made a .net package (German, version 20090922 and 20090913) with this configuration:

CODE

PROCESS_DNF1=
PROCESS_DNF2=
PROCESS_DNF35_DNF2=YES
PROCESS_DNF35_DNF3=YES
PROCESS_DNF35_DNF35=YES

PROCESS_DNF3_RGBRAST=YES
PROCESS_DNF3_WINIMAGING=YES
PROCESS_DNF3_MSXML6=YES
PROCESS_DNF3_XMLPSSC=YES

DNF_FF_ADDON=YES

PROCESS_LNG_DNF1=YES
PROCESS_LNG_DNF2=YES
PROCESS_LNG_DNF35_DNF2=YES
PROCESS_LNG_DNF35_DNF3=YES
PROCESS_LNG_DNF35_DNF35=YES

ADDON=
MERGE_FRAMEWORKS=YES
SILENT=
COMPRESSION_RATIO=
WINXP=YES

Unfortunatelly it installs only .net 2 and .net 3 but not .net 3.5

I'm using this files:
dotnetfx35.exe
dotnetfx35langpack_x86de.exe
msxml6-KB954459-deu-x86.exe
NDP20SP2-KB958481-x86.exe
NDP30SP2-KB958483-x86.exe
NDP35SP1-KB958484-x86.exe
NDP35SP1-KB963707-x86.exe

File size is 42.854 KB.

It worked with version 20090514. The file size was 50.859 KB

Any hints?

Regards

Stephan

strel

Sep 24 2009, 11:07 AM

Can you check 3.5SP1 and its languages are not really installed after looking for them on HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} regkeys?, if they are not really installed, and if you have installed made the install out of a windows setup, is there any NETFX35install.log or NETFX35LNGinstall.log related to this installs (check date) in %TEMP% folder?

Raoul90

Sep 24 2009, 03:39 PM

Hey Strel,

I updated the NL one, see here:
http://www.ryanvm.net/forum/viewtopic.php?t=7213

But unfortunatly, dotNET 2.0 crashes when windows xp is booting to desktop, just like the webclient service, because of this desktop hangs for like 10 minutes, and cant do anything. I disabled the causing service, but it still hangs, so I need to wait till it boots up.
Event log is full of errors, the exact errors are comming tomorrow (not written them down yet) , I will do some more tests also.
I installed from cmdlines. (using my extracted .exe from addon).
I might try installing it from runonceex.
I will rebuild installer tomorrow also.

strel

Sep 24 2009, 05:40 PM

No changes were made to 2.0 installers in the last versions, so I don't find any justification for such a bunch of errors. Waiting to see more info.

stephan_bauer

Sep 25 2009, 07:08 AM

Hello strel,

thank you for your answer.

The regkeys are not there. Also no files in C:\Windows\Microsoft.NET\Framework\ nor NETFXxxx.log.

QUOTE (strel @ Sep 24 2009, 07:07 PM)

stephan_bauer

Sep 25 2009, 07:16 AM

Hello,

is there a way to get the older versions.

I would like to test witch version does not have the error not installing .net 3.5.

Thanks in advance

Stephan

strel

Sep 25 2009, 07:40 AM

If you manage to install 2.0 and 3.0 frameworks, there should be uninstall regkeys for 2.0 and 3.0 frameworks and its langpacks at least, and under %SYSTEMROOT%\Microsoft .NET Framework\ there should be folders for these versions too, as well as its logs under %TEMP% folder (if you don't installed it from windows setup T-13)

Can you post your INSTALL.CMD?

I'll post previous versions in the next minutes.

stephan_bauer

Sep 25 2009, 09:26 AM

Attached you will find

INSTALL.CMD

NETFX35install.log

NETFX35LNGinstall.log

I couldn't upload log files.

strel

Sep 25 2009, 11:11 AM

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.

Raoul90

Sep 25 2009, 11:53 AM

CODE

.NET Runtime version 2.0.50727.3082 - Fatal Execution Engine Error (7A0979C6) (80131506)

Thats the error, I have no clue why tho, will now recreate the installer.

(BTW, I cant create the installer @ Windows 7, has issues with language pack of .net 2. Back to xp partition then).

strel

Sep 25 2009, 01:39 PM

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?

Raoul90

Sep 25 2009, 03:44 PM

QUOTE (strel @ Sep 25 2009, 09:39 PM)

This is the only official info I could found 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 that I know off.
I call the executable @ cmdlines.
My CMDLines in order:

CODE

1=dotNET-AIO-NLD-Silent.exe
2=RedDX_0.8.1_32bit.exe
3=winrar-x86-390nl.exe /S
4=PerfectDisk10.exe
5=mbam-setup.exe /VERYSILENT /SP- /norestart
6=Java6u16.exe
7=PowerISO45.exe /S
8=Adobe_Shockwave_11.5.1.601.exe
9=AcroRdr9.exe
10=VLC102.exe /S
11=klcodec510s.exe /VERYSILENT /SP- /norestart
12=klcodecupdate512s.exe /VERYSILENT /SP- /norestart

strel

Sep 25 2009, 04:24 PM

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.

Raoul90

Sep 26 2009, 02:26 AM

QUOTE (strel @ Sep 26 2009, 12:24 AM)

Will try it.

stephan_bauer

Sep 27 2009, 08:30 AM

Hello strel,

the last version which installs .net 3.5 is 20090821c.
I used the same files and configuration as mentioned before.

With later versions I'm getting a 'file not found' message for every .net version:
('Datei nicht gefunden' means 'File not found')

CODE

Checking .NET stuff to build installer(s)/addon(s) for XP...

** Processing .NET 3.5 SP1 redistributable package...
** Processing .NET 2.0 SP2 portion...
Processing NDP20SP2-KB958481-x86.exe...
Datei nicht gefunden
** Processing .NET 3.0 SP2 portion...
Processing msxml6-KB954459-deu-x86.exe...
Processing NDP30SP2-KB958483-x86.exe...
Datei nicht gefunden
** Processing .NET 3.5 SP1 portion...
Processing NDP35SP1-KB958484-x86.exe...
Datei nicht gefunden
Processing NDP35SP1-KB963707-x86.exe...
Datei nicht gefunden
** Processing dotnetfx35langpack_x86de.exe...
** Processing .NET 2.0 SP2 language portion...
** Processing .NET 3.0 SP2 language portion...
** Processing .NET 3.5 SP1 language portion...

Creating merged .NET 2.0 SP2 de, .NET 3.0 SP2 de, .NET 3.5 SP1 de passive installer...

DONE!

Could this be the problem? Is there a way to find out which file couldn'd be found?

Regards

Stephan

strel

Sep 27 2009, 09:34 AM

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.

stephan_bauer

Sep 27 2009, 10:29 AM

There it is

strel

Sep 27 2009, 01:17 PM

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.

stephan_bauer

Sep 27 2009, 02:54 PM

Hello strel,

it works with the latest 7zip (4.65).
Could you please add the version needed to your desription.
Is ist possible to check the version of 7zip within the script?

Thank you very much and sorry for wasting you time.

Regards

Stephan

Dumpy Dooby

Sep 29 2009, 01:00 AM

CODE

CSCRIPT /NOLOGO 35SP1SLIMMING.vbs

Should be...

CODE

CSCRIPT //NOLOGO 35SP1SLIMMING.vbs

You forgot the extra slash on that line (776).

YumeYao

Sep 30 2009, 03:14 AM

I finally worked out the whole thing as I wanted. Tested on VM and worked fine. Here are my final decisions to share:

for KB971276, I finally think it's safe to use original one.(WindowsXP-KB971276-v3-x86-ENU.exe for XP, WindowsServer2003-KB971276-v2-x86-ENU.exe for 2k3). But the hotfix update shell replacement is harmless and can be applied to reduce size.
on msi:
1. CA_BlockDirectInstall* in CustomAction and InstallExecuteSequence prevents msi from direct install. Removing them ensures the msi can be installed without "ADDEPLOY=1".
2. .NET 2.0 specific: DWFolder.D0DF3458_A845_11D3_8D0A_0050046416B9 and needed parents should NOT be removed in Directory, it's needed by debugger registry(DW20.exe).
on mst:
my final working set is here. Click to view attachment
on install.cmd:
Click to view attachment
EDIT: I have changed some paths.. be careful. as far as i can see, I didn't restore the path for XPS_LanguagePack in the document.

EDIT2: @Raul90
Have you integrated VC2005/2008 runtimes when you are doing a test?

strel

Sep 30 2009, 05:51 AM

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.

Raoul90

Sep 30 2009, 07:28 AM

@ YumeYao.

I only integrated this one:
http://www.ryanvm.net/forum/viewtopic.php?t=5063

YumeYao

Sep 30 2009, 09:23 AM

QUOTE (strel @ Sep 30 2009, 07:51 PM)

1. yes. My first method(branches) will bring a result that proper catalog is not installed on xp. My second method is a fault because it won't installs on xp sp3(I was working on xp sp2 those days so....).
Now I uses a modified inf and a patched update.exe for my release. If you don't want to use the patched one, you can apply my second method on KB971276-XP-V3(I didn't test that on 2k3 but I suppose it works). If that doesn't work, then using KB971276-XP and KB971276-2003 seperately is the safest way.

Still, I mean replace all update shells with the one in original XPS printer because those in XPS printer are latest.

QUOTE (strel @ Sep 30 2009, 07:51 PM)

- 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)

I'll test about the .msi cache names. I didn't notice what you said "original installers always use same file names for cached installers". If that's true, then I'll agree with you.
EDIT2: tested and here's a screenshot:
Click to view attachment
what you said does not happened.
so you can take a look at my msts and vbses, they will handle this issue properly.

QUOTE (strel @ Sep 30 2009, 07:51 PM)

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

On a live system it's always safe to execute spupdsvc.exe(consider how user installs hotfixes). Only on a system-setup-in-progress OS, it may damage. So I determinate it with SSIP.

RunOnceEx is also ok.

WIC won't execute spupdsvc.exe, that's why I doesn't make it RunOnce-delayed.

QUOTE (strel @ Sep 30 2009, 07:51 PM)

I'm beggining my tests now, hope all the above can be achieved.

good luck.

EDIT: forgot to say. look at this:
http://catalog.update.microsoft.com/v7/sit...aspx?q=KB951847
This 69.2 MB stuff is not same as the one in download.microsoft.com, if you can make your script compatible for this one, that will be good.

QUOTE (Raoul90 @ Sep 30 2009, 09:28 PM)

@ YumeYao.

I only integrated this one:
http://www.ryanvm.net/forum/viewtopic.php?t=5063

sorry, I can't see the reason why your install fails. All I use is also code's addon.

Dumpy Dooby

Sep 30 2009, 08:32 PM

Your program yielded this fancy install.CMD file for me...

CODE

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                                                        ::
::                Installer created with                  ::
::        Silent .NET Maker synthesized 20090922          ::
::  http://www.msfn.org/board/index.php?showtopic=127790  ::
::                                                        ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION
SET VERBOSITY=passive
SET SWITCH=%1
IF /I "%SWITCH:~-4%"=="sive" (SET VERBOSITY=passive) ELSE IF /I "%SWITCH:~-4%"=="uiet" (SET VERBOSITY=quiet) ELSE IF /I "%SWITCH:~-4%"=="lent" SET VERBOSITY=quiet
IF NOT EXIST FILEVER.vbs (
    ECHO>>FILEVER.vbs Set objFSO = CreateObject^("Scripting.FileSystemObject"^)
    ECHO>>FILEVER.vbs Wscript.Echo objFSO.GetFileVersion^(WScript.arguments^(0^)^)
)
FOR /F "DELIMS=. TOKENS=1" %%I IN ('CSCRIPT //NOLOGO FILEVER.vbs "%SYSTEMROOT%\SYSTEM32\MSI.DLL"') DO IF /I "%%I"=="2" (
    IF /I "%VERBOSITY%"=="passive" SET VERBOSITY=qb!
    IF /I "%VERBOSITY%"=="silent" SET VERBOSITY=qn
    IF /I "%VERBOSITY%"=="quiet" SET VERBOSITY=qn
)
SET SYS2K=1
IF EXIST %SYSTEMROOT%\system32\reg.exe (
    SET SYS2K=
    FOR /F "DELIMS=" %%I IN ('%SYSTEMROOT%\system32\REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ProductName') DO ECHO>DNFWIN1.TXT %%I
    FOR /F %%I IN ('FINDSTR/I "2000" DNFWIN1.TXT') DO SET SYS2K=1
)
IF NOT DEFINED SYS2K FOR /F "TOKENS=3" %%I IN ('REG QUERY "HKLM\SYSTEM\Setup" /v SystemSetupInProgress') DO SET SSIP=%%I
IF /I "%SSIP%"=="0x1" (
    REG DELETE "HKLM\SOFTWARE\Microsoft\PCHealth\ErrorReporting\DW" /f
    REG ADD "HKLM\SYSTEM\Setup" /v SystemSetupInProgress /t REG_DWORD /d 0 /f
)
IF EXIST *.TXT DEL /F *.TXT
XCOPY/DY DNF30\SYS32\rgb9rast_2.dll %SYSTEMROOT%\system32
%SYSTEMROOT%\system32\regsvr32 /s %SYSTEMROOT%\system32\rgb9rast_2.dll
START/WAIT DNF30\WIC\update\update.exe /%VERBOSITY% /norestart
START/WAIT DNF30\XPS\update\update.exe /%VERBOSITY% /norestart
NET STOP MSIServer
COPY /Y REMFONTCACHEFIX.mst DNF30
START/WAIT DNF30\Netfx30a_x86.msi /l*v "%TEMP%\NETFX30install.log" TRANSFORMS=REMFONTCACHEFIX.mst;NETWUFIXES.mst ADDEPLOY=1 ARPNOMODIFY=0 ARPNOREPAIR=0 /%VERBOSITY% /norestart
FOR /F "TOKENS=3" %%I IN ('REG QUERY "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\0DC1503A46F231838AD88BCDDC8E8F7C\InstallProperties" /V UnfixedDBName^|FINDSTR "UnfixedDBName"') DO REN %%I 39d3e.msi
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\0DC1503A46F231838AD88BCDDC8E8F7C\InstallProperties" /V UnfixedDBName /F
%SYSTEMROOT%\REGEDIT /E DNFWIN2.TXT "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"
TYPE DNFWIN2.TXT>DNFWIN3.TXT
FINDSTR/R "\[" DNFWIN3.TXT>DNFWIN4.TXT
FOR /F %%I IN ('FINDSTR/IR "\.KB958483" DNFWIN4.TXT') DO ECHO>>DNFWIN3.TXT %%I
FOR /F "DELIMS=[]" %%I IN (DNFWIN5.TXT) DO REG DELETE "%%I" /f
START/WAIT DNF35\vs_setup.msi /l*v "%TEMP%\NETFX35install.log" TRANSFORMS=NETWUFIXES.mst;NOFFADDONFIX.mst ADDEPLOY=1 ARPNOMODIFY=0 ARPNOREPAIR=0 /%VERBOSITY% /norestart
FOR /F "TOKENS=3" %%I IN ('REG QUERY "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\26DDC2EC4210AC63483DF9D4FCC5B59D\InstallProperties" /v UnfixedDBName^|FINDSTR "UnfixedDBName"') DO REN %%I 39d44.msi
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\26DDC2EC4210AC63483DF9D4FCC5B59D\InstallProperties" /v UnfixedDBName /f
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}" /v SystemComponent /t REG_DWORD /d 0 /f
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\26DDC2EC4210AC63483DF9D4FCC5B59D\InstallProperties" /v SystemComponent /t REG_DWORD /d 0 /f
%SYSTEMROOT%\REGEDIT /E DNFWIN2.TXT "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"
TYPE DNFWIN2.TXT>DNFWIN3.TXT
FINDSTR/R "\[" DNFWIN3.TXT>DNFWIN4.TXT
FOR /F %%I IN ('FINDSTR/IR "\.KB953595" DNFWIN4.TXT') DO ECHO>>DNFWIN6.TXT %%I
FOR /F %%I IN ('FINDSTR/IR "\.KB958484" DNFWIN4.TXT') DO ECHO>>DNFWIN6.TXT %%I
FOR /F "DELIMS=[]" %%I IN (DNFWIN6.TXT) DO REG DELETE "%%I" /f
IF /I "%SSIP%"=="0x1" (
    FOR /F "DELIMS=" %%I IN ('ECHO %PROGRAMFILES%\Common Files\Microsoft Shared') DO SET SHD=%%~sI
    REG ADD "HKLM\SYSTEM\Setup" /v SystemSetupInProgress /t REG_DWORD /d 1 /f
    REG ADD "HKLM\SOFTWARE\Microsoft\PCHealth\ErrorReporting\DW\Installed" /v DW0200 /t REG_SZ /d !SHD!\DW\DW20.EXE /f
)
%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\ngen.exe executequeueditems

I perused it a bit to try and find out what was causing my problems with my uninstallers not working, and I noticed this...

CODE

%SYSTEMROOT%\REGEDIT /E DNFWIN2.TXT "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"
TYPE DNFWIN2.TXT>DNFWIN3.TXT
FINDSTR/R "\[" DNFWIN3.TXT>DNFWIN4.TXT
FOR /F %%I IN ('FINDSTR/IR "\.KB958483" DNFWIN4.TXT') DO ECHO>>DNFWIN3.TXT %%I
FOR /F "DELIMS=[]" %%I IN (DNFWIN5.TXT) DO REG DELETE "%%I" /f

Specifically, I think...

CODE

FOR /F %%I IN ('FINDSTR/IR "\.KB958483" DNFWIN4.TXT') DO ECHO>>DNFWIN3.TXT %%I

is actually supposed to be...

CODE

FOR /F %%I IN ('FINDSTR/IR "\.KB958483" DNFWIN4.TXT') DO ECHO>>DNFWIN5.TXT %%I

Is that correct?

By the way, I don't think this has anything to do with my broken uninstaller (since I don't actually use install.cmd). It's just something I noticed while I was looking through the file.

7yler

Sep 30 2009, 11:09 PM

I been using SNM for a long time and its a great tool, thanks for you hard work.

I'm currently using SNM 20090913 and it works great, no problems on XP, but Win2003 is asking for KB951847.

Thanks for any help

strel

Oct 1 2009, 02:53 AM

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.

YumeYao

Oct 1 2009, 07:00 AM

good info.

Then it seems:

DW fix is not needed for we removed office debugger.

SSIP fix is (possibly) not needed for VC8 assemblies are initialized during txt-setup mode(if proper addon is integrated). I'm not sure and I havn't done any test for this.

Raoul90

Oct 1 2009, 07:53 AM

@ Strel
I havent had time to run a test install, I hope I can do it today.

strel

Oct 2 2009, 05:07 AM

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)?

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.