We might receive an error “SL****.tmp has stopped working" while installing .Net Framework 1.1 SP1 (NDP1.1sp1-KB867460-X86.exe)
In this scenario we receive an error “SL****.tmp has stopped working" and it crashes while installing .Net Framework 1.1 SP1 (NDP1.1sp1-KB867460-X86.exe), however, if we extract the patch using /XP (S867460.msp) and try installing, it installs fine. Since .Net Framework 1.1 SP1 crashes, I launched SP1 (NDP1.1sp1-KB867460-X86.exe) in the debugger https://www.microsoft.com/whdc/devtools/debugging/installx86.Mspx) and took a crash dump (https://support.microsoft.com/kb/286350) . After debugging I found that the program is invoked via reflection from XStart.Main in SL7096.tmp, and is running in the .NET Framework 2.0:
0:000> !eeversion
2.0.50727.312 retail
Workstation mode
The target invocation exception has an inner exception, which is an installer exception complaining about the product configuration data being incorrect:
Exception type: Microsoft.WindowsInstaller.InstallerException
Message: The configuration data for this product is corrupt. Contact your support personnel.
InnerException: <none>
StackTrace (generated):
SP IP Function
0012EDD8 00375079 Microsoft.WindowsInstaller.Installer.get_Products()
0012EDE8 00374DBE Microsoft.DDPatch.PatchInstallation.ApplyPatchToInstalledProducts(System.String, System.String, Microsoft.DDPatch.TargetProduct[], Boolean, System.String, System.String ByRef)
0012EE50 003731F7 Microsoft.DDPatch.PatchInstallation.Install(System.String, Boolean, System.String)
0012EE90 00372DCA Microsoft.DDPatch.PatchExec.Main(System.String[])
StackTraceString: <none>
HResult: 80131501
DumpDynamicAssemblies gives us this:
0:000> !dda
Domain: SL7096.tmp
---------------------------
Assembly: 0x00232e48 [Microsoft.Cabinet.MiniExtract, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null] Dynamic Module: 0x002d31c4 loaded at: 0x003d0000 Size: 0x00005a00(23,040)
Assembly: 0x00253778 [PatchExec, Version=1.0.1692.30808, Culture=neutral, PublicKeyToken=null] Dynamic Module: 0x002d58c8 loaded at: 0x03da0000 Size: 0x00015000(86,016)Assembly: 0x00257328 [Microsoft.WindowsInstaller, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null] Dynamic Module: 0x002d94ec loaded at: 0x03de0000 Size: 0x00017000(94,208)
Dumping the module info for the PatchExec:
0:000> !dumpmodule 0x002d58c8
Name: PatchExec, Version=1.0.1692.30808, Culture=neutral, PublicKeyToken=null
Attributes: PEFile
Assembly: 00253778
LoaderHeap: 00000000
TypeDefToMethodTableMap: 003e3d94
TypeRefToMethodTableMap: 003e3dd0
MethodDefToDescMap: 003e3f78
FieldDefToDescMap: 003e4098
MemberRefToDescMap: 003e41d0
FileReferencesMap: 003e44e0
AssemblyReferencesMap: 003e44e4
MetaData start address: 03daeba0 (16756 bytes)
This doesn't look right. What happened in this case? This particular patch (and some other .NET Framework patches) consists of a Windows Installer patch file (.msp file) along with some wrappers around some APIs for the Windows Installer. These wrappers provide, among other things, support for rollback and for proper installation of the patch. In this particular case, one wrapper called an API that enumerated products installed by the Windows Installer. That API enumerated the HKEY_CLASSES_ROOT/Installer/Products registry key which contains a GUID for each product that's installed. But in this case, a GUID “XXX613FD48ABF0B0XXX0B88B046785D8DSTXXX” was created by a different application. Hence, in order to resolve the issue I just deleted the registry key HKEY_CLASSES_ROOT\Installer\Products\XXX613FD48ABF0B0XXX0B88B046785D8DSTXXX