Share via

Visual Studio 2012 fails with an error 'The pipe is being closed'

  • Article

The Microsoft Visual Studio 2012 OR Visual Studio 2012 Update 3 install may fail with the below error message: 

 

Error

 

After reviewing the Setup failure log dd_vs_****_201308291*****.log, I found the below failure message:  

 [0690:23A4][2013-07-29T17:00:28]: MUX:  Source confirmed
[0690:23A4][2013-07-29T17:00:28]: Acquiring package: webdeploy_x86_en_usmsi_901, payload: webdeploy_x86_en_usmsi_901, copy from: C:\VS2012_ISO\packages\WebDeploy\WebDeploy_x86.msi
[0690:23A4][2013-07-29T17:00:29]: Error 0xc000000d: Failed to get signer chain from authenticode certificate.
[1638:1934][2013-09-03T22:42:51]: Error 0x800700e8: Failed to write message type to pipe.

 

Another log snippet from Visual Studio 2012 UPDATE 3:

[1638:1934][2013-09-03T22:42:51]: Error 0x800700e8: Failed to register the dependency on per-machine package.
[1638:1934][2013-09-03T22:42:51]: Error 0x800700e8: Failed to execute dependency action.
[1638:0B30][2013-09-03T22:42:51]: Error 0x80070642: BA aborted copy of payload from: 'C:\VS2012.3\packages\WinACK\Windows App Certification Kit x64-x86_en-us.msp' to: C:\Users\ADMINI~1\AppData\Local\Temp\{29828f33-4679-462a-8c98-1c3507678922}\WinACK_x64_x86_en.
[1638:0B30][2013-09-03T22:42:54]:
Failed to acquire payload: WinACK_x64_x86_en to working path: C:\Users\ADMINI~1\AppData\Local\Temp\{29828f33-4679-462a-8c98-1c3507678922}\WinACK_x64_x86_en, error: 0x80070642. [1638:0B30][2013-09-03T22:42:54]: Error 0x800700e8: Failed to write message type to pipe.

