“Error opening installation log file. Verify that the specified log file location exists and that you can write to it.” error when attempting to install any Setup package. For example, try installing any one of the below packages:

The Microsoft .Net Framework patch KB2972216      
The Microsoft Visual C++ 2008 Redistributable Package    
The Microsoft Forefront Endpoint Protection 

The sample error screenshots are displayed below:

There was a log file (dd_NDP45-KB2972216-x64_decompression_log.txt) in the user temp folder (%temp%) and I found the below information:

[3/15/2015, 10:40:28] Drive 'C:\' has been selected as the largest fixed drive     
[3/15/2015, 10:40:28] Directory 'C:\2d7a2b9d5ac9fde4e25b451fb755\' has been selected for file extraction      
[3/15/2015, 10:40:28] Extracting files to: C:\2d7a2b9d5ac9fde4e25b451fb755\      
[3/15/2015, 10:40:31] Extraction took 3.485 seconds      
[3/15/2015, 10:40:31] Executing command line: 'C:\2d7a2b9d5ac9fde4e25b451fb755\Setup.exe 

The subject error message appears to be an issue with NTFS file/folder permission. Hence, I ran a tool called Process Monitor. The procmon trace shows the failure. The MSI fails to write it’s log and that is what eventually kills the install.     
 
Setup.exe         1880       CreateFile           C:\Users\MyUser\AppData\Local\Temp\MSI3a3f7.LOG  ACCESS DENIED  Desired Access: Generic Write, Read Attributes, Disposition: Create, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: N, ShareMode: Read, AllocationSize: 0

User Mode Stack:
==============

18  KernelBase.dll    CreateFileW + 0x35e,   0x7578c5f7   C:\Windows\SysWOW64\KernelBase.dll
19  Kernel32.dll        CreateFileWImplementation + 0x69, 0x758f3f66 C:\Windows\SysWOW64\kernel32.dll
20  msi.dll   CMsiPath::TempFolderOrFile + 0x52e,   0x6f4b4739  C:\Windows\SysWOW64\msi.dll
21  msi.dll   CMsiPath::TempFileName + 0x2c,         0x6f4b4907   C:\Windows\SysWOW64\msi.dll
22  msi.dll   MsiUIMessageContext::InitializeLog + 0x601,  0x6f327ff2  C:\Windows\SysWOW64\msi.dll
23  msi.dll   MsiUIMessageContext::Initialize + 0x1da,     0x6f307d81   C:\Windows\SysWOW64\msi.dll
24  msi.dll   MsiUIMessageContext::RunInstall + 0x91,      0x6f308085  C:\Windows\SysWOW64\msi.dll
25  msi.dll   RunEngine + 0xe2,             0x6f308ed8  C:\Windows\SysWOW64\msi.dll
26  msi.dll   MsiInstallProductW + 0xa1, 0x6f39ee2c  C:\Windows\SysWOW64\msi.dll
27 SetupEngine.dll IronMan::MspInstallerT<IronMan::PatchesFilteredT <IronMan::CMsiInstallContext>>::Execute + 0x20d, 0x6f5abc76 C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
28 SetupEngine.dll IronMan::BaseMspInstallerT<IronMan::MsiExternalUiHandler, IronMan::PatchesFilteredT<IronMan::CMsiInstallContext> >::PerformMsiOperation + 0x323, 0x6f5a2643 C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
29 SetupEngine.dll IronMan::BaseMspInstallerT<IronMan::MsiExternalUiHand ler,IronMan::PatchesFilteredT<IronMan::CMsiInstallContext> >::PerformAction + 0x162,        0x6f5a2015   C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
30 SetupEngine.dll IronMan::CompositePerformerBaseT<IronMan::Performers <IronMan::MsiInstaller,IronMan::MspInstallerT<IronMan::Patches<IronMan::CMsiInstallContext> IronMan::RelatedProductsRepairer>,IronMan::Performers<IronMan::MsiUnInstallerT<IronMan: + 0x552, 0x6f5a3c62     C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
31 SetupEngine.dll IronMan::CompositePerformer::PerformAction + 0x1fa,  0x6f596f99  C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
32 SetupEngine.dll IronMan::NotifyController::ThreadProc + 0x12, 0x6f58aacc   C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
33 kernel32.dll    BaseThreadInitThunk + 0xe,  0x758f338a C:\Windows\SysWOW64\kernel32.dll
34 ntdll.dll __RtlUserThreadStart + 0x70,  0x77879f72  C:\Windows\SysWOW64\ntdll.dll
35 ntdll.dll _RtlUserThreadStart + 0x1b,  0x77879f45  C:\Windows\SysWOW64\ntdll.dll

 
I thought that there must be something busted with the ACL in the temp directory. So I ran Icacls.exe for the Temp folder:
C:\Users\MyUser\AppData\Local\>icacls Temp

Temp NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
           BUILTIN\Administrators:(I)(OI)(CI)(F)
           MyPC\MyUser:(I)(OI)(CI)(F)
Successfully processed 1 files; Failed processing 0 files

It shows that the ACL in the temp directory is appropriate and it is a default configuration. In fact re-creating the team folder didn’t make any difference. This problem occurs with different users as well. I used custom log path(/log C:\temp\Netfx.log) but still the issue was not resolved. Then, I tried turning on auditing for the Temp folder to see which user tries to access the Temp folder and I found the below information:             

Access Reasons:      
READ_CONTROL: Unknown or unchecked 
SYNCHRONIZE:  Unknown or unchecked
WriteData (or AddFile): Denied by Integrity Policy check
AppendData (or AddSubdirectory or CreatePipeInstance): Unknown or unchecked
WriteEA:         Unknown or unchecked
ReadAttributes:  Unknown or unchecked
WriteAttributes: Unknown or unchecked  

I checked the Integrity level in the process monitor. The below screen shot shows that the Setup.exe process is launched with low Integrity level. We know that Low integrity level processes cannot write in most of the places under user profile.

This should not be a default behavior as by default such levels are defined in the OS.  It must be explicitly defined and it was inherited to the process launched from the source directory C:\2d7a2b9d5ac9fde4e25b451fb755\. Here, the package is created using sfxcab(Self-Extracting Cabinet) - that's the self-extracting technology used for many Setup installers.During runtime it creates a randomly named folder at the drive where maximum free disk space is available and it's the temp location that setup extracts it's contents i.e. C:\2d7a2b9d5ac9fde4e25b451fb755\

Next, I ran Icacls.exe for the above folder and found the below output:

C:\>icacls 2d7a2b9d5ac9fde4e25b451fb755     
2d7a2b9d5ac9fde4e25b451fb755 BUILTIN\Administrators:(OI)(CI)(F) 
                     NT AUTHORITY\SYSTEM:(OI)(CI)(F) 
                     Everyone:(OI)(CI)(RX) 
                     BUILTIN\Users:(OI)(CI)(RX) 
                     Mandatory Label\Low Mandatory Level:(I)(OI)(CI NW)

Output for the root drive:

C:\>icacls C:     
C: NT AUTHORITY\SYSTEM:(OI)(CI)(F)      
   BUILTIN\Administrators:(OI)(CI)(F)      
   BUILTIN\Users:(OI)(CI)(RX)      
   BUILTIN\Users:(CI)(AD)      
   BUILTIN\Users:(CI)(IO)(WD)      
   CREATOR OWNER:(OI)(CI)(IO)(F)      
   Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

By default it should be like this:    
C:\>icacls C:      
C: BUILTIN\Administrators:(F)      
   BUILTIN\Administrators:(OI)(CI)(IO)(F)      
   NT AUTHORITY\SYSTEM:(F)      
   NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)      
   BUILTIN\Users:(OI)(CI)(RX)      
   NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)  
   NT AUTHORITY\Authenticated Users:(AD)      
   Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW)

The integrity level in the security access token of a process can be viewed using tools that expose the security details of a process, such as Process Explorer  The below image shows the display from Process Explorer with the Integrity Level column added to the view.

If we look at the security properties of a specific process, such as Setup.exe, Process Explorer shows the integrity level in the list of groups that are defined in the security access token of the process. The below image shows the Mandatory Label/Low Mandatory Level assigned to the access token for the process, Setup.exe

In order to resolve the issue, You can change the integrity level on the extracted folder(C:\2d7a2b9d5ac9fde4e25b451fb755) or on the root drive(C:\) from low to high. You can modify the mandatory level requirements using the icacls utility. It contains a command line switch: /setintegritylevel    
          
For example: icacls c:\myLowIntegrityFolder  /setintegritylevel  high     

Reference links:     
https://msdn.microsoft.com/en-us/library/bb625963.aspx      
https://msdn.microsoft.com/en-us/library/bb625960.aspx

P.S. Impersonation is one way that a service thread may be running at a lower integrity level. When a service thread impersonates a local client, the impersonation thread has the client’s security context, which includes the client’s integrity level if the client is running on the same local machine.

Not all application programs will run properly in a low-integrity process. A low integrity process does not have write access to most areas under the user’s local profile area of the file system or the registry under HKCU. The inability for a low-integrity process to get write access to the user profile is a good thing if the program is unwanted malicious software. But for applications like Protected Mode Internet Explorer, some redesign may be necessary to get all features of the application behaving correctly.

