[YumeYao]

of course not. you know when creating mst, InstEd's removing related entries function doesn't work....

well I decide I'll always create a modified msi first, then create mst file by clearing original entries and pasting new entries.

[strel]

For the debugger (only) removing file, the Property Custom Actions with target [WindowsFolder], [CommonFilesFolder] and [ProgramsFilesFolder], and its related entries in the XXXXExecutionTables, I'm dubious about removing them in the same manner as with that CA of the 3.5 slimming files. Is the same case? Any news around this?

EDIT: I understood finally what's the logic in removing them, they are there only for supporting the creation of a folder tree where only resides a DW subfolder exclusively related with office debugging. In the case of the [XXXXX_folder] entries in 3.5 slimming files I ask you before, it's not the same case in my opinion, I have not see they are there for creating any uneeded forlder tree, in fact I still don't know it's function, if any.

This post has been edited by strel: 19 September 2009 - 02:06 PM

[YumeYao]

I suppose so, and I havn't look deeply into this. but FWIS, removing them doesn't cause any problem.

[strel]

About debugger removing. You say it's convenient an option to remove debugger because there is ways to install updated versions than that inside .NET 2.0, but from your draft I see in the FeatureComponents table that removing all components of Watson Feature you're removing also C# debuggin and logging, should they remain or are they updated by OFFICE 11 SP3 too?

[YumeYao]

I have just reviewed this.
Yeah you are right, Watson20_Error_Logging_____X86.3643236F_FC70_11D3_A536_0090278A1BB8 and CSharp_Watson20_Reg_Keys_____X86.3643236F_FC70_11D3_A536_0090278A1BB8 should be kept.

[strel]

I've edited post #342 above about the folders. I didn't remove dwsens.dll entries from debugger removing file, I suppose any other application can suscribe to SENS through this DW.

This post has been edited by strel: 20 September 2009 - 10:56 AM

[0d14r3]

Quote

•Avoid win/ms update to push KB928416 (3.0 SP0 langpacks) and KB829019 (2.0 SP0 PT-BR langpack) pointless updates when the right upper langpack version is installed

Work fine before versions 20090826b and 20090913 but now WU show KB829019 for 2.0 SP0 PT-BR langpack in optional.

0d

[YumeYao]

strel, on Sep 19 2009, 11:00 PM, said:

EDIT:[/b] I understood finally what's the logic in removing them, they are there only for supporting the creation of a folder tree where only resides a DW subfolder exclusively related with office debugging. In the case of the [XXXXX_folder] entries in 3.5 slimming files I ask you before, it's not the same case in my opinion, I have not see they are there for creating any uneeded forlder tree, in fact I still don't know it's function, if any.

But I still assume they are same. Well, have you noticed my description in my tutorial on the installer type, I defined it as an offline installer. Thus, an online installer may uses the location such as desktop, etc., because If i remember this correct, there was some online installer creating a shortcut on desktop(for resuming a paused downloading, etc.) Maybe when the online installer was modified into offline installer, M$ crap forgot to remove these entries. ---- I see no points why a external commandline/dll/internal binary using such properties.

strel, on Sep 20 2009, 03:01 AM, said:

I've edited post #342 above about the folders. I didn't remove dwsens.dll entries from debugger removing file, I suppose any other application can suscribe to SENS through this DW. These are release candidate drafts for 2.0 SP2 for removing VC8 and Office crash reporting tools, would be similar for 2.0 SP1:

20SP2_REM_OFFDEBUG.mst 20SP2_REM_VC8.mst
Any comments?

I just checked it again. I was sure dwsens.dll also appears in office 11, even same action(2 same entry points are loaded). However I looked at them again and found the 2 dwsens.dlls in office 11 and .NET 2.0 differs. So I'm not sure whether they do exactly the same jobs yet I expect it. I'll go to look up any info available about this, and maybe even test it.(hoping I can directly call it by rundll32, not by installer each time, installing office 11 will be insane.)

EDIT1: for your mst files, I just applied both and then compare the transformed to mine. So I did some improvements (my previous draft also missed them).
 20SP2_REM_OFFDEBUG.mst (16.5K)
Number of downloads: 3  20SP2_REM_VC8.mst (17.5K)
Number of downloads: 4

EDIT2: I decide to remove dwsens.dll.

From what I know, the registry keys set in SYSTEM\CurrentControlSet\Services\Eventlog\Application\.NET Runtime 2.0 Error Reporting and SYSTEM\CurrentControlSet\Services\Eventlog\Application\Microsoft ® Visual C# 2005 Compiler doesn't need dwsens.dll.

