14 replies to this topic

[Johannes John]

Hello,

I've created a setup with the VC++ 8.0 MSMs, Version 8.0.50727.762.
Created with IS 2008. ( MSMs incl. Policies )

The installation is running fine.
But at the uninstallation, the SxsUninstallCA takes 6 minutes, as I can see in the LOG file.

That can't be normal.
Perhaps I'm doing something wrong.

Can someone give me a hint?

Thanks in advance!
Johannes


P.S.
In the LOG file:
...
Aktion gestartet um 19:21:08: SxsUninstallCA.
MSI (s) (78:94) [19:21:08:658]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI71B.tmp, Entrypoint: CustomAction_SxsMsmCleanup
MSI (s) (78:9C) [19:21:08:658]: Generating random cookie.
MSI (s) (78:9C) [19:21:08:690]: Created Custom Action Server with PID 4860 (0x12FC).
MSI (s) (78:A4) [19:21:08:846]: Running as a service.
MSI (s) (78:A4) [19:21:08:846]: Hello, I'm your 32bit Impersonated custom action server.
1: sxsdelca tried opening key w/o wow64key 2: Software\Microsoft\Windows\CurrentVersion\SideBySide\PatchedComponents 3: 396 4: 0
1: sxsdelca tried opening wow64key 2: Software\Microsoft\Windows\CurrentVersion\SideBySide\PatchedComponents 3: 416 4: 0
1: sxsdelca 2: traceop 3: 1158 4: 0
1: sxsdelca 2: traceop 3: 1186 4: 0
1: sxsdelca 2: traceop 3: 732 4: 0
1: sxsdelca 2: traceop 3: 748 4: 0
1: scavenge 2: {8FC72000-88A0-4B41-82B8-8905D4AA904C} 3: {98CB24AD-52FB-DB5F-C01F-C8B3B9A1E18E} 4: {C425F854-5106-4CF8-A2C1-AC615D6E26CF} 5: -1
1: sxsdelca 2: traceop 3: 748 4: 0
1: scavenge 2: {FA7E3351-448B-4BDA-986F-8CB3DA36CE5D} 3: {98CB24AD-52FB-DB5F-C01F-C8B3B9A1E18E} 4: {C425F854-5106-4CF8-A2C1-AC615D6E26CF} 5: -1
1: sxsdelca 2: traceop 3: 748 4: 0
1: scavenge 2: {117879C1-55D0-46C8-9376-1F97210A813B} 3: {98CB24AD-52FB-DB5F-C01F-C8B3B9A1E18E} 4: {C425F854-5106-4CF8-A2C1-AC615D6E26CF} 5: -1
1: sxsdelca 2: traceop 3: 748 4: 0
1: scavenge 2: {704092B2-A55F-4BA6-A50D-C3B9674335B3} 3: {98CB24AD-52FB-DB5F-C01F-C8B3B9A1E18E} 4: {C425F854-5106-4CF8-A2C1-AC615D6E26CF} 5: -1
1: sxsdelca 2: traceop 3: 748 4: 0
1: scavenge 2: {47C9D713-25E9-4262-9358-7763BCE67F33} 3: {98CB24AD-52FB-DB5F-C01F-C8B3B9A1E18E} 4: {C425F854-5106-4CF8-A2C1-AC615D6E26CF} 5: -1
1: sxsdelca 2: traceop 3: 748 4: 0
1: scavenge 2: {B9426885-7EAB-4d29-9324-F9F9FBD5D2C2} 3: {98CB24AD-52FB-DB5F-C01F-C8B3B9A1E18E} 4: {C425F854-5106-4CF8-A2C1-AC615D6E26CF} 5: -1
1: sxsdelca 2: traceop 3: 748 4: 0
1: scavenge 2: {80FDE627-62B0-46EF-B95A-CC28ACFEB20C} 3: {98CB24AD-52FB-DB5F-C01F-C8B3B9A1E18E} 4: {C425F854-5106-4CF8-A2C1-AC615D6E26CF} 5: -1
1: sxsdelca 2: traceop 3: 748 4: 0
1: scavenge 2: {4F177D37-2CF2-4B8F-9C0F-1E8D0AC66537} 3: {98CB24AD-52FB-DB5F-C01F-C8B3B9A1E18E} 4: {C425F854-5106-4CF8-A2C1-AC615D6E26CF} 5: -1
...
...
...
1: sxsdelca 2: traceop 3: 748 4: 0
1: scavenge 2: {3CCE56E5-9E33-4985-B79C-3AC8F3C91F34} 3: {671D08AE-9B06-9194-C01F-C8B3B9A1E18E} 4: {C425F854-5106-4CF8-A2C1-AC615D6E26CF} 5: -1
1: sxsdelca 2: traceop 3: 748 4: 0
1: scavenge 2: {F80A9686-0354-49A0-9003-76CAC5627199} 3: {671D08AE-9B06-9194-C01F-C8B3B9A1E18E} 4: {C425F854-5106-4CF8-A2C1-AC615D6E26CF} 5: -1
1: sxsdelca 2: traceop 3: 748 4: 0
1: scavenge 2: {AC76BA86-7AD7-1031-7B44-A81000000003} 3: {671D08AE-9B06-9194-C01F-C8B3B9A1E18E} 4: {C425F854-5106-4CF8-A2C1-AC615D6E26CF} 5: 3
1: sxsdelca 2: traceop 3: 1193 4: 0
1: sxsdelca 2: traceop 3: 1230 4: 0
1: sxsdelca 2: traceop 3: 1342 4: 0
1: sxsdelca 2: traceop 3: 1344 4: 0
1: sxsdelca 2: traceop 3: 662 4: 0
1: sxsdelca 2: traceop 3: 664 4: 0
1: sxsdelca 2: traceop 3: 1346 4: 0
1: sxsdelca 2: SxsMsmCleanup 3: 0 4: 0
Aktion beendet um 19:27:06: SxsUninstallCA. Rückgabewert 1.
...