While trying to create any C# shared or Windows Phone projects using the Visual Studio 2015 IDE, you may receive an error message as highlighted below:

This is a known issue and it would be fixed in a future update. In order to resolve the issue, please follow the below two workaround:

Workaround 1: 

Please modify the CodeSharing targets. To do so, download the attached target file and replace the file “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeSharing\Microsoft.CodeSharing.CSharp.targets” with it.

Alternatively, you can repair the target file manually: Open the file C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeSharing\Microsoft.CodeSharing.CSharp.targets(or, for Visual Basic, Microsoft.CodeSharing.VisualBasic.targets)

Around line 8, you should see two entries:
<Import
Project=”$(MSBuildExtensionsPath32)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets” Condition=”Exists(‘$(MSBuildExtensionsPath32)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets’)”/>

<Import
Project=”$(MSBuildBinPath)\Microsoft.CSharp.Targets” Condition=”!Exists(‘$(MSBuildExtensionsPath32)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets’)”
/> 
 
Replace these entries with the following:

<Import
Project=”$(MSBuildExtensionsPath32)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets”
Condition=”false”/>

<Import
Project=”$(MSBuildBinPath)\Microsoft.CSharp.Targets” Condition=”true”
/>

Workaround 2:

1. Open the VS 2015 IDE
2. Click on File->New->Project
3. Choose the only Project template under Windows 8 (below screenshot)
This will launch Visual Studio setup where you can install the templates that are missing.

Alternatively, you can install the below feature by changing the installed Visual Studio 2015 from the “Control Panel\Programs\Programs and Features”:

P.S.  For Windows 7 OS, the workaround 1 will be applicable only. It can also occur with Visual Basic shared projects.  Obviously the file to modify would be the VB one (Microsoft.CodeSharing.VisualBasic.targets)

Microsoft.CodeSharing.CSharp.targets

“Error opening installation log file. Verify that the specified log file location exists and that you can write to it.” error when attempting to install any Setup package. For example, try installing any one of the below packages:

The Microsoft .Net Framework patch KB2972216      
The Microsoft Visual C++ 2008 Redistributable Package     
The Microsoft Forefront Endpoint Protection 

The sample error screenshots are displayed below:

There was a log file (dd_NDP45-KB2972216-x64_decompression_log.txt) in the user temp folder (%temp%) and I found the below information:

[3/15/2015, 10:40:28] Drive ‘C:\’ has been selected as the largest fixed drive     
[3/15/2015, 10:40:28] Directory ‘C:\2d7a2b9d5ac9fde4e25b451fb755\’ has been selected for file extraction      
[3/15/2015, 10:40:28] Extracting files to: C:\2d7a2b9d5ac9fde4e25b451fb755\      
[3/15/2015, 10:40:31] Extraction took 3.485 seconds      
[3/15/2015, 10:40:31] Executing command line: ‘C:\2d7a2b9d5ac9fde4e25b451fb755\Setup.exe 

The subject error message appears to be an issue with NTFS file/folder permission. Hence, I ran a tool called Process Monitor. The procmon trace shows the failure. The MSI fails to write it’s log and that is what eventually kills the install.     
 
Setup.exe         1880       CreateFile           C:\Users\MyUser\AppData\Local\Temp\MSI3a3f7.LOG  ACCESS DENIED  Desired Access: Generic Write, Read Attributes, Disposition: Create, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: N, ShareMode: Read, AllocationSize: 0

User Mode Stack:
==============

18  KernelBase.dll    CreateFileW + 0x35e,   0x7578c5f7   C:\Windows\SysWOW64\KernelBase.dll
19  Kernel32.dll        CreateFileWImplementation + 0x69, 0x758f3f66 C:\Windows\SysWOW64\kernel32.dll
20  msi.dll   CMsiPath::TempFolderOrFile + 0x52e,   0x6f4b4739  C:\Windows\SysWOW64\msi.dll
21  msi.dll   CMsiPath::TempFileName + 0x2c,         0x6f4b4907   C:\Windows\SysWOW64\msi.dll
22  msi.dll   MsiUIMessageContext::InitializeLog + 0x601,  0x6f327ff2  C:\Windows\SysWOW64\msi.dll
23  msi.dll   MsiUIMessageContext::Initialize + 0x1da,     0x6f307d81   C:\Windows\SysWOW64\msi.dll
24  msi.dll   MsiUIMessageContext::RunInstall + 0x91,      0x6f308085  C:\Windows\SysWOW64\msi.dll
25  msi.dll   RunEngine + 0xe2,             0x6f308ed8  C:\Windows\SysWOW64\msi.dll
26  msi.dll   MsiInstallProductW + 0xa1, 0x6f39ee2c  C:\Windows\SysWOW64\msi.dll
27 SetupEngine.dll IronMan::MspInstallerT<IronMan::PatchesFilteredT <IronMan::CMsiInstallContext>>::Execute + 0x20d, 0x6f5abc76 C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
28 SetupEngine.dll IronMan::BaseMspInstallerT<IronMan::MsiExternalUiHandler, IronMan::PatchesFilteredT<IronMan::CMsiInstallContext> >::PerformMsiOperation + 0x323, 0x6f5a2643 C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
29 SetupEngine.dll IronMan::BaseMspInstallerT<IronMan::MsiExternalUiHand ler,IronMan::PatchesFilteredT<IronMan::CMsiInstallContext> >::PerformAction + 0x162,        0x6f5a2015   C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
30 SetupEngine.dll IronMan::CompositePerformerBaseT<IronMan::Performers <IronMan::MsiInstaller,IronMan::MspInstallerT<IronMan::Patches<IronMan::CMsiInstallContext> IronMan::RelatedProductsRepairer>,IronMan::Performers<IronMan::MsiUnInstallerT<IronMan: + 0x552, 0x6f5a3c62     C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
31 SetupEngine.dll IronMan::CompositePerformer::PerformAction + 0x1fa,  0x6f596f99  C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
32 SetupEngine.dll IronMan::NotifyController::ThreadProc + 0x12, 0x6f58aacc   C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
33 kernel32.dll    BaseThreadInitThunk + 0xe,  0x758f338a C:\Windows\SysWOW64\kernel32.dll
34 ntdll.dll __RtlUserThreadStart + 0x70,  0x77879f72  C:\Windows\SysWOW64\ntdll.dll
35 ntdll.dll _RtlUserThreadStart + 0x1b,  0x77879f45  C:\Windows\SysWOW64\ntdll.dll

 
I thought that there must be something busted with the ACL in the temp directory. So I ran Icacls.exe for the Temp folder:
C:\Users\MyUser\AppData\Local\>icacls Temp

Temp NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
           BUILTIN\Administrators:(I)(OI)(CI)(F)
           MyPC\MyUser:(I)(OI)(CI)(F)
Successfully processed 1 files; Failed processing 0 files

It shows that the ACL in the temp directory is appropriate and it is a default configuration. In fact re-creating the team folder didn’t make any difference. This problem occurs with different users as well. I used custom log path(/log C:\temp\Netfx.log) but still the issue was not resolved. Then, I tried turning on auditing for the Temp folder to see which user tries to access the Temp folder and I found the below information:             

Access Reasons:      
READ_CONTROL: Unknown or unchecked 
SYNCHRONIZE:  Unknown or unchecked
WriteData (or AddFile): Denied by Integrity Policy check
AppendData (or AddSubdirectory or CreatePipeInstance): Unknown or unchecked
WriteEA:         Unknown or unchecked
ReadAttributes:  Unknown or unchecked
WriteAttributes: Unknown or unchecked  

I checked the Integrity level in the process monitor. The below screen shot shows that the Setup.exe process is launched with low Integrity level. We know that Low integrity level processes cannot write in most of the places under user profile.

This should not be a default behavior as by default such levels are defined in the OS.  It must be explicitly defined and it was inherited to the process launched from the source directory C:\2d7a2b9d5ac9fde4e25b451fb755\. Here, the package is created using sfxcab(Self-Extracting Cabinet) – that’s the self-extracting technology used for many Setup installers.During runtime it creates a randomly named folder at the drive where maximum free disk space is available and it’s the temp location that setup extracts it’s contents i.e. C:\2d7a2b9d5ac9fde4e25b451fb755\

Next, I ran Icacls.exe for the above folder and found the below output:

C:\>icacls 2d7a2b9d5ac9fde4e25b451fb755     
2d7a2b9d5ac9fde4e25b451fb755 BUILTIN\Administrators:(OI)(CI)(F) 
                     NT AUTHORITY\SYSTEM:(OI)(CI)(F) 
                     Everyone:(OI)(CI)(RX) 
                     BUILTIN\Users:(OI)(CI)(RX) 
                     Mandatory Label\Low Mandatory Level:(I)(OI)(CI NW)

Output for the root drive:

C:\>icacls C:     
C: NT AUTHORITY\SYSTEM:(OI)(CI)(F)      
   BUILTIN\Administrators:(OI)(CI)(F)      
   BUILTIN\Users:(OI)(CI)(RX)      
   BUILTIN\Users:(CI)(AD)      
   BUILTIN\Users:(CI)(IO)(WD)      
   CREATOR OWNER:(OI)(CI)(IO)(F)      
   Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