From what I see, dwsens.dll only appears in M$ products that have an external error handler, such as office, M$ defender, etc. So it must be such a dll, making external debugger(or we say here, error handler) able to override dr. waston's job.

EDIT3: Updated MST here, with dwsens.dll removed.  20SP2_REM_OFFDEBUG_REM_DWSENSE.mst (16.5K)
Number of downloads: 5
and have you noticed the table "SensSubscription", don't you think dwsens.dll is relative to it?

This post has been edited by YumeYao: 19 September 2009 - 10:20 PM

[strel]

2 0d14r3

Let's see that. NETWUFIXES containing that fix last changed in 2009 08 25 but the part referring to KB829019 fix was not modified. I suppose you are using installer containing 2.0 SP2 framework, and that is updated properly, otherwise you could received a message during installer building saying KB951847 will not be applied, and if that happened this should be the cause, because both fixes came in the same pack; check the installer too, uncompress it to see whether NETWUFIXES.mst is in the same forlder as INSTALL.cmd or not.
Is the following value in the registry?
HKLM\SOFTWARE\Microsoft\DevDiv\URT\Servicing\1.1\RED\1046\Install
It should be of type DWORD with value 1. (that's KB829019 fix)

2 YumeYao
Obviously SensSubscription is absolutely related to dwsens.dll functionality, it is used to suscribe office debugger to SENS, but apparently is not part of the office debugger itself. What I say is that this library may be used by other .NET software appart from office to suscribe to SENS later. Or maybe the software that use it came with its own copy to do that. That's what I'd like to know.

In your 20SP2_REM_OFFDEBUG_REM_DWSENSE.mst you removed dwsens.dll and the custom actions related, that's in question. But you removed CreateFolder:
TARGETDIR CSharp_Watson20_Reg_Keys_____X86.3643236F_FC70_11D3_A536_0090278A1BB8
VC_Configurable.3643236F_FC70_11D3_A536_0090278A1BB8 Watson20_Error_Logging_____X86.364......
They are related to the components of the feature where office debugger resides that we concurred should not be removed. And in Directory:
VC_Configurable.3643236F_FC70_11D3_A536_0090278A1BB8 TARGETDIR .
In addition to its related CustomAction and XXXExecuteSequence entries.

In your 20SP2_REM_VC8.mst
I see your point removing sxs related folders left, and its related custom actions and XXXExecuteSequence entries.

And a trick to use Insted with .mst files, the time first you tell Insted where to save the .mst file is actually not saving anything until you make changes and then save, so does not present the window of related entries when you removed them, but when I opened Insted with a previously saved .mst it does it.

This post has been edited by strel: 20 September 2009 - 04:54 AM

[YumeYao]

Yeah, but from what i know, there is no need for .NET 2.0 to use this dwsens.dll. .NET 2.0 doesn't have a debugger, etc. .NET 2.0, like it is, "framework", is a framework on which applications could be runned. Same thing happens on .NET 3.0 & .NET 3.5, that's why they don't have such a dwsens.dll. I have said that, only applications coming with a debugger for itself needs this. That's why I see no points it's needed.

Additionally, I suppose the reason why .NET 2.0 include office debugger is for those who installed office11 but didn't have latest service pack applied. As it's said that .NET 2.0 is partly compatible to .NET 1.1 applications, so maybe this update is intended to let office 11's .NET 1.1 extension able to be debugged within the enviroment of .NET 2.0. As said, latest service pack of office 11 contains newer files, so definatively this functionality is embedded into office 11 itself.

on 20SP2_REM_OFFDEBUG_REM_DWSENSE.mst:
they are safe. That's what the trick is.

and thanks for the trick of creating mst file. very handy.

[YumeYao]

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:

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.

This post has been edited by YumeYao: 20 September 2009 - 06:47 AM

[YumeYao]

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.
 Blocks.zip (2.44K)
Number of downloads: 9
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)

This post has been edited by YumeYao: 20 September 2009 - 08:17 AM

[strel]

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

This post has been edited by strel: 29 October 2009 - 08:38 PM

[YumeYao]

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.
 35_slimmingmore.zip (6.43K)
Number of downloads: 12

[0d14r3]

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

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"

0d

[strel]

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

This post has been edited by strel: 20 September 2009 - 01:23 PM

[strel]

YumeYao, on Sep 20 2009, 02:27 PM, said:

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?

YumeYao, on Sep 20 2009, 02:27 PM, said:

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.

This post has been edited by strel: 21 September 2009 - 09:32 AM

[0d14r3]

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

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]

Bug fixed, check new version.

This post has been edited by strel: 22 September 2009 - 08:15 AM

[YumeYao]

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.

This post has been edited by YumeYao: 21 September 2009 - 11:30 AM