.NET Framework 3.5 SP1 setup will fail if it is run by a user account that starts with a # character
I was working with our product support team on an interesting .NET Framework 3.5 SP1 installation failure earlier this week, and I wanted to describe the issue and options for working around it in case anyone else runs into similar issues in the future.
Description of the issue
If you run .NET Framework 3.5 SP1 setup with a user account whose name begins with a # character, the installation will fail.
In this scenario, if you open the verbose MSI log file for the .NET Framework 3.5 SP1 ( %temp%\dd_net_framework35*.txt from this list of log files) and search for the string return value 3 , you will see an error like the following:
MSI (s) (1A:BC) [11:11:11:111]: Product: Microsoft .NET Framework 3.5 SP1 -- Error 1406.Could not write value InstalledBy to key \SOFTWARE\Microsoft\Updates\Microsoft .NET Framework 3.5 SP1\KB953595. System error . Verify that you have sufficient access to that key, or contact your support personnel.
The registry key that is causing this failure is new in the .NET Framework 3.5 SP1, so this error will not occur when installing the .NET Framework 3.5 or earlier.
How to work around the issue
If you encounter this error when trying to install the .NET Framework 3.5 SP1 with a user account whose name begins with a # character, you can do one of the following to work around this and successfully install:
1. Run .NET Framework 3.5 SP1 setup with a different user account
You can either log off and log on with another user account or use the RunAs command to run .NET Framework 3.5 SP1 setup with a different user account that does not start with a # character to avoid this error.
2. Manually set the registry values before running .NET Framework 3.5 SP1 setup
You can pre-configure the problematic registry key and values on your system before installing the .NET Framework 3.5 SP1 to avoid this error. This will cause setup to skip setting the values because they are already present. To do this, you will need to set the following registry values on your system:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Microsoft .NET Framework 3.5 SP1\KB953595]
"ThisVersionInstalled"="Y"
"ARPLink"="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}.KB953595"
"PackageName"="Hotfix for Microsoft .NET Framework 3.5 SP1 (KB953595)"
"PackageVersion"="1"
"Publisher"="Microsoft Corporation"
"PublishingGroup"="Developer Division"
"ReleaseType"="Hotfix"
"InstalledBy"="yourusername"
"InstalledDate"="2/27/2009"
"InstallerName"="Windows Installer"
"InstallerVersion"="4.00"
All of the above registry values should be set with the REG_SZ data type. The exact data set for the InstalledBy and InstalledDate values can be set to data of your choosing.
The InstallerVersion value should be set to the Windows Installer major and minor version on your system. You can determine the appropriate value on your system by running msiexec.exe /? and looking at the version number listed at the top of the dialog that appears.
Root cause of the issue
The entry for the InstalledBy value in the Registry table of the .NET Framework 3.5 SP1 MSI is set to the value [LogonUser]. This will set the registry value to the built-in Windows Installer property named LogonUser.
If the LogonUser property begins with a # character, Windows Installer will attempt to write the InstalledBy registry value as a REG_DWORD value (because the # character is a special prefix when used in a registry value as described in this MSDN topic). However, if the LogonUser value is not actually a DWORD, the MSI will fail with a 1406 error like the one listed above.
Comments
Anonymous
March 06, 2009
Sorry for a detour, but desperation prevails ;o( WIN XP SP3 IE7 VisualStudio 8 (fully updated) .NET all the latest All of a sudden javascript stopped working? Using MSHTA or IE7... FF and Chrome work fine ... Any ideas? It must be some update messed up the registry and/or security ? dbjdbj@gmail.comAnonymous
March 08, 2009
Hi DBJDBJ - I don't have a lot of expertise troubleshooting Javascript problems like you describe. It might help to re-register jscript.dll by running regsvr32.exe %windir%system32jscript.dll.Anonymous
May 05, 2009
We are deploying .net 3.5 through Prism Deploy. It runs in a script, configured to run as an admin-level user. It succeeds on about 50% of the computers, and fails on the other 50%. Here’s a snippet from a log of a successful installation: Action start 14:39:16: InstallFinalize. MSI (s) (DC:C0) [14:39:16:845]: Executing op: ProductInfo(ProductKey={54A4143B-6B4B-4082-B248-643B25561CCB},ProductName=RGB9RAST,PackageName=RGB9RAST_x86.msi,Language=0,Version=151978719,Assignment=0,ObsoleteArg=0,,,PackageCode={03C9DE4B-2618-4EDA-9C8B-8CD66AC8C15B},,,InstanceType=0,LUASetting=0,RemoteURTInstalls=0) MSI (s) (DC:C0) [14:39:16:845]: SHELL32::SHGetFolderPath returned: C:Documents and SettingsPCDApplication Data Note PCD is the domain admin account that the task is set to run as. Here’s a snippet from the log of an unsuccessful installation. It’s the same task, running as the same PCISD user. Things start to go south when looking for a user shell folder. This SID in the error below is the SID of the domain admin account the installation is running as: MSI (s) (64:E0) [22:58:44:140]: Executing op: ProductInfo(ProductKey={54A4143B-6B4B-4082-B248-643B25561CCB},ProductName=RGB9RAST,PackageName=RGB9RAST_x86.msi,Language=0,Version=151978719,Assignment=0,ObsoleteArg=0,,,PackageCode={03C9DE4B-2618-4EDA-9C8B-8CD66AC8C15B},,,InstanceType=0,LUASetting=0,RemoteURTInstalls=0) MSI (s) (64:E0) [22:58:44:140]: Note: 1: 1402 2: HKEY_USERSS-1-5-21-8915387-1188570074-196506527-24732SoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders 3: 2 MSI (s) (64:E0) [22:58:44:140]: Note: 1: 1402 2: HKEY_USERSS-1-5-21-8915387-1188570074-196506527-24732SoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders 3: 2 MSI (s) (64:E0) [22:58:44:140]: Found shell folder by spelunking through the registry. MSI (s) (64:E0) [22:58:44:140]: Note: 1: 2103 2: 26 MSI (s) (64:E0) [22:58:44:140]: Note: 1: 2205 2: 3: Error MSI (s) (64:E0) [22:58:44:140]: Note: 1: 2228 2: 3: Error 4: SELECTMessageFROMErrorWHEREError= 2103 DEBUG: Error 2103: Could not resolve path for shell folder 26. MSI (s) (64:E0) [22:58:44:140]: Note: 1: 2205 2: 3: Error MSI (s) (64:E0) [22:58:44:140]: Note: 1: 2228 2: 3: Error 4: SELECTMessageFROMErrorWHEREError= 1709 MSI (s) (64:E0) [22:58:44:140]: Product: RGB9RAST -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2103. The arguments are: 26, , The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2103. The arguments are: 26, , We don't understand why it succeeds only on 50%.Anonymous
May 06, 2009
The comment has been removedAnonymous
May 07, 2009
PingBack from http://blogs.msdn.com/astebner/archive/2009/05/07/9595739.aspxAnonymous
August 03, 2009
We are facing what seems as a somewhat related issue. Using Framework 3.5 SP1: When we log in a user that starts with a # character and want to run a csharp application, the application fails to find its own configuration file, where we set some values required for it to find some resources. I was thinking that it could be an error similar where the Logon is used as a variable or variable value somewhere. Do you know a work around for the issue I just described? Thank you in advance. IvanAnonymous
August 10, 2009
Hi Ivan Carmona - The error described in this blog post is specifically related to a registry key that is being created during the installation process. I don't think it is the same as the runtime issue that you're seeing. Unfortunately, I'm not familiar with any workarounds for your issue. I'd suggest posting a question about this issue on the forum at http://social.msdn.microsoft.com/Forums/en-US/clr/threads to see if someone there is familiar with it and can help suggest a fix or workaround.