By default it should be like this:    
C:\>icacls C:      
C: BUILTIN\Administrators:(F)      
   BUILTIN\Administrators:(OI)(CI)(IO)(F)      
   NT AUTHORITY\SYSTEM:(F)      
   NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)      
   BUILTIN\Users:(OI)(CI)(RX)      
   NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)  
   NT AUTHORITY\Authenticated Users:(AD)      
   Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW)

The integrity level in the security access token of a process can be viewed using tools that expose the security details of a process, such as Process Explorer  The below image shows the display from Process Explorer with the Integrity Level column added to the view.

If we look at the security properties of a specific process, such as Setup.exe, Process Explorer shows the integrity level in the list of groups that are defined in the security access token of the process. The below image shows the Mandatory Label/Low Mandatory Level assigned to the access token for the process, Setup.exe

In order to resolve the issue, You can change the integrity level on the extracted folder(C:\2d7a2b9d5ac9fde4e25b451fb755) or on the root drive(C:\) from low to high. You can modify the mandatory level requirements using the icacls utility. It contains a command line switch: /setintegritylevel    
          
For example: icacls c:\myLowIntegrityFolder  /setintegritylevel  high     

Reference links:     
https://msdn.microsoft.com/en-us/library/bb625963.aspx      
https://msdn.microsoft.com/en-us/library/bb625960.aspx

P.S. Impersonation is one way that a service thread may be running at a lower integrity level. When a service thread impersonates a local client, the impersonation thread has the client’s security context, which includes the client’s integrity level if the client is running on the same local machine.

Not all application programs will run properly in a low-integrity process. A low integrity process does not have write access to most areas under the user’s local profile area of the file system or the registry under HKCU. The inability for a low-integrity process to get write access to the user profile is a good thing if the program is unwanted malicious software. But for applications like Protected Mode Internet Explorer, some redesign may be necessary to get all features of the application behaving correctly.

You may find the below error message while publishing a ClickOnce application in the Visual Studio IDE: “SignTool Error: The signer’s certificate is not valid for signing”

Since, the above error message indicates that it’s an issue with the certificate. I tried signing a sample EXE file using the same certificate and it failed with the below error message:

C:\>signtool.exe sign /f My_Certificate.pfx MyApp.exe
SignTool Error: The signer’s certificate is not valid for signing.
SignTool Error: An error occurred while attempting to sign: MyApp.exe

Then I verified the certificate property and found the below information:

The above issue is due to the certificate having an RSA key less than 1024 bits (512 bits) long. As per this MSDN doc: https://msdn.microsoft.com/en-us/library/aa374191(v=vs.85).aspx 
publicKeyToken– A 16-character hexadecimal string representing the last 8 bytes of the SHA-1 hash of the public key under which the application or assembly is signed. The public key used to sign the catalog must be 2048 bits or greater.

Hence, the recommended resolution would be to implement certificates that have a key length of at least 2048 bits. Then sign the ClickOnce application using the certificate.

An alternative workaround:

The following command (admin prompt) would allow you to bypass the blocking keys that have a length of less than1024 bits: certutil -setreg chain\minRSAPubKeyBitLength 512

You can revert to blocking keys that have a length of less than1024 bits by removing the value. To do this, run the following certutil command: certutil -delreg chain\MinRsaPubKeyBitLength

Microsoft does not recommend customers use certificates less than 1024 bits long. Customers may however need the above temporary workaround while a longer term solution is developed to replace RSA certificates with a key length of less than 1024 bits length. Customers configuring these settings are accepting the risk that an attacker may be able to break their certificates and use them to spoof content, perform phishing attacks, or perform Man-in-the-Middle attacks.

Reference: https://support.microsoft.com/en-in/kb/2661254

Security Update for Microsoft .NET Framework 4.X (KB3135996 or KB3136000) may fail with the below error message: Installation failed with error code: (0x800B010A), “A certificate chain could not be built to a trusted root authority.”

As per the install log:

C:\65760b35b9bcb98aad5de44ad83b\NDP45-KB3135996.msp Signature could not be verified for NDP45-KB3135996.msp
No FileHash provided. Cannot perform FileHash verification for NDP45-KB3135996.msp
File NDP45-KB3135996.msp (C:\65760b35b9bcb98aad5de44ad83b\NDP45-KB3135996.msp), failed authentication(Error = -2146762486). It is recommended that you delete this file and retry setup again.
Failed to verify and authenticate the file -C:\65760b35b9bcb98aad5de44ad83b\NDP45-KB3135996.msp
Please delete the file, C:\65760b35b9bcb98aad5de44ad83b\NDP45-KB3135996.msp and run the package again

According to the CAPI2 event messages inside the log:

                                                             <CryptRetrieveObjectByUrlWire>

                                                                                 <URL scheme=”http”>http://www.microsoft.com/pki/certs/MicRooCerAut2011_2011_03_22.crt </URL>

                                                                                 <Object type=”CONTEXT_OID_CERTIFICATE” constant=”1″/>

                                                                                 <Timeout>PT15S</Timeout>

                                                                                 <Flags value=”286005″ CRYPT_RETRIEVE_MULTIPLE_OBJECTS=”true” CRYPT_WIRE_ONLY_RETRIEVAL=”true” CRYPT_LDAP_SCOPE_BASE_ONLY_RETRIEVAL=”true” CRYPT_OFFLINE_CHECK_RETRIEVAL=”true” CRYPT_AIA_RETRIEVAL=”true” CRYPT_PROXY_CACHE_RETRIEVAL=”true”/>

                                                                                 <AdditionalInfo>

                                                                                                      <Action name=”NetworkRetrievalTimeout”>

                                                                                                                          <Error value=”5B4″>This operation returned because the timeout period expired. </Error>

                                                                                                      </Action>

                                                                                 </AdditionalInfo>

                                                                                 <EventAuxInfo ProcessName=”Setup.exe”/>

                                                                                 <CorrelationAuxInfo TaskId=”{98B7F5D9-09DF-4158-8662-72272FA6171C}” SeqNumber=”9″/>

                                                                                 <Result value=”5B4″>This operation returned because the timeout period expired.</Result>

                                                </CryptRetrieveObjectByUrlWire>

This issue occurs when this certificate MicRooCerAut2011_2011_03_22.cer is missing particularly when you operate in an environment that’s disconnected from the Internet or that has a firewall that blocks content from the following URL: http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en This behavior is due to recent changes to Microsoft Windows Enforcement of Authenticode Code Signing and Timestamping.

In order to resolve this issue, please try the below steps:

·         Download the certificate http://www.microsoft.com/pki/certs/MicRooCerAut2011_2011_03_22.crt  locally (Example: C:\Temp)
·         You can use the certmgr.exe utility to add the certificate by using command line. For more information, see the Certmgr.exe (Certificate Manager Tool) topic at MSDN.
·         Open an admin command prompt and run this command: certmgr.exe /add  C:\Temp\MicRooCerAut2011_2011_03_22.cer /s /r localMachine root
·         Next try installing the patch KB3135996 or KB3136000

Alternatively, you can download and install KB2813430 and then manage certificates individually: http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en 

For more information, see the Configure trusted roots and disallowed certificates & Install a Root Certification Authority on offline machines topics at TechNet.

Evaluating Visual Studio 2015 for 30 Days

You can evaluate the Professional and Enterprise editions of Visual Studio 2015 for 30 days, starting when you install the product.

To verify this, select “Account Settings” option under “File” menu

For Example: This installation was done on 18-Feb-2016 and the evaluation period will end on 19-Mar-2016

How to extend the evaluation period of Visual Studio 2015 by 90 days?

If you are signing in to Visual Studio 2015 within 30 days from the installation using your account that is not linked with your MSDN account will overwrite the evaluation period to 90 days. So, you can evaluate Visual Studio 2015 for a maximum of 120 days.

Let us consider the following example: 

How to unlock Visual Studio 2015?

To continue to use the product after ≤ 120 days, you must unlock Visual Studio 2015 by providing a valid product key, or sign into Visual Studio 2015 with an account that is associated with an MSDN subscription or a Visual Studio Online subscription.

1.       Unlock Visual Studio 2015 using product key

2.       Unlock Visual Studio 2015 using sign into Visual Studio 2015 with an account that is associated with an MSDN subscription

To unlock Visual Studio with a product key

Select File > Account Settings to open the Account Settings dialog and click on the “Unlock with a ProductKey” link.

Enter the product key in the space provided and apply

Note: If you are using Visual Studio for extended periods in environments with limited or no internet access, you should use a product key to unlock Visual Studio in order to avoid interruption.

You can apply your product key programmatically during installation of Visual Studio or after an installation completed.

Apply the license during installation

Use the /ProductKey parameter to apply a product key during Visual Studio’s setup process. This setup parameter can be used with the /Silent parameter to install Visual Studio in an already licensed state for an end user. To use the /ProductKey parameter, open up a command prompt. Run the setup program (e.g. vs_enterprise.exe or vs_professional.exe) and set the /ProductKey parameter with a product key (25 characters) that includes no dashes:

This is an example command for installing Visual Studio 2015 Enterprise with product key AAAAABBBBBCCCCCDDDDDEEEEEEE:

vs_enterprise.exe [any other setup parameters] /ProductKey AAAAABBBBBCCCCCDDDDDDEEEEEE

Apply the license after installation