So, I used signtool.exe to verify the digital signature of the file listed in the above error message (SignTool is available as part of the Windows SDK, which you can download from https://go.microsoft.com/fwlink/p/?linkid=84091):

C:\>signtool verify -pa -v "c:\VS2012.3\packages\WinACK\Windows App Certification Kit Native Components-x64_en-us.msp"

 

Verifying: c:\VS2012.3\packages\WinACK\Windows App Certification Kit Native Components-x64_en-us.msp

Hash of file (SHA-256): 7242C5E45B7D51EF98FFC1B64A739281B06CE52C8F920952FF33808AEDC9D2CE

Signing Certificate Chain:

    Issued to: Microsoft Root Certificate Authority 2011

    Issued by: Microsoft Root Certificate Authority 2011

    Expires: Sat Mar 22 17:13:04 2036

    SHA1 hash: 8F43288AD272F3103B6FB1428485EA3014C0BCFE

        Issued to: Microsoft Code Signing PCA 2011

        Issued by: Microsoft Root Certificate Authority 2011

        Expires: Wed Jul 08 16:09:09 2026

        SHA1 hash: F252E794FE438E35ACE6E53762C0A234A2C52135

            Issued to: Microsoft Corporation

            Issued by: Microsoft Code Signing PCA 2011

            Expires: Sun Oct 06 19:14:32 2013

            SHA1 hash: BCA0A72FBF7C3A6666CBB15EEB450A3AE6F14A48

 

File is not timestamped.

SignTool Error: WinVerifyTrust returned error: 0xC000000D

 

Number of files successfully Verified: 0

Number of warnings: 0

Number of errors: 1 

 

Even looking at the digital signature property of the same file, I found the below error (Right Click on the file -> select Properties -> Click on “Digital Signatures” tab):

 

 Untitled  

                                         

 Cert_Error

 

Hence, I captured CAPI2 events logged through the Microsoft-Windows-CAPI2 channel in the event log. The events are based on the common CAPI, which is part of the certificate path validation process. I found the below information from CAPI2 events log:

  

<Event xmlns="**https://schemas.microsoft.com/win/2004/08/events/event**"\>

<System>

<Provider Name="Microsoft-Windows-CAPI2" Guid=" {5bbca4a8-b209-48dc-a8c7-b23d3e5216fb} " />

<EventID>81</EventID>

<Version>0</Version>

<Level>2</Level>

<Task>80</Task>

<Opcode>2</Opcode>

<Keywords>0x4000000000000040</Keywords>

<TimeCreated SystemTime="2013-09-05T19:15:11.964667100Z" />

<EventRecordID>1665</EventRecordID>

<Correlation />

<Execution ProcessID="9012" ThreadID="948" />

<Channel>Microsoft-Windows-CAPI2/Operational</Channel>

<Computer>COMPUTER1</Computer>

<Security UserID="S-1-5-21-2826430686-930391821-3413531744-500" />

</System>

           <UserData>

 <WinVerifyTrust>

<ActionID> {00AAC56B-CD44-11D0-8CC2-00C04FC295EE} </ActionID>

<UIChoice value="2">WTD_UI_NONE</UIChoice>

<RevocationCheck value="0" />

<StateAction value="1">WTD_STATEACTION_VERIFY</StateAction>

<Flags value="80000080" WTD_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT="true" CPD_USE_NT5_CHAIN_FLAG="true" />

<FileInfo filePath="C:\ProgramData\Package Cache\.unverified\WinACK_native_x64_en" hasFileHandle="true" />

<DigestInfo digestAlgorithm="" digest="7242C5E45B7D51EF98FFC1B64A739281B06CE52C8F920952FF33808AEDC9D2CE" />

<RegPolicySetting value="23C00" WTPF_OFFLINEOK_IND="true" WTPF_OFFLINEOK_COM="true" WTPF_OFFLINEOKNBU_IND="true" WTPF_OFFLINEOKNBU_COM="true" WTPF_IGNOREREVOCATIONONTS="true" />

           <SignerInfo>

<DigestAlgorithm oid="2.16.840.1.101.3.4.2.1" />

</SignerInfo>

<CertificateChain chainRef=" {7BDEEF41-63C5-49DD-B819-F6C007B1D045} " />

 <StepError stepID="16" stepName="TRUSTERROR_STEP_MSG_COUNTERSIGINFO">

<Result value="80096005">The timestamp signature and/or certificate could not be verified or is malformed. </Result>

</StepError>

  <StepError stepID="33" stepName="TRUSTERROR_STEP_FINAL_SIGPROV">

<Result value="C000000D" />

</StepError>

< EventAuxInfo ProcessName="VS2012.3.exe" />

<CorrelationAuxInfo TaskId=" {AD5981CA-F431-4A74-AF30-2CCC10DBC92D} " SeqNumber="9" />

<Result value="C000000D" />

</WinVerifyTrust>

</UserData>

</Event>

 

After further debugging, I found a bunch of custom OID registrations under the registry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo\]. Many registry keys under CryptDllFindOIDInfo were written by third party applications. In my scenario, I found there was an application called “Entrust Entelligence Security Provider for Windows” which added those registry keys. Entrust registers another copy of the sha256 hash algorithm OID with a legacy name of “SHA-256”, and the AlgId field not set to 0xffffffff (it uses 0x800c, or CALG_SHA_256) and does not set the CNG algorithm name field at all. This causes CAPI2 to find the Entrust OID registration instead of the built-in OID registration, that would cause CNG-based sha256 signature validation to fail. CAPI2 only uses CNG providers for sha2 hash algorithms, so this could be fatal to all sha256 signature validation. In order to resolve the issue, please add the below highlighted entry in the registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo\2.16.840.1.101.3.4.2.1!1]
"Name"="SHA-256"
"Algid"=dword:0000800c
"CNGAlgid"="SHA256"
"Flags"=dword:00000001

You may also execute the Fix_it.reg file attached with this blog. Another workaround would be to temporarily uninstall “Entrust Entelligence Security Provider for Windows” from Control panel/ARP and reboot the system. Then install the Visual Studio 2012/ Update3. Once, it is completed, please reinstall “Entrust Entelligence Security Provider for Windows”. 

 

 

Important: Please note that serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base: How to back up and restore the registry in Windows

Fix_it.zip

Comments

  • Anonymous
    April 06, 2016
    Thank you! I spent days researching this issue without a fix. Finally found this article and worked like a charm after uninstalling Entrust.