The Microsoft .Net Framework 3.5 SP1 Setup may fail without any error message or the setup may crash almost at the end. You can find the below error messages in the log file:

[01/20/13,05:32:37] Microsoft .NET Framework 3.5 (x64) 'package': [2] Error: Installation failed for component Microsoft .NET Framework 3.5 (x64) 'package'. MSI returned error code 1603
[01/20/13,05:32:49] WapUI: [2] DepCheck indicates Microsoft .NET Framework 3.5 (x64) 'package' is not installed.

In the detail log file (dd_NET_Framework35_x64_MSI****.txt) at %temp% location, it had more information on the failure as mentioned below:

DDSet_Status: CExtensionElement::SetData szName=webHttp szType=System.ServiceModel.Configuration.WebHttpElement, System.ServiceModel.Web, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 szXPath=system.serviceModel/extensions/behaviorExtensions/add
DDSet_Status: CFxInstaller::SetupExtensions Adding System.ServiceModel.Configuration.WebHttpElement, System.ServiceModel.Web, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
DDSet_Status: CExtensionElement::AddToConfigFile _xPath=system.serviceModel/extensions/behaviorExtensions/add
DDSet_Status: CConfigEntry::IsPresent szPath=system.serviceModel/extensions/behaviorExtensions/add
DDSet_Status: CFxInstaller::SetupExtensions extensionElement.AddToConfigFile failed.value=System.ServiceModel.Configuration.WebHttpElement, System.ServiceModel.Web, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Error code: 0x80004005.
DDSet_Status: CExtensionElement::SetData szName=webMessageEncoding szType=System.ServiceModel.Configuration.WebMessageEncodingElement, System.ServiceModel.Web, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 szXPath=system.serviceModel/extensions/bindingElementExtensions/add
DDSet_Status: CFxInstaller::SetupExtensions Adding System.ServiceModel.Configuration.WebMessageEncodingElement, System.ServiceModel.Web, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
DDSet_Status: CExtensionElement::AddToConfigFile _xPath=system.serviceModel/extensions/bindingElementExtensions/add
DDSet_Status: CConfigEntry::IsPresent szPath=system.serviceModel/extensions/bindingElementExtensions/add
DDSet_Status: CFxInstaller::SetupExtensions extensionElement.AddToConfigFile() failed. Value=System.ServiceModel.Configuration.WebMessageEncodingElement, System.ServiceModel.Web, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Error code:0x80004005

After my initial review, I found that that the issue occurred due to the below lines being added in the 32-bit web.config file located at C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG

<compilation tempDirectory="C:\Asp.net Temp Files\2.0.50727\x86">
<compilation tempDirectory="C:\Asp.net Temp Files\2.0.50727\x64">

