Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

.NET Framework 3.5 SP1 setup will fail if it is run by a user account that starts with a # character

.NET Framework 3.5 SP1 setup will fail if it is run by a user account that starts with a # character

  • Comments 7

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.

  • 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.com

  • 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%\system32\jscript.dll.

  • 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 Settings\PCD\Application 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_USERS\S-1-5-21-8915387-1188570074-196506527-24732\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders 3: 2

    MSI (s) (64:E0) [22:58:44:140]: Note: 1: 1402 2: HKEY_USERS\S-1-5-21-8915387-1188570074-196506527-24732\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell 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: SELECT `Message` FROM `Error` WHERE `Error` = 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: SELECT `Message` FROM `Error` WHERE `Error` = 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%.

  • Hi Perler - It looks like you're hitting an error like the one in the forum post at http://social.msdn.microsoft.com/Forums/en-US/netfxsetup/thread/839509dc-398b-40b9-a99a-420e504be6b8/.  There are some issues related to the ALLUSERS property in the RgbRast MSI when deploying from some types of deployment software.

    I'd suggest trying to manually install RgbRast before running .NET Framework 3.5 SP1 setup to work around this issue.  Here is a command line you can use to do that:

    msiexec /i RGB9RAST.msi /qn ALLUSERS=1 REBOOT=ReallySuppress

    I'm not sure why you're only seeing this behavior on some systems but not others though.

  • PingBack from http://blogs.msdn.com/astebner/archive/2009/05/07/9595739.aspx

  • 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.

    Ivan

  • 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.

Page 1 of 1 (7 items)
Leave a Comment
  • Please add 2 and 1 and type the answer here:
  • Post