You can activate an installed version of Visual Studio with a product key by using the storePID.exe utility on the target machines in silent mode. StorePID.exe is a utility program that installs with Visual Studio at <drive>:\\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\StorePID.exe.

Run storePID.exe with elevated privileges, either by using a System Center agent or an elevated command prompt, followed by the product key (including the dashes) and the Microsoft Product Code (MPC). Please be sure to include the dashes in the product key!

 StorePID.exe [product key including the dashes] [MPC]

This is an example command line for installing Visual Studio 2015 Enterprise, which has a MPC of 07060, with a product key “AAAAA-BBBBB-CCCCC-DDDDDD-EEEEEE”:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\StorePID.exe AAAAA-BBBBB-CCCCC-DDDDDD-EEEEEE 07060

Note: Ensure that there are no extra spaces given in between the ProductKey and MPC code

The following table lists the MPC codes for each edition of Visual Studio:

To unlock Visual Studio using an online subscription

To unlock Visual Studio using an MSDN or Visual Studio online subscription associated with a Microsoft account, or a work or school account:

Click on the “Sign in” button in the upper right corner of the IDE (or go to File > Account Settings to open the Account Settings dialog and click on the “Sign in” button.)

Enter the credentials for either a Microsoft account or a work or school account. Visual Studio will find an MSDN subscription or Visual Studio Team Services subscription associated with your account.

In order to sign into the Visual Studio, you will have to ensure that the following set of URLs are not blocked in your environment

1.       management.core.windows.net

2.       *.microsoftonline.com

3.       go.microsoft.com

4.       graph.windows.net

5.       tfsprodch1acs01.accesscontrol.windows.net

6.       *.visualstudio.com

7.       *.live.com

8.       sxp.microsoft.com

9.       cdp1.public-trust.com

10.   *.microsoftonline-p.com

11.   *.symcb.com

12.   *.symcd.com

13.   *.msecnd.net

14.   auth.gfx.ms

15.   *.nuget.org

16.   *.azurewebsites.net

17.   ctldl.windowsupdate.com

References: 

https://msdn.microsoft.com/en-us/library/dn950037.aspx

https://msdn.microsoft.com/en-us/library/mt270173.aspx

Content Published by Jagadeesan Balakrishnan

Visual Studio 2015 or update packages may fail with the below error message:

In order to diagnose the VS 2015 failure, we need to review the log files.
 
•       Download collect.exe from https://aka.ms/vscollect and save it locally
•       Open an admin command prompt and launch collect.exe 
When it finishes, the logs would be generated in %temp%\vslogs.zip 

In this case, I reviewed the bundle log(dd_vs_enterprise****.log ):

[17F0:1690][2016-02-03T11:47:28]i000: MUX:  ExecutePackageBegin PackageId: vs_teamExplorerCoreRes_enu

[1370:1330][2016-02-03T11:47:28]i301: Applying execute package: vs_teamExplorerCoreRes_enu, action: Install, path: C:\ProgramData\Package Cache\{F60D7BDB-655F-3AF5-BFE4-E543408DCDBD}v14.0.24712\packages\TeamExplorer\enu\vs_teamExplorerCoreRes_enu.msi, arguments: ‘ MSIFASTINSTALL=”7″ USING_EXUIH=”1″‘

[17F0:1690][2016-02-03T11:47:40]i000: MUX:  ExecuteError: Package (vs_teamExplorerCoreRes_enu) failed: Error Message Id: 1606 ErrorMessage: Could not access network location \\MyMachine\Shared Folders\Desktop\.

[17F0:1690][2016-02-03T11:47:40]i000: MUX:  ExecuteError: Package (vs_teamExplorerCoreRes_enu) failed: Error Message Id: 1606 ErrorMessage: Could not access network location \\MyMachine\Shared Folders\Desktop\.

[1370:1330][2016-02-03T11:47:40]e000: Error 0x80070643: Failed to install MSI package.

[1370:1330][2016-02-03T11:47:40]e000: Error 0x80070643: Failed to execute MSI package.

[17F0:1690][2016-02-03T11:47:40]e000: Error 0x80070643: Failed to configure per-machine MSI package.

[17F0:1690][2016-02-03T11:47:40]i000: MUX:  Installation size in bytes for package: vs_teamExplorerCoreRes_enu MaxAppDrive: 0  MaxSysDrive: 385024  AppDrive: 0  SysDrive: 131072

[17F0:1690][2016-02-03T11:47:40]i000: MUX:  Return Code:0x80070643 Msi Messages:Could not access network location \\MyMachine\Shared Folders\Desktop\. Result Detail:0 Restart:None

[17F0:1690][2016-02-03T11:47:40]i000: MUX:  Set Result: Return Code=-2147023293 (0x80070643), Error Message=Could not access network location \\MyMachine\Shared Folders\Desktop\., Result Detail=, Vital=True, Package Action=Install, Package Id=vs_teamExplorerCoreRes_enu

0x80070643# ERROR_INSTALL_FAILURE – Fatal error during installation

Further reviewing the log dd_vs_enterprise_*****_vs_teamExplorerCoreRes_enu.log

MSI (s) (04:00) [11:47:40:294]: Note: 1: 1314 2: \\MyMachine\Shared Folders\Desktop\

MSI (s) (04:00) [11:47:40:294]: Note: 1: 1606 2: \\MyMachine\Shared Folders\Desktop\

Action start 11:47:28: RemoveShortcuts.

MSI (s) (04:00) [11:47:40:303]: Product: Microsoft Visual Studio 2015 Team Explorer Language Pack – ENU — Error 1606. Could not access network location \\MyMachine\Shared Folders\Desktop\.

MSI (s) (04:00) [11:47:40:305]: Note: 1: 1606 2: \\MyMachine\Shared Folders\Desktop\ or 1606. Could not access network location \\MyMachine\Shared Folders\Desktop\.

Action ended 11:47:40: RemoveShortcuts. Return value 3.

According to this KB https://support.microsoft.com/en-us/kb/886549 this issue may occur if there is an incorrect setting in one of the following registry subkeys:  

•HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

•HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Please review each subkeys and look for the path “MyMachine\Shared Folders\Desktop\” In my scenario, I replaced incorrect shared path entries “\\Mymachine\Shared Folders”  by local path like “%USERPROFILE%\Downloads” in the registry HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders. Then the problem was resolved.

“Exception has been thrown by the target of an invocation” error message when you try to create a project in Visual Studio 2015 IDE

As per the VS IDE log (ActivityLog.xml),

Construction of frame content failed. Frame identifier: ST:0:0:{74946827-37a0-11d2-a273-00c04f8ef4ff} Frame caption: Exception details: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) at Microsoft.VisualStudio.Shell.Interop.IVsShell5.LoadPackageWithContext(Guid& packageGuid, Int32 reason, Guid& context) at Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.GetPackage() at Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.ConstructContent()

I also reviewed the DebugDiag trace. Considering above error message, one of the relevant call stacks was  as mentioned below:

                Type:     System.Reflection.TargetInvocationException
                Message:  Exception has been thrown by the target of an invocation.
                                Type:     System.Reflection.TargetInvocationException
                                Message:  Exception has been thrown by the target of an invocation.
                                                Type:     System.InvalidOperationException
                                                Message:  This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.
                Stack:   
                                [GCFrame]
                                [GCFrame]
                                [HelperMethodFrame_PROTECTOBJ]
                                System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(System.Object, System.Object[], System.Object[])
                                System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
                                Roslyn.Utilities.SHA256CryptoServiceProvider..ctor()
                                Microsoft.CodeAnalysis.Diagnostics.Log.DiagnosticAnalyzerLogger..cctor()
                                [GCFrame]
                                [HelperMethodFrame]
                Microsoft.CodeAnalysis.Diagnostics.Log.DiagnosticAnalyzerLogger.AllowsTelemetry(Microsoft.CodeAnalysis.Diagnostics.DiagnosticAnalyzerService, Microsoft.CodeAnalysis.Diagnostics.DiagnosticAnalyzer)
                Microsoft.CodeAnalysis.Diagnostics.Log.DiagnosticLogAggregator.UpdateAnalyzerTypeCount(Microsoft.CodeAnalysis.Diagnostics.DiagnosticAnalyzer, Microsoft.CodeAnalysis.Diagnostics.AnalyzerActions)

This problem occurs when the “FIPS-compliant algorithms” policy is enabled on a system. For more details: https://support.microsoft.com/en-in/kb/811833 

Here, fipsalgorithmpolicy registry subkey was set to 1 (Enabled).

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy]
“Enabled”=dword:00000001

I disabled FIPS setting “Enabled” DWORD value to Zero.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy]
“Enabled”=dword:00000000

Then the problem was resolved. I was able to create projects in Visual Studio 2015 IDE.

There is a known issue with Update for Visual C++ 2013 package: When you install an updated Visual C++ 2013 redistributable package, binaries for non-target architectures are removed. For example, after you install an update for an x86-based application, the x64 Visual C++ 2013 runtime libraries are missing. If you install the “Visual C++ Redistributable 2013 x86 v12.0.30501”, it removes x64 “Visual C++ Redistributable 2013 v12.0.21005”

Before installing Visual C++ Redistributable 2013 x86 v12.0.30501

After installing Visual C++ Redistributable 2013 x86 v12.0.30501