In general the <compilation tempDirectory…> is never set to a value like this. It used to be always under C:\Windows\Microsoft.NET\v2.0.50727\Temporary ASP.NET files.  Later, I found WFServicesReg was barfing because the config file already contained the elements needed in the file so it was not able to re-add them, hence the failure code. Finally, I was able to resolve the issue after replacing the web.config files by web.config.default in both the locations (x86/x64 <C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG  and C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG>. When I replaced the web.config with the default one, this allowed WFServicesReg to proceed as the elements weren’t there to begin with. The Microsoft .Net Framework 3.5 SP1 was installed successfully.

N.B.: Please take a back up of web.config files before replacing them. You may also have to repair applications which add custom entries in web.config files.

Recently we worked on an interesting issue with a new installation of Visual Studio 2012. Where the IDE would open but trying create a new project or opening an existing project using the File > Open menu would fail with error an error message. Trying to use the Key board shortcut Ctrl + Shift + N would show the same dialog box with the following error message.

---------------------------
Microsoft Visual Studio
---------------------------

Failed to create a 'ImageSource' from the text '..\Images\Medium.png'.

---------------------------
OK
---------------------------

Note: Most of the error message dialog boxes allow the txt to be copied. Just press Ctrl + C to copy the text and then paste in email or notepad.

In this scenario, customer had Visual Studio 2008 and Visual Studio 2010 installed on the machine earlier. Then he said Visual Studio 2012 was installed. It was working fine, until he installed the Office 2013.

Per discussion, the picture viewing software got affected. He mentioned that the Print Screen copy and paste into the MS word would not work etc.

While searching on the internet we came across the following two links.

http://stackoverflow.com/questions/12257817/visual-studio-2012-failed-to-create-project

http://www.fastpictureviewer.com/forum/viewtopic.php?f=11&p=3806

On examining the computer we found that the computer had “FastPictureViewer Codec Pack 2.4” installed on the machine.

Latest version of the “FastPictureViewer” mentioned here on the web site http://www.fastpictureviewer.com/codecs/ is “FastPictureViewer” 3.4.

We discussed about the issue and as it was not very clear how this “FastPictureViewer Codec Pack 2.4” got installed on the machine. As there was no requirement we decided to uninstall the Viewer.

That required the machine to restarted for clean uninstall.

Once the machine was restarted, the Visual Studio IDE 2012 issue was resolved. There were no error messages shown on the IDE start.

Possibly, installing the “FastPictureViewer Codec Pack 3.4” could also be able to resolved the issue if Code pack is need.

Happy coding!!

ISSUE DESCRIPTION:

Visual Studio 2010 throws package load errors on launch and creation of new project in fails with more errors

ENVIRONMENT:

This is applicable to both 32 bit and 64 bit machines, running Windows 8/Widows 7/ Server 2012/ Server 2008/ Windows Server2003/ Windows XP

Symptom and inference:

Here is the error message that you will notice on launching Visual Studio:

Also, when you still go ahead and try to create a new project, it immediately fails with these error messages:

This happens because of Visual Studio is trying to load extensions that do no exist on the machine! (Well, at least not at the path that it is looking at).

Also, you will notice that in the IDE the Extension manager cannot be accessed. You get this error:

Resolution:

To resolve this, navigate following registry key, and make sure that the given paths (string values listed under this key) are valid.

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\ExtensionManager\EnabledExtensions

Alternately, you can just disable the extension if path does not exist if you are unsure of what the exact path needs to be. Later of course you can get this extension installed back again.

Here is how I was able to reproduce the issue, by prefixing the key under EnabledExtensions with ‘old_’

Content by

Ritwik Sinha

ISSUE DESCRIPTION: The installation of .NET Framework 3.5 SP1 fails with errors 1714 and 1612 on a machine that already has .NET Framework 3.5 installed (with corresponding source files missing under the installer cache).

ENVIRONMENT: Windows Server2003/ Windows XP

Symptom and inference:

The installation of .net framework 3.5 sp1 fails during the installation.

Having enabled windows installer verbose logging on the machine (http://support.microsoft.com/kb/223300) you will see the following as part of the newly formed .net framework 3.5 sp1 failed installation log:

----------------------------------------------------------------------------------------------------------------

MSI (s) (24:FC) [02:54:11:910]: Note: 1: 2203 2:  3: -2147287037
MSI (s) (24:FC) [02:54:11:910]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
MSI (s) (24:FC) [02:54:11:910]: Note: 1: 1706 2: -2147483647 3: Netfx20a_x86.msi
MSI (s) (24:FC) [02:54:11:910]: SOURCEMGMT: Processing URL source list.
MSI (s) (24:FC) [02:54:11:910]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (s) (24:FC) [02:54:11:910]: Note: 1: 1706 2: -2147483647 3: Netfx20a_x86.msi
MSI (s) (24:FC) [02:54:11:910]: Note: 1: 1706 2:  3: Netfx20a_x86.msi
MSI (s) (24:FC) [02:54:11:910]: SOURCEMGMT: Failed to resolve source
MSI (s) (24:24) [02:54:11:910]: Note: 1: 1714 2: Microsoft .NET Framework 2.0 Service Pack 2 3: 1612 MSI (s) (24:24) [02:54:11:957]: Product: Microsoft .NET Framework 2.0 Service Pack 2 -- Error 1714.The older version of Microsoft .NET Framework 2.0 Service Pack 2 cannot be removed.  Contact your technical support group.  System Error 1612.

Error 1714.The older version of Microsoft .NET Framework 2.0 Service Pack 2 cannot be removed.  Contact your technical support group.  System Error 1612.
MSI (s) (24:24) [02:54:11:957]: User policy value 'DisableRollback' is 0
MSI (s) (24:24) [02:54:11:957]: Machine policy value 'DisableRollback' is 0
Action ended 2:54:11: RemoveExistingProducts. Return value 3.

----------------------------------------------------------------------------------------------------------------

.NET Framework 3.5 SP1 is a major upgrade for .NET Framework 3.5 and so it tries to remove the older version i.e .NET Framework 3.5 during the installation.

.NET Framework 3.5 is a cumulative update for .NET Framework  2.0 SP1 , .NET Framework 3.0 SP1 and .Net Framework 3.5, where in .Net Framework 3.5 SP1 is the cumulative update for the .NET framework 2.0 SP2, .NET Framework 3.0 SP2 and .NET Framework 3.5 SP1.
So during the installation of .NET 3.5 SP1, it tries to uninstall .NET 2.0 SP1 , .NET 3.0 SP1 and .NET 3.5, however it was unable to do so due to missing source file from the installer cache evident by:

MSI (s) (24:FC) [02:54:11:910]: SOURCEMGMT: Failed to resolve source

RESOLUTION: To fix the issue, one needs to remove the .NET Framework 3.5, .NET Framework 3.0 SP1 , .NET Framework 3.5 using the .NET framework removal tool or the Uninstall utility.

Content by: Keshav Deo Jain

You may find the below error message while trying to create or build a VC++ (Win32/MFC/ATL) project in Microsoft Visual Studio 2012:

MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file.

Please check the following reg keys (I printed what should be there and nothing else):

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0]  
"MSBuildToolsPath"="C:\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\"    
"MSBuildToolsRoot"="C:\\Windows\\Microsoft.NET\\Framework64\\"     
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0A@InstallationFolder)"     
"MSBuildRuntimeVersion"="4.0.30319"     
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0A\\WinSDK-NetFx40Tools-x86@InstallationFolder)"     
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0A\\WinSDK-NetFx35Tools-x86@InstallationFolder)"     
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\MSBuild\\ToolsVersions\\4.0@MSBuildToolsPath)"     
"VCTargetsPath"="$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0]  
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A@InstallationFolder)"    
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\WinSDK-NetFx40Tools-x86@InstallationFolder)"     
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\WinSDK-NetFx35Tools-x86@InstallationFolder)"     
"WindowsSDK80Path"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0@InstallationFolder)"     
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\v110\\'))"     
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"     
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"     

If the above settings are already set properly, then check if you have VCTargetsPath set as a global environment variable. If it is set system wide, then  remove it as this is what might cause the above issue. On my system it was set as mentioned below:

VCTargetsPath=C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0

Microsoft Visual Studio 2012 Setup may fail on Windows 7 system with the below error screenshot:

As per the Setup failure log (dd_vs_***_58*****875_vs_professionalcore.log):