Edited by Johannes John, 14 February 2008 - 17:27.

[VBScab]

Run ProcMon (or your favoured process/file/registry monitoring tool) as you uninstall and that will clearly show what's going on.

Edited by VBScab, 19 February 2008 - 15:40.

[Johannes John]

Hello,

with VC 9.0 I get the same problem.

The CA SxsUninstallCA takes time, too much.

I don't know, if I want to know, what this CA is doing and how.

Does someone know, what happens if I delete this CA in my MSIs?
( expect my setup at uninstall runs much faster ).

Perhaps Stefan could ask MS, for what the CA SxsUninstallCA is good for?

Regards and Thanks!
Johannes

Edited by Johannes John, 17 October 2008 - 15:59.

[VBScab]

[Johannes John]

Hello VBScab,

now I know, that it's doing a lot in the registry.

How do I have an influence on that?
I can't do any changes to the CA, if I'm right?

Could this, what the CA is doing, could this be done more quickly?
Are there any properties to have an influence on the ongoing of the CA?

Hello VBScab, do you have any suggestions?

Regards!
Johannes

Edited by Johannes John, 20 October 2008 - 10:27.

[VBScab]

You have no influence over it, no and I wouldn't imagine you'd be able to change the CA itself, unless it's script-driven. If it bothers you, you *could* rebuild the CA into your own version, whereby you just delete the relevant keys/values but you'd also need to check reference-counting for the assemblies (if used) and things like that.

TBH, if it were me, I'd live with it.

[Johannes John]

It seams to be, that I will have to live with this problem too.

But my target is, that MS will optimize this CA in the MSM.
Where there's life, there's hope.

Regards!
Johannes

[colby]

Some of my users have reported this same issue for an MSI package that shipped in early 2008. However, the problem only occurs on systems where MSI 4.5 has been installed. It appears that installing MSI 4.5 is causing some kind of trouble with the SxsUninstallCA custom action. In fact, a customer has duplicated this problem AT INSTALLTIME by installing MSI 4.5 before the install package on an XP system. In that scenario, SxsInstallCA takes a long time to run.

[VBScab]

Have you or the customer reported it to MS?

[Johannes John]

Hello VBScab,

no, I havn't.
I don't know how! Sorry!

But if I could support someone, I will do.
Johannes

[colby]

I reported this to Microsoft using my MSDN subscription. After finally being routed to the correct resolvers they were able to determine that this is a problem under the following conditions:

1) MSI package contains the SxsInstallCA/SxsUninstallCA custom actions from the VS 2005 SP1 merge modules.
2) MSI package contains the [MsiLogging] property with the "x" logging flag (debug) included in the value.
3) MSI 4.0 or higher is installed.

What is happening is that the CAs from the VS 2005 SP1 modules have some code that gets fired when the "x" MSI logging flag is set. The code itself doesn't actually write much to the MSI log but if the correct debugging setting is enabled on the system and the appropriate debugging objects are present it will show more information in the debugging window.

In order to prevent the uninstall from using [MsiLogging] value specified in the MSI package, you have to BOTH of the MSI logging machine policy registry entries listed below:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
"Logging"="voicewarmup"
"DisableLoggingFromPackage"=dword:00000001

The "Logging" registry value can be set to anything as long as the "x" flag is not specified. Also note that the MSI log will still show the [MsiLogging] value specified in the MSI package but it will be ignored and the value specified in the "Logging" registry value will be used instead.

Microsoft has promised me they will send me a URL for a support incident that can be referenced by my customers. I will post the URL once it is available.

Hope this helps!

[VBScab]

Excellent work, Sir, and damn useful. Another nugget to file away and produce years from now, to my colleague's amazement!

[Johannes John]

Hello,

thanks to you, colby, for your effort.
Very interesting point.

But your resolvers havn't told the whole truth.

To 3): it happens on MSI 3.1 too
To 2): there it depends on the "v" and the "i" flag

But without "vi" the log is very small.

I hope, that the next releases of these VS MSMs, ( especial the VS 2008 and next VSs) include a SxsUninstallCA custuom action with reduced output.

Hope ...

Thanks!
Johannes

[colby]

Sorry, my earlier post about the infromation from MS support was a generic post I cut/pasted to several forums where an issue similar to the one described by the original poster was reported. I posted it here because I thought it was relavant too. However, the actual problem that my post explains is slightly different from the one by the original poster. That problem (my problem) is that the custom actions in question take in excess of 20-30 MINUTES to run. That problem does only occur when MSI 4.0/4.5 is installed and the "x" logging flag is used.

In my case, my customer started seeing the behavior on an WinXP system after installing my product then installing MSI 4.5 then uninstalling my product (I had set the MsiLogging property to include all flags - which I will NEVER do again).

Something that may be relavant to the problem reported by the original poster: the time it takes for these custom actions to run on all versions of MSI will vary depending on how many times they've been run on the system by other application installations (other installations that also contain those merge modules). This is the reason for the earlier posting about the "stuff in the registry" the custom actions are doing. The more apps installed with those CAs, the more "stuff in the registry" that needs to be done for ref counting.

BTW, I don't think MS is going to fix this by releasing another version of the VS 2005 modules so if you're building using VS 2005 then I think your best bet is to install the binaries as private assemblies to your application program files folder according to the instructions in the VS 2005 file "redist.txt" (assuming your application only targets WinXP and higher - that won't work for W2K systems). Then you don't need the VS 2005 modules at all.

[colby]

http://support.microsoft.com/kb/971133