Resolution:
Microsoft Visual C++ 2013 Update 5 Redistributable Package is released as a fix. Please refer to this KB: https://support.microsoft.com/en-us/kb/3138367 This fix makes sure that both versions of the Visual C++ redistributable are visible when you add or remove programs after installation of the update.

Microsoft Visual Studio 2015 Update 2 fails to install with the below error message:

Setup Failed! – Team Explorer for Microsoft Visual Studio 2015 Update 2

I ran https://aka.ms/vscollect tool and reviewed the logs %temp%\vslogs.zip

As per the Team Explorer log: 

MSI (s) (C4:08) [10:30:56:545]: Executing op: ActionStart(Name=TeamExplorerVsixInstall,,)

MSI (s) (C4:08) [10:30:56:545]: Executing op: CustomActionSchedule(Action=TeamExplorerVsixInstall,ActionType=1074,Source=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\VSIXInstaller.exe,Target=/q  “C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\TeamExplorer.vsix” /admin,)

MSI (s) (C4:08) [10:31:07:640]: Note: 1: 1722 2: TeamExplorerVsixInstall 3: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\VSIXInstaller.exe 4: /q  “C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\TeamExplorer.vsix” /admin

CustomAction TeamExplorerVsixInstall returned actual error code 3001 (note this may not be 100% accurate if translation happened inside sandbox)

MSI (s) (C4:08) [10:31:07:641]: Product: Team Explorer for Microsoft Visual Studio 2015 — Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action TeamExplorerVsixInstall, location: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\VSIXInstaller.exe, command: /q  “C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\TeamExplorer.vsix” /admin

Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action TeamExplorerVsixInstall, location: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\VSIXInstaller.exe, command: /q  “C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\TeamExplorer.vsix” /admin

MSI (s) (C4:08) [10:31:07:692]: User policy value ‘DisableRollback’ is 0

MSI (s) (C4:08) [10:31:07:692]: Machine policy value ‘DisableRollback’ is 0

Action ended 10:31:07: InstallFinalize. Return value 3.

VSIXInstaller log shows the below call stack:

4/27/2016 10:30:00 AM – Found installed product – Microsoft Visual Studio Community 2015

4/27/2016 10:30:00 AM – Found installed product – Microsoft Visual Studio 2015 Shell (Integrated)

4/27/2016 10:30:00 AM – Found installed product – Global Location

4/27/2016 10:30:00 AM – Found installed product – ViewDesigner