MSI (s) (A4:48) [18:08:37:579]: Executing op: CustomActionSchedule(Action=RollbackHttp.992B75DB_179A_4B48_B260_9FD0862C9A76,ActionType=3329,Source=BinaryData,Target=Uninstall,)
MSI (s) (A4:48) [18:08:37:580]: Executing op: ActionStart(Name=ReserveHttp.992B75DB_179A_4B48_B260_9FD0862C9A76,,)
MSI (s) (A4:48) [18:08:37:581]: Executing op: CustomActionSchedule(Action=ReserveHttp.992B75DB_179A_4B48_B260_9FD0862C9A76,ActionType=3073,Source=BinaryData,Target=Install,)
MSI (s) (A4:A8) [18:08:37:605]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIA1BF.tmp, Entrypoint: Install
04/15/13 18:08:37 DDSet_Entry: WcfToolsInstall
04/15/13 18:08:37 DDSet_Status: HttpReservation::PerformInstall
04/15/13 18:08:37 DDSet_Status: HttpReservation::IsInstalled
04/15/13 18:08:37 DDSet_Status: HttpLibrary::HttpInitialize
MSI (s) (A4!E8) [18:08:37:646]: Product: Microsoft Visual Studio Professional 2012 -- 04/15/13 18:08:37 DDSet_Error: Internal error: 1060.

I tried the below steps:

C:\>netsh http show urlacl

URL Reservations:
-----------------
The handle is invalid.

C:\>net start http
The service name is invalid.

I ran httpcfg.exe tool http://technet.microsoft.com/en-us/library/cc787508%28WS.10%29.aspx

c:\>httpcfg.exe set urlacl -u http://+:80/Temporary_Listen_Addresses/ -a DSadA;;GX;;;WD)

HttpInitialize failed with 1060.

C:\>net helpmsg 1060
The specified service does not exist as an installed service.

So I checked the HTTP driver properties and found that both Start & Stop buttons were disabled as shown below:

To open HTTP driver properties, please follow the steps indicated below: 

1. Open Device Manager.
2. Click the View menu, and then click Show hidden devices.
3. In the list of devices, double-click Non-Plug and Play Drivers, right-click the device you want, and then click Properties.
4. On the Driver tab, click Start or Stop, and then click OK.

The above issue clearly indicated HTTP driver was not functional. After further debugging, I found that it was due to missing 32 bitStartDWORD value in the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP (below screenshot). Hence, I created it manually and rebooted the system.

Then I was able to install the Microsoft Visual Studio 2012 successfully on the system.

While working on a recent customer case, we observed the following error message, MSBuild.exe is not a valid Win32 application.

Issue Description:

A project is build using the MSBuild.exe and the following error message is shown.

OS Environment:

Windows 7/Server 2008 R2/ Windows XP/ Server 2003 R2/ Server 2003 (with .NET Framework 4.0 Full installed)

Symptom and inference: 

We started the troubleshooting by checking the size, digital signature and other attributes of the file “C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe”. In our case size of the file was 0 KB. Verified the same file in the other folder “C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe” and found the size was 129 KB (132,432 bytes). Which clearly indicates that the file ‘MSBuild.exe’ was corrupted.

Solution:

In order to fix this issue, the file was renamed to “MSBuild.exe.old” and then we started the repair of .NET Framework 4.0 Client Profile from ‘Programs and Features’. This process was able to replace the corrupted MSBuild.exe file with a new one.

A computer reboot may be necessary, if prompted by the setup, the computer must be restarted.

Verification:

The build process worked as expected after the repair and reboot.

Content by:
Keshav Jain.

While working on customer case, I came across an interesting issue with an application deployed using ClickOnce.

Issue Description:

A custom deployment of ClickOnce application starts the reinstallation process every time the user logs off and logs back again.

Cause:

We worked on the machine and found the following registry key that belongs to the ClickOnce isolation store was getting deleted during each logoff.

HKEY_CURRENT_USER\Software\Classes\Software\Microsoft\Windows\CurrentVersion\Deployment\SideBySide\2.0\PackageMetadata

When the user is logged in, a handle is created for the HKCU\Software\Classes hive, if a logoff could not unload this hive properly, it might get corrupted or hold incorrect data. This leads to get the corrupted data loaded back during logon.

In our case there was a problem with a single User Profile. These registry keys were getting removed or modified and was triggering the re-installation.

In a normal scenario, these registry keys do not get removed or modified, that provides the persistence to the application deployed using ClickOnce. In other words no re-installation occurs until there is a new update that is available and needs to be installed.

Possible Resolution: 

System processes and applications occasionally maintain connections to registry keys in the UserProfile, even after a user logs off. In such cases, the user session fails to end entirely. When you use roaming user profiles in a network environment, this can result in problems like deletion or modification of registry hives.

