Freigeben über

We might receive an error “SL****.tmp has stopped working" while installing .Net Framework 1.1 SP1 (NDP1.1sp1-KB867460-X86.exe)

  • Artikel

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