4/27/2016 10:30:00 AM – System.FormatException: Input string was not in a correct format.

   at System.Version.VersionResult.SetFailure(ParseFailureKind failure, String argument)

   at System.Version.TryParseComponent(String component, String componentName, VersionResult& result, Int32& parsedComponent)

   at System.Version.TryParseVersion(String version, VersionResult& result)

   at System.Version.Parse(String input)

   at System.Version..ctor(String version)

   at VSIXInstaller.SupportedVSSKU.get_VersionWithBuildRevisionInfo()

   at VSIXInstaller.App.IsValidSKUForExtension(SupportedVSSKU supportedSKU, IExtension extension, List`1 validSKUs)

   at VSIXInstaller.App.InitializeInstall(Boolean isRepairSupported)

   at VSIXInstaller.App.OnStartup(StartupEventArgs e)

As per the MSIINV output log: I found the below “ViewDesigner” MSI:

{09FF21B7-5E63-49C2-8DB4-53FB19F873A5} Studio 5000 View Designer

   Package code: {38978A4D-2BF8-4DAB-848B-82F100DAA058}

   Install date: 2016.04.18

        Version: 2.01.00000.00079

      Publisher: Rockwell Automation, Inc.

     Assignment: Per-Machine

       Language: 1033

  Suggested loc: C:\Program Files (x86)\Rockwell Software\

        Package: Studio 5000 View Designer.msi

  Local package: C:\Windows\Installer\3474a6.msi

Installed from: C:\Users\myuser\Documents\temp\Rockwell\27.00.00-Studio5000-Web\27.00.00-Studio5000\ViewDesigner\

    Last source: n;1;C:\Users\myuser\Documents\temp\Rockwell\27.00.00-Studio5000-Web\27.00.00-Studio5000\ViewDesigner\

     About link: http://www.RockwellAutomation,Inc..com

   Product Icon: C:\Windows\Installer\{09FF21B7-5E63-49C2-8DB4-53FB19F873A5}\ARPPRODUCTICON.exe

      Help link: http://support.rockwellautomation.com

     Features: View_Designer_Files, FTAStandard

Total features: 2

              2: Local

  Total patches: 0

Resolution:

The resolution was to remove the “Studio 5000 View Designer” program from Programs and Features (Control Panel) or running this command from an admin prompt: msiexec /X  {09FF21B7-5E63-49C2-8DB4-53FB19F873A5}

Microsoft .Net Framework 4.5.2/4.6/4.6.1 fails to install on Windows 7/2008 R2 OSs. The installation may roll back at the end.

As per the log, this is a custom action failure:

SI (s) (68:58) [13:28:19:005]: Executing op: CustomActionSchedule(Action=CA_Regtlb_Microsoft.JScrip_amd64,ActionType=3073,Source=BinaryData,Target=QuietExec,CustomActionData=”C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regtlibv12.exe” “C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.JScript.tlb”;11)
MSI (s) (68:58) [13:28:19:005]: Creating MSIHANDLE (19) of type 790536 for thread 4696
MSI (s) (68:48) [13:28:19:005]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI4EFE.tmp, Entrypoint: QuietExec
MSI (s) (68:78) [13:28:19:005]: Generating random cookie.
MSI (s) (68:78) [13:28:19:021]: Created Custom Action Server with PID 1340 (0x53C).
MSI (s) (68:64) [13:28:19:083]: Running as a service.
MSI (s) (68:64) [13:28:19:099]: Custom Action Server rejected – Wrong Context
MSI (s) (68:78) [13:28:19:099]: CA Server Process has terminated.
CustomAction CA_Regtlb_Microsoft.JScrip_amd64 returned actual error code 1601 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (68:48) [13:28:19:099]: Closing MSIHANDLE (19) of type 790536 for thread 4696
MSI (s) (68:58) [13:28:19:099]: Note: 1: 1719 2: CA_Regtlb_Microsoft.JScrip_amd64 3: QuietExec 4: C:\Windows\Installer\MSI4EFE.tmp
MSI (c) (E0:3C) [13:28:19:099]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

Error 1719.The Windows Installer Service could not be accessed. This can occur if you are running Windows in safe mode, or if the Windows Installer is not correctly installed. Contact your support personnel for assistance.

In order to resolve the above issue, please follow the below steps:

• Under Key “HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer”, create a DWORD: “SecureRepairPolicy” and set its Value to 2.
• Add the list of Applications to Whitelist: Create a new key “SecureRepairWhitelist” under “HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer” and create StringValues with the MSI package product codes (Including flower brackets {})
The product code of .Net Framework 4.6.1 is {BD6F5371-DAC1-30F0-9DDE-CAC6791E28C3}

For example:

You can open your msi file with Orca and check the property table for “Product Code”. For more information on usage of Orca tool: https://support.microsoft.com/en-in/kb/255905

Ref: https://support.microsoft.com/en-us/kb/2918614
https://blogs.msdn.microsoft.com/astebner/2011/05/16/possible-cause-of-error-code-1719-or-1723-when-installing-a-64-bit-msi/
https://blogs.msdn.microsoft.com/rflaming/2005/07/12/troubleshooting-signs-of-an-incorrectly-registered-custom-action-server/

Visual Studio 2015 setup crashes with the following error after the splash screen is shown: “Setup detected an issue during the operation. Please click below to check for a solution and help us to improve the setup experience.”

After reviewing the Setup failure log dd_vs_****_201*******.log, I found the below failure stack:

[22C4:0820][2016-08-10T14:11:05]e000: MUX:  ERROR: The type initializer for ‘System.Windows.Media.FontFamily’ threw an exception.
[22C4:0820][2016-08-10T14:11:05]e000: MUX:  Stack:    at System.Windows.Media.Typeface..ctor(FontFamily fontFamily, FontStyle style, FontWeight weight, FontStretch stretch)
   at MS.Internal.Text.DynamicPropertyReader.GetTypeface(DependencyObject element)
   at MS.Internal.Text.TextProperties.InitCommon(DependencyObject target)
   at MS.Internal.Text.TextProperties..ctor(FrameworkElement target, Boolean isTypographyDefaultValue)
   at System.Windows.Controls.TextBlock.GetLineProperties()
   at System.Windows.Controls.TextBlock.EnsureTextBlockCache()
   at System.Windows.Controls.TextBlock.MeasureOverride(Size constraint)
   at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   at System.Windows.UIElement.Measure(Size availableSize)

<InnerException>

[22C4:0820][2016-08-10T14:11:05]e000: MUX:  Exception: Info: InnerException: Info:
[22C4:0820][2016-08-10T14:11:05]e000: MUX:  ERROR: Specified argument was out of the range of valid values.
[22C4:0820][2016-08-10T14:11:05]e000: MUX:  Stack:    at MS.Internal.FontCache.CheckedPointer.op_Addition(CheckedPointer rhs, Int32 offset)
   at MS.Internal.FontCache.HashTable.GetElementInfo(Int32*& elementOffsetPtr, ElementHeader*& elementHeader, CheckedPointer& elementDataPtr)
   at MS.Internal.FontCache.HashTable.Lookup(IFontCacheElement e, Boolean add)
   at MS.Internal.FontCache.CacheManager.Lookup(IFontCacheElement e)
   at System.Windows.Media.FontFamily.PreCreateDefaultFamilyCollection()
   at System.Windows.Media.FontFamily..cctor()

VS Setup is a WPF application and WPF apps are susceptible to broken fonts.  A similar issue is described at https://support.microsoft.com/en-in/kb/2978135 

In this case, the issue was resolved by stopping the “Windows Presentation Foundation Font Cache 3.0.0.0” Windows service.

Visual Studio 2015 IDE can’t be launched after removing Visual Studio U3. In the task manager it shows devenv.exe but there is no UI availavle on the screen. If I launch VS IDE again, the behavior remains same and the task manager shows two instances of devenv.exe. Even if I repair VS 2015, it doesn’t make any difference.

Post investigation, it is found that the issue occurs due to mismatched binaries.

       Microsoft.VisualStudio.Imaging.dll C:\windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.Imaging\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Imaging.dll          Yes         N/A        Loading disabled by Include/Exclude setting.    30     14.00.25125.3       6A7A0000-6A83C000          [0xF70] devenv.exe          [1] DefaultDomain          

Microsoft.VisualStudio.Utilities.dll C:\windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.Utilities\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Utilities.dll              Yes         N/A        Loading disabled by Include/Exclude setting.     19     14.00.23107.0        6B310000-6B3FE000    [0xF70] devenv.exe   [1] DefaultDomain          

Here the component Microsoft.VisualStudio.Imaging.dll didn’t get reverted back to RTW. As per the VS logs (using VS collect tool):

• Both VSUpdate and MicroUpdate patches are now absent in the “view installed updates” section of ARP
• But, I still see those two patches applied to a small number of MSIs (full list of MSIs they’re applied to is below)

As per the MSIINV output,

{030A6785-C3A9-37DA-8530-444C320629FA} Microsoft Visual Studio 2015 Shell (Minimum)

   Package code: {19E2D78C-2716-44EF-B992-E383D631C8F3}

   Install date: 2016.09.02

        Version: 14.0.23107

      Publisher: Microsoft Corporation

     Assignment: Per-Machine

       Language: 1033

        Package: vs_minshellcore.msi

  Local package: C:\Windows\Installer\87217e.msi

Installed from: C:\ProgramData\Package Cache\{030A6785-C3A9-37DA-8530-444C320629FA}v14.0.23107\packages\vs_minshellcore\

    Last source: n;1;C:\ProgramData\Package Cache\{030A6785-C3A9-37DA-8530-444C320629FA}v14.0.23107\packages\vs_minshellcore\

       Features: Provider, vs_minshellcore, PID_Validation, PIDGenX_DLL, System.Threading.Tasks.Dataflowx86enu, Servicing_Key

Total features: 6

              6: Local

          Patch: {D174F2C0-A894-495F-B276-C28B52D4DBB4} KB3151378 (Applied)

          Patch: {B9041113-67E7-46A3-BC24-A977D1FD13A1} KB3165756 (Applied)

  Total patches: 2

{14D1CABE-2B5A-3AED-B3A7-42315D062965} Microsoft Visual Studio Enterprise 2015

   Package code: {FE7684DC-63FA-401C-A1BA-A879B3C57FAE}

   Install date: 2016.09.02

        Version: 14.0.23107

      Publisher: Microsoft Corporation

     Assignment: Per-Machine

       Language: 1033

        Package: vs_enterprisecore.msi

  Local package: C:\Windows\Installer\872219.msi

Installed from: C:\ProgramData\Package Cache\{14D1CABE-2B5A-3AED-B3A7-42315D062965}v14.0.23107\packages\enterprisecore\

    Last source: n;1;C:\ProgramData\Package Cache\{14D1CABE-2B5A-3AED-B3A7-42315D062965}v14.0.23107\packages\enterprisecore\

      Help link: http://go.microsoft.com/fwlink/?LinkId=133405

       Features: Provider, Visual_Studio_Ultimate_x86_enu, Team_Developer_and_Test_tools_x86_enu, Testing_Tools_12153_x86_enu, VsttliteSpecific_Feature, VsttLite_Update1_Feature, VSU_TestTools_Update1_Feature, VSU_TestTools_Update2_Feature, AgileTestWindow_net, ProductRegKeyVSTS_12211_x86_enu, PID_Validation, PIDGenX_DLL, Servicing_Key, Detection_Keys

Total features: 14

             14: Local

          Patch: {B9041113-67E7-46A3-BC24-A977D1FD13A1} KB3165756 (Applied)

  Total patches: 1

{DE064F60-6522-3310-9665-B5E3E78B3638} Microsoft Visual Studio Community 2015

   Package code: {4CCB2524-FCB2-461B-9530-CF2737B95732}

   Install date: 2016.09.02

        Version: 14.0.23107

      Publisher: Microsoft Corporation

     Assignment: Per-Machine

       Language: 1033

        Package: vs_communitycore.msi

  Local package: C:\Windows\Installer\8721d1.msi

Installed from: C:\ProgramData\Package Cache\{DE064F60-6522-3310-9665-B5E3E78B3638}v14.0.23107\packages\communitycore\Setup\

    Last source: n;1;C:\ProgramData\Package Cache\{DE064F60-6522-3310-9665-B5E3E78B3638}v14.0.23107\packages\communitycore\Setup\

       Features: Visual_Studio_Community_x86_enu, VB_for_VS_7_Pro_11320_x86_enu, Provider, VCsh_for_VS_7_Pro_810_x86_enu, VWD_for_VS_Pro_11324_x86_enu, Testing_Tools_for_Pro_x86_enu, Code_Analysis_Tools_11987_x86_enu, Performance_Tools_11988_x86_enu, TSDevPkg_12650_x86_enu, WinSDK_EULA, VS_Remote_Debugging_x86_enu, PID_Validation, PIDGenX_DLL, SilverlightSL4_Reg, Servicing_Key, Detection_Keys, UnitTest_Agent_12142

Total features: 17

             17: Local

          Patch: {B9041113-67E7-46A3-BC24-A977D1FD13A1} KB3165756 (Applied)

  Total patches: 1

{DF32E41C-24AD-4A87-B43A-B38553B1806E} Visual Studio 2015 Prerequisites

   Package code: {470C3138-DE41-4A82-AF51-621DA2F70582}

   Install date: 2016.09.02

        Version: 14.0.23107

      Publisher: Microsoft Corporation

     Assignment: Per-Machine

       Language: 1033

        Package: VS_Prerequisites_x64_neutral.msi

  Local package: C:\Windows\Installer\872106.msi

Installed from: C:\ProgramData\Package Cache\{DF32E41C-24AD-4A87-B43A-B38553B1806E}v14.0.23107\packages\64bitPrereq\x64\

    Last source: n;1;C:\ProgramData\Package Cache\{DF32E41C-24AD-4A87-B43A-B38553B1806E}v14.0.23107\packages\64bitPrereq\x64\

      Help link: http://go.microsoft.com/fwlink/?LinkId=133405

       Features: VS_BSLN_enu_amd64_sfx_SETUP, Provider, Visual_Studio_A64_Prereqs_amd64_enu, WinSDK_Registry_x64, Servicing_Key, Detection_Keys

Total features: 6

              6: Local

          Patch: {B9041113-67E7-46A3-BC24-A977D1FD13A1} KB3165756 (Applied)

  Total patches: 1

{66D86CBC-EFCD-3502-A249-F91F775427F8} Microsoft Visual Studio Premium 2015

   Package code: {B5F4BF5C-5086-4A0C-BF4E-C821E0401A7B}

   Install date: 2016.09.02

        Version: 14.0.23107

      Publisher: Microsoft Corporation

     Assignment: Per-Machine

       Language: 1033

        Package: vs_premiumcore.msi

  Local package: C:\Windows\Installer\8721fa.msi

Installed from: C:\ProgramData\Package Cache\{66D86CBC-EFCD-3502-A249-F91F775427F8}v14.0.23107\packages\premiumcore\

    Last source: n;1;C:\ProgramData\Package Cache\{66D86CBC-EFCD-3502-A249-F91F775427F8}v14.0.23107\packages\premiumcore\

      Help link: http://go.microsoft.com/fwlink/?LinkId=133405

       Features: Provider, Visual_Studio_Premium_x86_enu, VB_for_VS_7_Ent_28_x86_enu, VCsh_for_VS_7_Ent_670_x86_enu, Team_Developer_Tools_11986_x86_enu, Testing_Tools_for_Dev_11989_x86_enu, VSU_UITest_Components_Update1_Feature, TSDevPkg_12650_x86_enu, VsttliteSpecific_Feature, VsttLite_Update1_Feature, SilverlightSL4_Reg, Servicing_Key, Detection_Keys

Total features: 13

             13: Local

          Patch: {B9041113-67E7-46A3-BC24-A977D1FD13A1} KB3165756 (Applied)

  Total patches: 1

What happened:

When VSU3 is uninstalled, it also uninstalls MU3.x (MicroUpdate 3).  That is okay. However, the MU3.x uninstall didn’t remove the MU MSP (patch) that targets many VS MSIs. 

From dd_patch_KB3165756_2060902195618.log:

[1914:1DB8][2016-09-02T19:56:20]i201: Planned package: kb3165756_enu, state: Present, default requested: None, ba requested: None, execute: None, rollback: None, cache: No, uncache: No, dependency: Unregister

[1914:1DB8][2016-09-02T19:56:20]i201: Planned package: kb3165756, state: Present, default requested: None, ba requested: None, execute: None, rollback: None, cache: No, uncache: No, dependency: Unregister

Why did it happen:

Unfortunately, this is how bundles are designed to work for performance reasons.  It is assumed that if a patch bundle (like VS Update) is being removed because it is a related bundle and the related parent bundle is also being removed, then the parent bundle will be uninstalling the product (MSI) so the patch bundle doesn’t need to remove the patch (MSP).  If it didn’t do this, it would take twice as long to uninstall VS when VS Update is also present.  So this performance design works great for the VS & VS Update scenario.

However, this design does not work with Micro Updates which are a patch to a patch.  Since it is assumed that if a patch bundle (like MU3.x) is being removed because it is a related bundle and the related parent bundle (VSUpdate) is also being removed, then the parent bundle will remove the product.  But, VS Update isn’t a product, it is a patch.  So what happens here is that the VS U3 patch gets removed but the MU3.x patch does not get removed since the product (VS RTM) is still present.

Workaround:

Find all the Micro Updates on your machine.  Even though the Micro Updates are already uninstalled when VS Update is uninstalled, there is still a copy of the MU setup exes in the SecondaryInstaller cache.  Note: The paths will vary depending on the versions of MUs you previously had installed.  You can find them by running this command:   dir “\ProgramData\VS14-KB*.exe” /s

Next, run all of these exes with “/uninstall” to force it to uninstall the MUs again using the below commands.  This time, they will not run in “related bundle” mode so they will actually remove the patch (MSP) and VS files that are patched will go back to their RTM version.

C:\ProgramData\Microsoft\VisualStudioSecondaryInstaller\14.0\installers\MicroUpdate2.1\en\0\vs14-kb3151378.exe /uninstall

C:\ProgramData\Microsoft\VisualStudioSecondaryInstaller\14.0\installers\MicroUpdate3.4\en\0\vs14-kb3165756.exe /uninstall

If you find more than one MU, uninstall all of them just to be sure they are all removed.  On my machine, I previously had MU2.1 and MU3.4.  That is why even after uninstalling VS U3 some MSIs still had 2 patches applied. Now the VSU3 and MU3.4 and MU2.1 patches are all removed and Visual Studio IDE can be launched successfully.

While trying to create any C# shared or Windows Phone projects using the Visual Studio 2015 IDE, you may receive an error message as highlighted below:

This is a known issue and it would be fixed in a future update. In order to resolve the issue, please follow the below two workaround:

Workaround 1: 

Please modify the CodeSharing targets. To do so, download the attached target file and replace the file “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeSharing\Microsoft.CodeSharing.CSharp.targets” with it.

Alternatively, you can repair the target file manually: Open the file C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeSharing\Microsoft.CodeSharing.CSharp.targets(or, for Visual Basic, Microsoft.CodeSharing.VisualBasic.targets)

Around line 8, you should see two entries:
<Import
Project=”$(MSBuildExtensionsPath32)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets” Condition=”Exists(‘$(MSBuildExtensionsPath32)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets’)”/>

<Import
Project=”$(MSBuildBinPath)\Microsoft.CSharp.Targets” Condition=”!Exists(‘$(MSBuildExtensionsPath32)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets’)”
/>

Replace these entries with the following:

<Import
Project=”$(MSBuildExtensionsPath32)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets”
Condition=”false”/>

<Import
Project=”$(MSBuildBinPath)\Microsoft.CSharp.Targets” Condition=”true”
/>

Workaround 2:

1. Open the VS 2015 IDE
2. Click on File->New->Project
3. Choose the only Project template under Windows 8 (below screenshot)
This will launch Visual Studio setup where you can install the templates that are missing.

Alternatively, you can install the below feature by changing the installed Visual Studio 2015 from the “Control Panel\Programs\Programs and Features”:

P.S.  For Windows 7 OS, the workaround 1 will be applicable only. It can also occur with Visual Basic shared projects.  Obviously the file to modify would be the VB one (Microsoft.CodeSharing.VisualBasic.targets)

Visual Studio 2017 installation fails after extracting files. As per the bootstrapper log:

VisualStudio Bootstrapper:3/28/2017 3:24:41 PM: Current Optin root path does not exists
VisualStudio Bootstrapper:3/28/2017 3:24:42 PM: Caught Exception: Type = ManagementException, Message = Invalid class , StackTrace =    at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
   at System.Management.ManagementObject.Get()
   at Microsoft.VisualStudio.Setup.Bootstrapper.Utilities.GetParentProcess(ILogger logger, Boolean throwOnComException)
VisualStudio Bootstrapper:3/28/2017 3:24:42 PM: Invalid class
VisualStudio Bootstrapper:3/28/2017 3:24:42 PM: Caught Exception: Type = ManagementException, Message = Invalid class , StackTrace =    at Microsoft.VisualStudio.Setup.Bootstrapper.Utilities.GetParentProcess(ILogger logger, Boolean throwOnComException)
   at Microsoft.VisualStudio.Setup.Bootstrapper.Program.Parse(String[] args, ILogger logger, String entryAssemblyProcessName, String entryAssemblyProcessFullName)
   at Microsoft.VisualStudio.Setup.Bootstrapper.Program.Run(String[] args)
VisualStudio Bootstrapper:3/28/2017 3:24:42 PM: General Failure. Message:Invalid class  Callstack:    at Microsoft.VisualStudio.Setup.Bootstrapper.Utilities.GetParentProcess(ILogger logger, Boolean throwOnComException)
   at Microsoft.VisualStudio.Setup.Bootstrapper.Program.Parse(String[] args, ILogger logger, String entryAssemblyProcessName, String entryAssemblyProcessFullName)
   at Microsoft.VisualStudio.Setup.Bootstrapper.Program.Run(String[] args) Inner Message: Internal

I launched the Setup in debugger and captured a crash dump.  I found the following information from the crash dump:
0:000> !pe
Exception object: 0000000002627408
Exception type:   System.Management.ManagementException
Message:          Invalid class
InnerException:   <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131501

0:000> kL100
# Child-SP          RetAddr           Call Site
00 00000000`006fb470 00007fff`f58ffbf1 KERNELBASE!RaiseException+0x68
01 00000000`006fb550 00007fff`f58ff9f0 clr!RaiseTheExceptionInternalOnly+0x2f0
02 00000000`006fb650 00007fff`962248e3 clr!IL_Throw+0x111
03 00000000`006fb800 00007fff`f58ff589 vs_setup_bootstrapper!Microsoft.VisualStudio.Setup.Bootstrapper.Utilities.GetParentProcess(Microsoft.VisualStudio.Setup.Services.ILogger, Boolean)+0x1e3
04 00000000`006fb850 00007fff`f5900bfb clr!ExceptionTracker::CallHandler+0xf1
05 00000000`006fb940 00007fff`f58fed0f clr!ExceptionTracker::CallCatchHandler+0x8b
06 00000000`006fb9d0 00007ff8`0b1b9b6d clr!ProcessCLRException+0x31c
07 00000000`006fbab0 00007ff8`0b14595c ntdll!RtlpExecuteHandlerForUnwind+0xd
08 00000000`006fbae0 00007fff`f5900e10 ntdll!RtlUnwindEx+0x38c
09 00000000`006fc1c0 00007fff`f5900dcf clr!ClrUnwindEx+0x40
0a 00000000`006fc6e0 00007ff8`0b1b9aed clr!ProcessCLRException+0x2e9
0b 00000000`006fc7c0 00007ff8`0b144fe9 ntdll!RtlpExecuteHandlerForException+0xd
0c 00000000`006fc7f0 00007ff8`0b1b8bfa ntdll!RtlDispatchException+0x3a9
0d 00000000`006fcf00 00007ff8`07be1f28 ntdll!KiUserExceptionDispatch+0x3a
0e 00000000`006fd600 00007fff`f58ffbf1 KERNELBASE!RaiseException+0x68
0f 00000000`006fd6e0 00007fff`f58ff9f0 clr!RaiseTheExceptionInternalOnly+0x2f0
10 00000000`006fd7e0 00007fff`e5e85a69 clr!IL_Throw+0x111
11 00000000`006fd990 00007fff`e5e81b79 System_Management_ni!System.Management.ManagementException.ThrowWithExtendedInfo(System.Management.ManagementStatus)+0xc9
12 00000000`006fd9f0 00007fff`9622478b System_Management_ni!System.Management.ManagementObject.Get()+0x199
13 00000000`006fda80 00007fff`962226a0 vs_setup_bootstrapper!Microsoft.VisualStudio.Setup.Bootstrapper.Utilities.GetParentProcess(Microsoft.VisualStudio.Setup.Services.ILogger, Boolean)+0x8b
14 00000000`006fdae0 00007fff`961f2751 vs_setup_bootstrapper!Microsoft.VisualStudio.Setup.Bootstrapper.Program.Parse(System.String[], Microsoft.VisualStudio.Setup.Services.ILogger, System.String, System.String)+0xa0
15 00000000`006fde50 00007fff`961f0514 vs_setup_bootstrapper!Microsoft.VisualStudio.Setup.Bootstrapper.Program.Run(System.String[])+0x131
16 00000000`006fdf10 00007fff`adfeeece vs_setup_bootstrapper!Microsoft.VisualStudio.Setup.Bootstrapper.App.OnStartup(System.Windows.StartupEventArgs)+0x34
17 00000000`006fdf40 00007fff`e22f9bc9 PresentationFramework_ni!System.Windows.Application.<.ctor>b__1_0(System.Object)+0x3e
18 00000000`006fdf80 00007fff`e22f9ac6 WindowsBase_ni!System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)+0x69
19 00000000`006fdff0 00007fff`e22fca2b WindowsBase_ni!System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)+0x36
1a 00000000`006fe040 00007fff`f439a77e WindowsBase_ni!System.Windows.Threading.DispatcherOperation.InvokeImpl()+0x10b
1b 00000000`006fe0c0 00007fff`f439a617 mscorlib_ni!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+0x15e
1c 00000000`006fe190 00007fff`f439a5d2 mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+0x17
1d 00000000`006fe1c0 00007fff`e2513670 mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+0x52
1e 00000000`006fe210 00007fff`e22fc784 WindowsBase_ni!MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object)+0x80
1f 00000000`006fe270 00007fff`e22f7c24 WindowsBase_ni!System.Windows.Threading.DispatcherOperation.Invoke()+0x64
20 00000000`006fe2d0 00007fff`e22f8061 WindowsBase_ni!System.Windows.Threading.Dispatcher.ProcessQueue()+0x1a4
21 00000000`006fe350 00007fff`e22f9e53 WindowsBase_ni!System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)+0x71
22 00000000`006fe3d0 00007fff`e22f9d82 WindowsBase_ni!MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)+0xc3
23 00000000`006fe460 00007fff`e22f9bc9 WindowsBase_ni!MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)+0x82
24 00000000`006fe4b0 00007fff`e22f9ac6 WindowsBase_ni!System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)+0x69
25 00000000`006fe520 00007fff`e22f7583 WindowsBase_ni!System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)+0x36
26 00000000`006fe570 00007fff`e22f94ff WindowsBase_ni!System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)+0x173
27 00000000`006fe610 00007fff`e24c471a WindowsBase_ni!MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)+0x11f
28 00000000`006fe6c0 00007fff`f5897b9e WindowsBase_ni!DomainBoundILStubClass.IL_STUB_ReversePInvoke(Int64, Int32, Int64, Int64)+0x5a
29 00000000`006fe730 00007ff8`092d1169 clr!UMThunkStub+0x6e
2a 00000000`006fe7c0 00007ff8`092d0c97 user32!UserCallWinProcCheckWow+0x1f9
2b 00000000`006fe8b0 00007fff`e2330ee8 user32!DispatchMessageWorker+0x1a7
2c 00000000`006fe930 00007fff`e230d8fc WindowsBase_ni!DomainBoundILStubClass.IL_STUB_PInvoke(System.Windows.Interop.MSG ByRef)+0x78
2d 00000000`006fe9f0 00007fff`ad6998b3 WindowsBase_ni!System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)+0xec
2e 00000000`006fea80 00007fff`ad69969d PresentationFramework_ni!System.Windows.Application.RunDispatcher(System.Object)+0x73
2f 00000000`006feac0 00007fff`961f04b8 PresentationFramework_ni!System.Windows.Application.RunInternal(System.Windows.Window)+0x8d
30 00000000`006feb20 00007fff`f58240b3 vs_setup_bootstrapper!Microsoft.VisualStudio.Setup.Bootstrapper.App.Main()+0x38
31 00000000`006feb50 00007fff`f5823f75 clr!CallDescrWorkerInternal+0x83
32 00000000`006feb90 00007fff`f5824546 clr!CallDescrWorkerWithHandler+0x4e
33 00000000`006febd0 00007fff`f593b6ae clr!MethodDescCallSite::CallTargetWorker+0xf8
34 (Inline Function) ——–`——– clr!MethodDescCallSite::Call+0x1c
35 00000000`006fecd0 00007fff`f593b846 clr!RunMain+0x1e7
36 00000000`006feeb0 00007fff`f593b73e clr!Assembly::ExecuteMainMethod+0xb6
37 00000000`006ff1a0 00007fff`f593b9a3 clr!SystemDomain::ExecuteMainMethod+0x5ea
38 00000000`006ff7d0 00007fff`f593b97a clr!ExecuteEXE+0x3f
39 00000000`006ff840 00007fff`f594dd3c clr!_CorExeMainInternal+0xb2
3a 00000000`006ff8d0 00007fff`f627802d clr!_CorExeMain+0x14
3b 00000000`006ff910 00007fff`f6391184 mscoreei!_CorExeMain+0xe0
3c 00000000`006ff960 00007fff`f63910ab mscoree!ShellShim__CorExeMain+0xb8
3d 00000000`006ff990 00007ff8`088a8102 mscoree!_CorExeMain_Exported+0xb
3e 00000000`006ff9c0 00007ff8`0b16c5b4 kernel32!BaseThreadInitThunk+0x22
3f 00000000`006ff9f0 00000000`00000000 ntdll!RtlUserThreadStart+0x34

As per the error message it appears that the win32_process class is not installed or corrupted on the machine. In order to narrow down the issue we created and execute the C# console application using the steps outline below: 

Create Project:
Create a project (WMITest) which targets 3.5 Framework on a machine that has VS 2015/2017 already installed and build it.

Source Code:
       using System;

using System.Diagnostics;

using System.IO;

using System.Management;

using System.Reflection;

namespace ConsoleApplication1

{

    class Program

    {

        static void Main(string[] args)

        {

            Console.WriteLine(“Start”);

            var processName = Assembly.GetEntryAssembly().GetName().Name;

            Console.WriteLine($”Process Name: {processName}“);

            var directory = Path.GetDirectoryName(Assembly.GetEntryAssembly().Location);

            Console.WriteLine($”Directory Name: {directory}“);

            var parentProcessFullPath = GetParentProcess().MainModule.FileName;

            Console.WriteLine(parentProcessFullPath);

            Console.WriteLine(“End”);

        }

        internal static Process GetParentProcess()

        {

            Console.WriteLine($”Enter GetParentProcess”);

            int Id = Process.GetCurrentProcess().Id;

            Console.WriteLine($”Current ProcessId {Id}“);

            try

            {

                using (ManagementObject mo = new ManagementObject(“win32_process.handle=’” + Id + “‘”))

                {

                    mo.Get();

                    Console.WriteLine($”Parent Id: {mo[“ParentProcessId”]}“);

                    int parentPid = Convert.ToInt32(mo[“ParentProcessId”]);

                    Console.WriteLine($”Parent Id (Int): {parentPid}“);

                    return Process.GetProcessById(parentPid);

                }

            }

            catch(Exception ex)

            {

                Console.WriteLine($”Message {ex.Message} Exception {ex.StackTrace}“);

                return null;

            }

        }

    }

}

The output of the above application (WMITest.Exe) execution (run from an admin cmd prompt):

Start
Process Name: WMITest
Directory Name: c:\WMITest\
Enter GetParentProcess
Current ProcessId 1536
Message Invalid class  Exception at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
   at System.Management.ManagementObject.Get()

Here are the steps to resolve the issue (Reference: WMI: Missing or Failing WMI Providers or Invalid WMI Class):

1. Go to start-run and type in wmimgmt.msc
2. Right click on Local Wmi Control (Local)and select properties
3. Click on the Security tab and expand Root folder. This is where you will see all of the namespace listed for WMI
4. Select the cimv2 namespace as pointed below:

5. If you find the namespace is missing, do the following, otherwise skip to step 6 if the namespace is listed
a. From the command prompt with administrative rights or elevated privileges change directory to C:\Windows\System32\Wbem and run the following command: mofcomp.exe CimWin32.mof
b. For re-registering associated .dll if one exists use following command: regsvr32 CIMWin32.dll
c. Restart the Windows Management Instrumentation Service
d. Go to start-run and type in wmimgmt.msc
e. Right click on Local Wmi Control (Local)and select properties
f. Click on the Security tab and expand Root folder. You can now see cimv2.
6. Create a system restore point (Steps: https://support.microsoft.com/en-us/help/17127/windows-back-up-restore)
7. Execute the console application if there is no error, exit.
a. From the command prompt with administrative rights or elevated privileges, execute the following steps and execute the following this: net stop winmgmt
b. Open a Windows Explorer and locate the path to C:\windows\system32\WBEM\ folder and rename the Repository folder to something else like RepositoryOLD (right click and choose ‘Rename Folder’).
c. restart the computer
d. From the command prompt with administrative rights or elevated privileges, execute the following steps and execute the following this: net stop winmgmt
e. From the command prompt with administrative rights or elevated privileges, execute the following steps and execute the following this: winmgmt /resetRepository
f. restart the computer.
8. Run the c# console app(WMITest.Exe) again. If it executes successfully, then start the VS 2017 Setup. It should resolve the issue.