To resolve this problem, install Microsoft User Profile Hive Cleanup Service (UPHClean). UPHClean monitors the computer while you log off, and then UPHClean unloads UserProfiles. The User Profile Hive Cleanup service helps us to make sure that user sessions are completely ended when a user logs off. (http://msdn.microsoft.com/en-us/library/aa910532.aspx)

The User Profile Hive Cleanup service monitors for users who have logged off and for whom registry hives are still loaded. When this occurs, the service determines which applications have handles that are opened to the hives and releases them. It logs the application name and what registry keys were left open. After this occurs, the system finishes unloading the profile.

For more information and for installing User profile Hive cleanup service we recommend the following KB: http://support.microsoft.com/kb/837115

Content by: Ajith Thomas

This week we worked on a customer case, where we found that the computer was being scanned vulnerable by Microsoft Base Line Security Analyzer tool (MBSA 2.2).

Issue Description:

MBSA 2.2 scanning tool is reoffering KB2538243, even though it has been already installed on the machine.

Cause:

We worked on computer and found that the VC ++ Security update KB2538243 provided as a part of Security bulletin MS11-025 was getting reoffered.

Security Bulletin page: http://technet.microsoft.com/en-us/security/bulletin/ms11-025

KB describing the file versions: http://support.microsoft.com/kb/2538243

Link to download files: http://www.microsoft.com/en-us/download/details.aspx?id=26368

Resolution: 

Since the computer was x64 bit OS, the customer had only installed the x64 file from the download page. Though the installation looked OK(as per the verbose logs located under the %temp% folder), the MBSA would still say that the update is missing.

Going back to the download page, we found three types of installer files: x86, x64 and IA64.

With the OS in this case having an X64 architecture, we could have both x86 and x64 editions of Visual C++ redistributables installed on the machine. Visual C++ is a commonly used component for various applications and it is normal to have 32 bit and 64 bit runtime installed on a 64 bit system.

Since the customer had only one version of the VC++ installed, they were being offered KB2538243 to be installed on the computer.

We decided to download both the x86 and x64 versions of the VC++ runtime and installed it. Once both were installed, the MBSA did not show the vulnerability anymore.

Content by: Ajith Thomas

The Microsoft .Net Framework 3.5 SP1 /2.0 SP2 Setup may fail without any error message or the setup may crash almost at the end. You can find the below error messages in the log file:

  MSI (s) (00:C8) [10:09:41:999]: Executing op: CustomActionSchedule(Action=CA_InstallAssemblyDef.3643236F_FC70_11D3_A536_0090278A1BB8,ActionType=1025,Source=BinaryData,Target=InstallAssembly,CustomActionData=c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\IEExecRemote.dll;8192)

MSI (s) (00:DC) [10:09:42:092]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI20D.tmp, Entrypoint: InstallAssembly

04/18/13 10:09:42 DDSet_Status: LANGID: 1033

04/18/13 10:09:42 DDSet_Entry: InstallAssembly started

04/18/13 10:09:42 DDSet_Status: CustomActionData: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\IEExecRemote.dll;8192

04/18/13 10:09:42 DDSet_Status: Loading mscoree.dll

04/18/13 10:09:42 DDSet_Status: Loading fusion.dll using LoadLibraryShim()

04/18/13 10:09:42 DDSet_Error: Failed to install assembly c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\IEExecRemote.dll. IAssemblyCache->InstallAssembly() returned -2147024614.

04/18/13 10:09:42 DDSet_Error: Failed to install assembly 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\IEExecRemote.dll' because of system error: The mounted file system does not support extended attributes.

 The error code -2147024614 means   ERROR_EAS_NOT_SUPPORTED # the mounted file system does not support extended attributes

 I captured a procmon trace http://technet.microsoft.com/en-in/sysinternals/bb896645.aspx and after reviewing the procmon, I found that the failure occurs when performing FSCTL_SET_REPARSE_POINT on the GAC directory for IEExecRemote.dll:

 11:03:52.4649173AM      MsiExec.exe      3888       FileSystemControl          328                C:\WINDOWS\assembly\GAC_MSIL\IEExecRemote\2.0.0.0__b03f5f7f11d50a3a EAS NOT SUPPORTED     Control: FSCTL_SET_REPARSE_POINT

The reparse points are used in hard links (and possibly directory junctions). A hard link is a directory entry that associates a name with a file on a file system. The Hard link is used between win32 assemblies in WinSxS and this particular assembly has a win32 manifest, so that could be why this is happening.  None of the previously successfully installed assemblies have win32 manifests, and I found none of them setting reparse points. So we tried to create a hard link on this drive and see if that is supported. In order to do the same I used the tool called junction.exe http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx

 C:\>junction.exe c:\test1 c:\test

 Error setting junction for c:\test1:

The mounted file system does not support extended attributes.

 I also took a procmon trace while running the junction.exe and found the similar behavior like .Net Framework install 

  06:28:28.2800295 PM        junction.exe      3512       FileSystemControl           C:\test1                EAS NOT SUPPORTED     Control: FSCTL_SET_REPARSE_POINT      domain\user1                00000000:0001e183        0

It had the below stack:

 0              fltmgr.sys            fltmgr.sys + 0x24ca          0xf734c4ca          C:\WINDOWS\System32\Drivers\fltmgr.sys

1              fltmgr.sys            fltmgr.sys + 0x3f2a          0xf734df2a          C:\WINDOWS\System32\Drivers\fltmgr.sys

2              fltmgr.sys            fltmgr.sys + 0x48d2         0xf734e8d2         C:\WINDOWS\System32\Drivers\fltmgr.sys

3              fltmgr.sys            fltmgr.sys + 0x12693       0xf735c693          C:\WINDOWS\System32\Drivers\fltmgr.sys

4              ntoskrnl.exe      ntoskrnl.exe + 0x401d3 0x808401d3        C:\WINDOWS\system32\ntoskrnl.exe

5              ntoskrnl.exe      ntoskrnl.exe + 0x12c3f9                0x8092c3f9          C:\WINDOWS\system32\ntoskrnl.exe

6              ntoskrnl.exe      ntoskrnl.exe + 0x12c32e               0x8092c32e         C:\WINDOWS\system32\ntoskrnl.exe

7              ntoskrnl.exe      ntoskrnl.exe + 0x1397ef               0x809397ef         C:\WINDOWS\system32\ntoskrnl.exe

8              ntoskrnl.exe      ntoskrnl.exe + 0x33c3f  0x80833c3f          C:\WINDOWS\system32\ntoskrnl.exe

9              junction.exe      junction.exe + 0x294a    0x40294a             C:\1A1\Net Updates\19APR\Junction\junction.exe

The error message comes from STATUS_EAS_NOT_SUPPORTED => ERROR_EAS_NOT_SUPPORTED.  This is the error code returned by NTFS when you try to set a reparse point on a file that already has EAs on it.  (Reparse points and EAs cannot coexist on the same file.) Hence, I generated the list of file system filters present on the system.  So we ran the below command:

C:\>fltmc   filters

Filter Name                     Num Instances           Frame

------------------------------ ---------------------          ----------

EzWatch                                    1                              1

BHDrvx86                                  1                              1

eeCtrl                                       1                               1

SRTSP                                       3                               1

DfsDriver                                                      <Legacy>

SymEFA                                   3                                0

C:\>fltmc instances

Filter                         Volume Name                    Altitude                         Instance Name

--------------               ---------------------                 -------------                      -----------------------

EzWatch                        C:                                    370030                           EzWatch Instance

BHDrvx86                       C:                                    365100                              BHDrvx86

eeCtrl                             C:                                    329010                              eeCtrl

SRTSP                             C:                                    329000                              SRTSP

SRTSP             \Device\LanmanRedirector       329000                              SRTSP

SRTSP                        \Device\RdpDr                  329000                              SRTSP

SymEFA                         C:                                     260600                              SymEFA

SymEFA          \Device\LanmanRedirector       260600                              SymEFA

SymEFA                     \Device\RdpDr                  260600                              SymEFA

In the above list DfsDriver is the only filter driver which is owned by Microsoft and the remaining all are Third party filter drivers. We tried removing the filters one at a time and after each removal and tried the junction scenario until we find when it stops working. In order to remove the filter driver, I opened an Admin command prompt and ran the below commands:

 For EzWatch

sc config EzWatch  start=  disabled

For BHDrvx86

sc config bhdrvx86 start=  disabled

For eeCtrl

sc config eectrl start=  disabled

For SRTSP:

sc config srtsp start=  disabled

For SymEFA

sc config symefa start=  disabled

In this way I found that EzWatch was the file system filter driver which caused setting the junction though the file system was NTFS. In the same way it caused the .Net Framework Setup failure. Disabling EzWatch filter driver resolved the issue.

To re-enable them the process is similar, just use start=  system

For example: sc config bhdrvx86 start=  system  

Also we can make the above changes in the registry in this path for each driver by changing their start value from 0 (boot) or 1 (system) to 4 (disabled): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services

Issue Description:

Installation of VC++ 2005/2008 fail with 0x80070005 Assembly Error:Access is denied issue

MSI (s) (54:80) [13:56:14:694]: Assembly Error:Access is denied.

MSI (s) (54:80) [13:56:14:694]: Note: 1: 1935 2: {97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E} 3: 0x80070005 4: IAssemblyCache 5: CreateAssemblyCacheItem 6: Microsoft.VC80.ATL,type="win32",version="8.0.50727.4053",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86"

Root Cause:

When we search for ‘value 3’ in the VC++ 2005 error log it gives the below error message

MSI (s) (54:80) [13:56:14:694]: Executing op: AssemblyCopy(SourceName=b3t3z6j5.7ag|x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_473666fd.manifest,SourceCabKey=ul_manifest.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E,DestName=x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_473666fd.manifest,Attributes=16384,FileSize=466,PerTick=32768,,VerifyMedia=1,ElevateFlags=4,,,,ComponentId={97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E},IsManifest=1,,,AssemblyMode=0,)

MSI (s) (54:80) [13:56:14:694]: Assembly Error:Access is denied.

MSI (s) (54:80) [13:56:14:694]: Note: 1: 1935 2: {97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E} 3: 0x80070005 4: IAssemblyCache 5: CreateAssemblyCacheItem 6: Microsoft.VC80.ATL,type="win32",version="8.0.50727.4053",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86"

Which means the ‘System’ account installing the VC++ MSI isn’t having access on the Assemblycache folder. A procmon log should show the folder which is “C:\Windows\Winsxs\Installtemp” folder

Resolution:

1. Give “Full Control” to the “System” account on “C:\Windows\Winsxs\Installtemp”

2. After this the installation of VC++ 2005 should be successful on the machine

Content By : Sarat Chandra

ISSUE DESCRIPTION:

Failing installation of .net framework 3.5 sp1 with existing mscoreee.dll file version being 4.0

ENVIRONMENT:

This is applicable to both 32 bit and 64 bit machines, running Windows Server2003/XP

Symptom and inference:

It may so happen on a server 2003/XP machine where .net framework 4.0 has been uninstalled earlier, that the ‘mscoree.dll’ file gets left out at C:\Windows\System32, and is still of 4.0 version.

In this case the installation of .net framework 3.5 sp1 fails as it is unable to replace the higher version mscoree.dll file with a lower version one.

Having enabled windows installer verbose logging on the machine (http://support.microsoft.com/kb/223300) you will see the following as part of the newly formed .net framework 3.5sp1 failed installation log:

09/21/12 21:17:36 DDSet_Status: Loading mscoree.dll

09/21/12 21:17:36 DDSet_Status: Loading fusion.dll using LoadLibraryShim()

09/21/12 21:17:36 DDSet_Error: Error occurred while initializing fusion. Setup could not load fusion with LoadLibraryShim(). Error: 0x80131700

MSI (s) (7C!58) [21:17:37:003]: Product: Microsoft .NET Framework 2.0 Service Pack 2 -- Error 25007.Error occurred while initializing fusion. Setup could not load fusion with LoadLibraryShim(). Error: 0x80131700

Error 25007.Error occurred while initializing fusion. Setup could not load fusion with LoadLibraryShim(). Error: 0x80131700

09/21/12 21:17:37 DDSet_CARetVal: 25007

09/21/12 21:17:37 DDSet_Exit: InstallAssembly ended with return value 1603

MSI (s) (7C:84) [21:17:37:065]: User policy value 'DisableRollback' is 0

MSI (s) (7C:84) [21:17:37:065]: Machine policy value 'DisableRollback' is 0

Action ended 21:17:37: InstallExecute. Return value 3.

Resolution:

The resolution is simple really: you need to rename (or delete) the existing mscoree.dll file from under the C:\System32 folder and then retry the installation of .net framework 3.5 sp1

Content By : Ritwik Sinha

ISSUE DESCRIPTION:

Installation of .net framework updates like KB2657424 failing as ‘web.config’ file has Read Only (RO) attribute

ENVIRONMENT:

This is applicable to both 32 bit and 64 bit machines, running Windows 8/Widows 7/ Server 2012/ Server 2008/ Windows Server2003/ Widows XP

Symptom and inference:

The installations of .net framework 3.5 sp1 updates such as kb2657424 fail during installation.

Having enabled windows installer verbose logging on the machine (http://support.microsoft.com/kb/223300) you will see the following as part of the newly formed .net framework 3.5sp1 failed installation log:

01/30/12 12:55:04 DDSet_Entry: RunProcess started

01/30/12 12:55:04 DDSet_Status: CustomActionData: "C:\WINDOWS\Microsoft.NET\Framework\v3.5\WFServicesReg.exe" /c /v /m /i

DDSet_Entry: WFServicesReg.exe

DDSet_Status: CFxInstaller::CopyConfigFilesToTemp is64bit=0

DDSet_Status: CFileHelper::CopyConfigFilesToTempLocation

DDSet_Error: CFileHelper::CheckIsWriteable C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\web.config is read only.

DDSet_Error: _fileHelper->CopyConfigFilesToTempLocation failed. Error code: 0x80004005

DDSet_Error: Failed to copy config files to temp directory. Error code: 0x80004005

DDSet_CARetVal: -2147467259

DDSet_Exit: WFServicesReg.exe

01/30/12 12:55:04 DDSet_Status: Process returned -2147467259

01/30/12 12:55:04 DDSet_Error: The Commandline '"C:\WINDOWS\Microsoft.NET\Framework\v3.5\WFServicesReg.exe" /c /v /m /i' returned non-zero value: -2147467259.

01/30/12 12:55:04 DDSet_CARetVal: -2147467259

01/30/12 12:55:04 DDSet_Exit: RunProcess ended

MSI (s) (1C:94) [12:55:04:608]: User policy value 'DisableRollback' is 0

MSI (s) (1C:94) [12:55:04:608]: Machine policy value 'DisableRollback' is 0

Action ended 12:55:04: InstallExecute. Return value 3.

As is evident from the above lines, the issue is with the web.config file at location C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG

The file has been marked as read only, because of which it is not possible for the update installation to modify the contents of the file in any way, and hence you see the installation failure.

Resolution:

Navigate to C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG. Under the properties of the web.config file, read only attribute needs to be unchecked. Running the update installation again will go through (unless there are other unrelated issues!)

Content By  : Ritwik Sinha

You would receive the below error message while running a ClickOnce bootstrapper created using Visual Studio 2012 on Windows XP systems.

Clickonce bootstrapper engine (setup.exe) that was shipped with Visual Studio 2012 is NOT compatible with any OS below Windows Vista.  So, the above error message is expected and by design. The reason for this behavior is because the bootstrapper is compiled using the VC compiler and the Dev11 VC compiler does not support Windows XP.  

So the workaround is to install all the prerequisites manually and launch the ClickOnce application directly from deployment manifest file (.application). Another workaround would be to create a sample ClickOnce application using Visual Studio 2010 OR Visual Studio 2008 with the same name as mentioned in Visual Studio 2012 and publish it. From the published location take the setup.exe bootstrapper and replace the existing setup.exe bootstrapper created using Visual Studio 2012

Microsoft VC development team has done work to make VC compilers work on Windows XP in Visual Studio 2012 Update 1 CTP 3http://www.microsoft.com/en-us/download/details.aspx?id=34818 This Visual Studio 2012 Update 1 CTP 3 patch provides an opportunity to users in building VS2012 C++ project for Win XP OS. For the users who want to develop their applications using Dev11 VC compiler (v110) for Windows XP OS, would need to install Visual Studio 2012 Update 1 CTP 3 patch.

MSI package having multi files custom merge module fails to install after applying a localized transform. You would find the below error message:
"Error 1334. The file '_xxxxxxxxxxxxxxxxxxxxxxxxxxx' cannot be installed because the file cannot be found in cabinet file '_ xxxxxxxxxxxxxxxxxxxxxxxxxxx'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package."

The above error occurs only when the packaged merge module contains more than one file.

From the install log:

MSI (s) (A4:B0) [14:19:12:558]: Executing op: FileCopy(SourceName=AREACODE.XML|AreaCode.xml,SourceCabKey=areacode.xml.DA3A9EE8_BE02_4989_9F57_339E53042965,DestName=AreaCode.xml,Attributes=16384,FileSize=25657,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=1207937628,HashPart2=-1026001738,HashPart3=-895601004,HashPart4=-1186834295,,)

MSI (s) (A4:B0) [14:19:12:558]: File: C:\Program Files (x86)\Microsoft\Setup1\AreaCode.xml; To be installed; Won't patch; No existing file

MSI (s) (A4:B0) [14:19:12:558]: Source for file 'areacode.xml.DA3A9EE8_BE02_4989_9F57_339E53042965' is compressed
InstallFiles: File: AreaCode.xml,  Directory: C:\Program Files (x86)\Microsoft\Setup1\,  Size: 25657
MSI (s) (A4:B0) [14:19:12:558]: Note: 1: 1334 2: areacode.xml.DA3A9EE8_BE02_4989_9F57_339E53042965 3: _91DACBF5642025AC8F7CAA5A857CF149
MSI (s) (A4:B0) [14:19:12:558]: Note: 1: 2262 2: Error 3: -2147287038
MSI (c) (58:70) [14:19:12:574]: Note: 1: 2262 2: Error 3: -2147287038

Error 1334. The file 'XXX.DA3A9EE8_BE02_4989_9F57_339E53042965' cannot be installed because the file cannot be found in cabinet file '_91DACBF5642025AC8F7CAA5A857CF149'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.

I observed that when the transform is applied in ORCA, the file sequencing is changed for the files packaged under merge module.During application of transform the sequence changes while the media will be of base MSI package , hence the failure. To avoid this either keep the sequence same during creating of localized MSI or manually edit the transform after using msitrans.exe. If the file table has large number of entries then you may export file table from base MSI package and import it in localized MSI package

You may receive an error message "Error 1606.Could not access network location” while installing the recent release of 1.1 security patch (KB2698023)  

How do you detect the issue
·         Open %temp% and look for the installation log for that patch - NDP1.1Sp1-KB2698023-X86-MSI**.log
·         Search for this error "Error 1606.Could not access network location”

Workaround
     If you find the above error in the log, then please install "Microsoft Fix it 50356" http://go.microsoft.com/?linkid=9708107
     If the issue still occurs, please share the log file NDP1.1Sp1-KB2698023-X86-MSI**.log for further analysis.

Another way to confirm this issue is to check the registry keys
·         HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
·         HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

For HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\AppData

Correct value : %USERPROFILE%\AppData\Roaming
Incorrect value that may cause failure : %APPDATA%

If you find any other issues with the current patch please share the log file. You can provide me log files from the machine as mentioned below:
1.  Download and run this diagnostic tool from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=e0da314f-6216-4a18-bc6b-7d29cf83af20&displaylang=en
2.  Share the log generated by this tool: %temp%\vslogs.cab
3.  Also please send us the information like OS and SP Level on this machine.

When you try to install a ClickOnce application on Windows 8 OS, it is intercepted by the SmartScreen filter. It would show the below screenshot:

Though the application is signed with a certificate from Verisign, still the publisher name is displayed as unknown. SmartScreen dialog should be the same as for any other executable, with a "More Info" option, and "Run Anyway" button. Windows SmartScreen alerts users before running unrecognized programs downloaded from the Internet. Microsoft has extended the SmartScreen feature of Internet Explorer to Windows as well to protect users from malware. In general, SmartScreen Protection shows the above message when you try to run a newly released program or an application that has not yet established a reputation. Even though one can easily disable the SmartScreen Protection feature in Windows 8, we don’t advise you to turn off the protection.

In addition to Strong Name signing the assembly, which VS offers support for (via project property pages), you will need to Authenticode sign.  There is no direct support for Authenticode signing from Visual Studio; however, it’s easy to add as a post-build step, like so, by inserting these lines into your project file:

  <Target Name="BeforePublish">

    <Exec Command="&quot;$(WindowsSdkDir)bin\signtool.exe&quot; sign
/f &quot;path_to_your_certificate&quot;
/d signed_content_description
/du signed_content_URL
/t http://timestamp.(vendorwebsite)
/v &quot;path_to_your_exe (in the obj\$(ConfigurationName) directory)&quot;"   />

  </Target>

The /d is a string description and /du is an url that points to additional description. These two are optional parameters.

Example:

<TargetName="BeforePublish">

 <ExecCommand="&quot;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\signtool.exe&quot; sign /f &quot;MyCert.pfx&quot; /p &quot;password&quot; /t http://timestamp.verisign.com/scripts/timstamp.dll &quot;C:\Projects\obj\Release\App.exe&quot;" />

</Target>

Once this is done, the SmartScreen will continue to warn about the application until the certificate develops a reputation. But it would display a valid publisher name instead of unknown publisher.

The .Net Framework 2.0 SP2/3.5 SP1 fails/crashes immediately after running the Setup on Windows 2003 systems. As per the failure verbose log ( How to Enable Microsoft Installer logging ):

=== Verbose logging started: 1/14/2013  5:35:52  Build type: SHIP UNICODE 4.05.6001.00 Calling process: c:\6449087192a6054b8a1d78bb6c\setup.exe ===

MSI (c) (CC:50) [05:35:53:460]: Original package ==> c:\6449087192a6054b8a1d78bb6c\vs_setup.msi
MSI (c) (CC:50) [05:35:53:460]: Package we're running from ==> c:\6449087192a6054b8a1d78bb6c\vs_setup.msi
MSI (c) (CC:50) [05:35:53:476]: APPCOMPAT: looking for appcompat database entry with ProductCode '{C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F}'.
MSI (c) (CC:50) [05:35:53:476]: APPCOMPAT: no matching ProductCode found in database.
MSI (c) (CC:50) [05:35:53:538]: MSCOREE not loaded loading copy from system32
MSI (c) (CC:34) [05:35:53:570]: Windows Installer proxy information not correctly registered
MSI (c) (CC:34) [05:35:53:570]: Failed to connect to server. Error: 0x80004005
MSI (c) (CC:50) [05:35:53:570]: Failed to get IMsiCustomAction*

Another type of log snippet:
MSI (s) (64:9C) [11:07:37:574]: Internal Exception during install operation: 0xc0000005 at 0x0094D0F5.
MSI (s) (64:9C) [11:07:55:209]: Crash report directed to WER.
MSI (s) (64:9C) [11:07:55:209]: Internal MSI error. Installer terminated prematurely.
MSI (s) (64:9C) [11:07:56:781]: MainEngineThread is returning 1603

The Windows Installer executes an installation in two distinct processes.  One is a client process and the other is a server process.  The log file will show the installation information for both processes.  In a typical verbose log file, you will see lines like the following for a line that denotes the information presented was done on the client context of the installation:
        MSI(c)(29:28) : Resetting cached policy values

In a typical verbose log file, you will see lines like the following for a line that denotes the information presented was done on the server process of the installation:
        MSI(s) (A0:EC): Original package ==> D:\TEMP\Default.msi

So it was unable to connect to the server process. Surprisingly, The .Net Framework 2.0 RTM gets installed successfully on the same system. Even other MSI packages are also installed successfully. After debugging the issue, I found the above issue occurs due to a bug with Windows Installer 4.5. If the hotfix 972397 is installed on your system, this issue would occur. In order to resolve the issue, please install this hotfix http://support.microsoft.com/kb/983280

While running a ClickOnce 4.5 application, you may receive the below error message:

Once you click on Details… button, it will popup the log file where you can find the below exception:

Following failure messages were detected:
  + Exception reading manifest from file://XXX/ClickOnce/MyApplication.application: the manifest may not be valid or the file could not be opened.
  + Manifest XML signature is not valid.
  + SignatureDescription could not be created for the signature algorithm supplied.

--- Inner Exception ---
  System.Security.Cryptography.CryptographicException
  - SignatureDescription could not be created for the signature algorithm supplied.
  - Source: System.Security
  - Stack trace:
   at System.Security.Cryptography.Xml.SignedXml.CheckSignedInfo(AsymmetricAlgorithm key)
   at System.Security.Cryptography.Xml.SignedXml.CheckSignature(AsymmetricAlgorithm key)
   at System.Security.Cryptography.Xml.SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm& signingKey)
   at System.Deployment.Internal.CodeSigning.SignedCmiManifest.Verify(CmiManifestVerifyFlags verifyFlags)
   at System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream s)

The above issue occurs due to the MyApplication.application file,  the hash for that file was generated using SHA-256 algorithm.  You can find the following tag Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha256" /> in the application manifest file.  For more information, please go through the document: http://msdn.microsoft.com/en-us/library/92f9ye3s.aspx#clickonce

This change is due to the fact that we stopped using legacy certificates as default (SHA-1) in NetFX4.5 to sign manifest and instead, use newer version (SHA-256), which is not recognized by NetFx4.0 runtime. Therefore, while parsing the manifest, 4.0 runtime complains of an invalid manifest. For legacy frameworks, when we try to run a ClickOnce app on a box that does not have targeted runtime, ClickOnce pops up a message to user saying “you need xxxx.xx runtime to run this app”. But starting .NET 4.5, if a 4.5 ClickOnce app is run on the box with only .NET 4.0 installed, the message complains about an invalid manifest. In order to resolve the issue, you must install .Net Framework 4.5 on the target system.

Recently I found an issue with latest release of MS13-004 patch. MS13-004 patch for .Net 1.1 is re-offered on Windows XP systems even though patch files are updated successfully. I collected and reviewed the below logs but didn’t find any meaningful information on the re-offer issue.

“%temp%\NDP1.1sp1-KBXXXXXXX-X86\*.log"
OR
“%windir%\temp\NDP1.1sp1-KBXXXXXXX-X86\*.log"

MBSA and WSUS both have same detection logic as they have the same source. I tried the below scenario :

First, set the registry keys

To turn on verbose logging, add the following registry key with two values:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace
Value name: Flags
Value type: REG_DWORD
Value data: 000000016  <<< this is HEX 16

Value name: Level
Value type: REG_DWORD
Value data: 00000004   <<< make this as 4

•Have the system with .Net 1.1 SP1 and KB979906 installed.
•Scan Windows Update and see if KB2742597 gets offered first
•Scan Windows Update again and see if KB2742597 gets re-offered

Collect the logs:  %systemroot%\Windowsupdate.log file and “%temp%\NDP1.1sp1-KBXXXXXXX-X86\*.log"

Now, if I just uninstall KB979906 the version of mscorees.dll is reverted to the version that is stated in the http://support.microsoft.com/kb/2742597  article. Here is a screen shot of the file properties for mscorees.dll located in c:\windows\system 32\mui\0409 before and after I uninstalled KB979906:

Before uninstalling kb979906:

After uninstalling kb979906:


I did further investigation on this. Mscorees.dll not being updated by KB27425997 is by the design of MSI technology.  KB979906 transform shows mscorees.dll is 4.0.31106.0 and KB27425997 also shows mscorees.dll 4.0.31106.0.  This gives MSI the impression if mscorees.dll is installed by KB979906 before then it does not need to be installed by KB27425997 again.

 
Secondly, the end user’s machine should never end up with the state where shared component goes back to an older version. As long as KB979906 is on the box, mscorees.dll should have a version 4.0.31106.0 or higher. One possible reasons is that on those machines impacted, a different setup technology could have been used in order to install third-party software that touches mscorees.dll.  
 
That’s being said, the work-around  solution for those impacted machines, un-installing and re-installing KB979906 should do the trick. Another simple fix for this should be to repair .Net 1.1 after installing KB2742597. The repair command line:

msiexec /fomus {CB2F7EDD-9D1F-43C1-90FC-4F52EAE172A1}