locked
Error 643 .Microsoft .NET Framework 4.5.2 para Windows 7 sistemas basados en x64 (KB2901983) RRS feed

  • Pregunta

  • Al tratar de instalar esta asctualización continuamente me sale este error 643
    sábado, 1 de agosto de 2015 21:21

Respuestas

  • Bueno, me había confundido momentáneamente, al principio pensé que se trataba de una actualización de seguridad (o de otro tipo) para el .NET 4.5.2 ya instalado. KB2901983 es el identificador del propio .NET Framework 4.5.2, de manera que los nombres de los logs empiezan directamente por "Microsoft .NET Framework 4.5.2 Setup".

    El problema tiene relación con varias actualizaciones recientes que afectan al servicio Windows Installer. La contribución principal es la KB2918614 de agosto de 2014. Las actualizaciones posteriores KB3000988 y KB3008627 intentan mitigar conflictos con algunos paquetes de instalación, pero a veces no es suficiente con tenerlas instaladas y hay que añadir algunas entradas en el registro de Windows. Además apareció en julio de este año la KB3072630, que mantiene los cambios introducidos en la KB2918614. No es aconsejable desinstalar ninguna de ellas.

    Esta es la sección pertinente del TXT del primer enlace, Microsoft .NET Framework 4.5.2 Setup_20150731_174116806-MSI_netfx_Full_GDR_x64.msi.txt:

    MSI (s) (64!3C) [17:41:33:263]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'C:\9dc773f162a13bf91d372f11c941\'.
    MSI (s) (64!3C) [17:41:33:263]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'C:\9dc773f162a13bf91d372f11c941\'.
    MSI (s) (64!3C) [17:41:33:263]: PROPERTY CHANGE: Adding SourcedirProduct property. Its value is '{26784146-6E05-3FF9-9335-786C7C0FB5BE}'.
    MSI (s) (64!3C) [17:41:33:263]: SOURCEDIR ==> C:\9dc773f162a13bf91d372f11c941\
    MSI (s) (64!3C) [17:41:33:263]: SOURCEDIR product ==> {26784146-6E05-3FF9-9335-786C7C0FB5BE}
    MSI (s) (64!3C) [17:41:33:276]: SECREPAIR: CryptAcquireContext: Could not create the default key container
    MSI (s) (64!3C) [17:41:33:276]: Determining source type
    MSI (s) (64!3C) [17:41:33:276]: Source type from package 'netfx_Full_GDR_x64.msi': 0
    MSI (s) (64!3C) [17:41:33:276]: SECREPAIR: Hash Database: C:\Windows\Installer\SourceHash{26784146-6E05-3FF9-9335-786C7C0FB5BE}
    MSI (s) (64!3C) [17:41:33:276]: SECREPAIR: SourceHash database file already exists. Deleting it.
    MSI (s) (64!3C) [17:41:33:332]: Note: 1: 2262 2: SourceHash 3: -2147287038
    MSI (s) (64!3C) [17:41:33:351]: SECREPAIR: New Hash Database creation complete.
    MSI (s) (64!3C) [17:41:33:352]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:997
    MSI (s) (64!3C) [17:41:33:357]: SECUREREPAIR: Failed to CreateContentHash of the file: 1030\SetupResources.dll: for computing its hash. Error: 997
    MSI (s) (64!3C) [17:41:33:358]: SECREPAIR: Failed to create hash for the install source files
    MSI (s) (64!3C) [17:41:33:358]: SECUREREPAIR: SecureRepair Failed. Error code: 3e5EF7244B8
    La acción se inició a las 17:41:33: CA_NgenUpdateHighestVersion_I_RB_amd64.3643236F_FC70_11D3_A536_0090278A1BB8.
    MSI (s) (64!3C) [17:41:33:360]:
    Error 997. Se está ejecutando la operación de E/S superpuesta.

    La acción terminó a las 17:41:33: CA_NgenUpdateHighestVersion_I_RB_amd64.3643236F_FC70_11D3_A536_0090278A1BB8. Valor devuelto 3.

    El problema viene descrito en una entrada de un blog de MSDN y uno de los comentarios amplía la información:
    Error 997. Overlapped I/O operation is in progress: KB2918614 breaks Windows Installer Service (MSDN Blogs)

    Hay varias formas de eludir el problema. Se puede elegir cualquiera de ellas, pero solamente una en un momento dado; si fracasa, se escoge otra. La preferible sería la 3, aunque la 2 resulta más sencilla. La 2 y la 3 se deben deshacer de forma inmediata tras la instalación, si no vuelve a fallar, para mantener la seguridad. Habría que borrar los valores y claves creados, así como modificar los existentes con el contenido que tuvieran anteriormente (por ejemplo, si había un 0 y se puso un 1, volver al 0).

    1. Desinstalar cualquier versión de .NET Framework 4.x que se tenga (sólo a partir de la 4.0) y volver a intentar la instalación de .NET 4.5.2. Las aplicaciones existentes basadas en cualquiera de las versiones de .NET 4.x dejarán de funcionar mientras tanto, ya que Windows 7 no integra ninguna versión de .NET 4.x. No sería tan traumático en Windows 8 y Windows 8.1, que retrocederían a las versiones 4.5 y 4.5.1 respectivamente.
    2. Añadir el valor del registro SecureRepairPolicy (REG_DWORD) y establecerlo a 1 en la clave del registro HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer. Se puede hacer a través de Regedit o escribiendo en una sola línea la siguiente orden en una ventana del símbolo del sistema como administrador (Inicio, escribir CMD, clic derecho y Ejecutar como administrador):

      reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v SecureRepairPolicy /t REG_DWORD /d 1 /f

      Para evitar errores de tecleo, copia la línea entera desde REG hasta /f, ya sea en un paso o por partes, y pégala en la ventana de texto usando clic derecho en la ventana, Pegar, o bien Alt+Espacio (o clic en la esquina superior izquierda), Editar, Pegar.
      Esta es la opción menos segura, pues anula el mecanismo de seguridad introducido en la actualización KB2918614.
    3. Establecer a 2 el valor SecureRepairPolicy del mismo lugar y además crear la clave SecureRepairWhitelist, una lista blanca de identificadores. Dentro de HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer\SecureRepairWhitelist, crear también un valor REG_SZ (valor de cadena) vacío cuyo nombre sea el código de producto del paquete MSI afectado, en este caso {26784146-6E05-3FF9-9335-786C7C0FB5BE} para el paquete netfx_full_GDR_x64.msi. El log lo indica en varios puntos, como se puede ver arriba.

      reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v SecureRepairPolicy /t REG_DWORD /d 2 /f

      reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\SecureRepairWhiteList /v {26784146-6E05-3FF9-9335-786C7C0FB5BE} /t REG_SZ /f

      Se puede omitir /t REG_SZ, pues se da por hecho el tipo REG_SZ si no se especifica /t. La herramienta Reg crea automáticamente la clave SecureRepairWhiteList si no existe; no hace falta un "reg add blablabla\SecureRepairWhitelist" separado.
    4. De otro equipo con el mismo producto instalado, buscar en C:\Windows\Installer el archivo SourceHash cuyo identificador coincida con el código de producto y copiarlo al equipo en el que ocurre el error. La carpeta Installer tiene atributos de oculto y sistema, escribir en ella requerirá privilegios administrativos y el acceso de lectura podría necesitarlo también.

      Ejemplo: trasladar el archivo C:\Windows\Installer\SourceHash{26784146-6E05-3FF9-9335-786C7C0FB5BE} del PC A al PC B.

      Aquí la instalación del paquete netfx_full_GDR_x64.msi de .NET Framework (basado en Windows Installer) reduce el abanico de posibilidades a versiones x64 de Windows que cumplan los siguientes requisitos:
      - Windows Vista, Windows Server 2008, Windows 7 o Windows Server 2008 R2 con .NET Framework 4.0, 4.5, 4.5.1 ó 4.5.2.
      - Windows 8 o Windows Server 2012 con .NET Framework 4.5.1 ó 4.5.2.
      - Windows 8.1 o Windows Server 2012 R2 con .NET Framework 4.5.2.
      Las ediciones x86 no valen porque el paquete netfx_full_GDR_x64.msi no va dirigido a ellas. La versión oportuna de .NET Framework 4.x ha tenido que instalarse (o quizá repararse) después de la actualización de seguridad KB2918614 para que se haya generado el fichero SourceHash correspondiente.

    Otras referencias:

    Conforme vaya aprendiendo más sobre este inconveniente y las circunstancias que lo originan, iré refinando y tratando de simplificar las opciones posibles de resolución.

    • Propuesto como respuesta Moderador M lunes, 3 de agosto de 2015 17:43
    • Marcado como respuesta Moderador M miércoles, 5 de agosto de 2015 15:48
    lunes, 3 de agosto de 2015 0:08

Todas las respuestas

  • El error 643, conversión hexadecimal del número 1603, indica un fallo general de Windows Installer. Para intentar determinar la causa hay que examinar los logs que deja el proceso de instalación de .NET Framework y sus actualizaciones, bien en la carpeta temporal de la cuenta de usuario, representada por la variable de entorno TEMP (tipo C:\Users\<usuario>\AppData\Local\Temp), o bien en C:\Windows\Temp. Concretamente se deben revisar los archivos .txt, sobre todo el más reciente, cuyo nombre contenga "KB2901983", el identificador de la actualización que falla.

    Se puede buscar el texto "return value 3" o "valor devuelto 3" (sin comillas) y pegar como respuesta varias de las líneas anteriores y posteriores, las que se vea que pueden aportar cierto contexto al problema, o por otro lado enviar los logs completos a un servicio de alojamiento (Dropbox, Google Drive, OneDrive, etc.) y compartir un enlace de descarga para poder echarles un ojo más detenidamente.

    domingo, 2 de agosto de 2015 0:09
  • Hola gracias por interesarte por mi problema.

    El archivo de texto de la instalación está aquí: https://drive.google.com/file/d/0B6NnMQ1uqC_JSnRxQTBDczNNa3M/view?usp=sharing

    El archivo LOG: https://drive.google.com/file/d/0B6NnMQ1uqC_JRmp5bWF3TzFUNDQ/view?usp=sharing

    domingo, 2 de agosto de 2015 10:18
  • Bueno, me había confundido momentáneamente, al principio pensé que se trataba de una actualización de seguridad (o de otro tipo) para el .NET 4.5.2 ya instalado. KB2901983 es el identificador del propio .NET Framework 4.5.2, de manera que los nombres de los logs empiezan directamente por "Microsoft .NET Framework 4.5.2 Setup".

    El problema tiene relación con varias actualizaciones recientes que afectan al servicio Windows Installer. La contribución principal es la KB2918614 de agosto de 2014. Las actualizaciones posteriores KB3000988 y KB3008627 intentan mitigar conflictos con algunos paquetes de instalación, pero a veces no es suficiente con tenerlas instaladas y hay que añadir algunas entradas en el registro de Windows. Además apareció en julio de este año la KB3072630, que mantiene los cambios introducidos en la KB2918614. No es aconsejable desinstalar ninguna de ellas.

    Esta es la sección pertinente del TXT del primer enlace, Microsoft .NET Framework 4.5.2 Setup_20150731_174116806-MSI_netfx_Full_GDR_x64.msi.txt:

    MSI (s) (64!3C) [17:41:33:263]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'C:\9dc773f162a13bf91d372f11c941\'.
    MSI (s) (64!3C) [17:41:33:263]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'C:\9dc773f162a13bf91d372f11c941\'.
    MSI (s) (64!3C) [17:41:33:263]: PROPERTY CHANGE: Adding SourcedirProduct property. Its value is '{26784146-6E05-3FF9-9335-786C7C0FB5BE}'.
    MSI (s) (64!3C) [17:41:33:263]: SOURCEDIR ==> C:\9dc773f162a13bf91d372f11c941\
    MSI (s) (64!3C) [17:41:33:263]: SOURCEDIR product ==> {26784146-6E05-3FF9-9335-786C7C0FB5BE}
    MSI (s) (64!3C) [17:41:33:276]: SECREPAIR: CryptAcquireContext: Could not create the default key container
    MSI (s) (64!3C) [17:41:33:276]: Determining source type
    MSI (s) (64!3C) [17:41:33:276]: Source type from package 'netfx_Full_GDR_x64.msi': 0
    MSI (s) (64!3C) [17:41:33:276]: SECREPAIR: Hash Database: C:\Windows\Installer\SourceHash{26784146-6E05-3FF9-9335-786C7C0FB5BE}
    MSI (s) (64!3C) [17:41:33:276]: SECREPAIR: SourceHash database file already exists. Deleting it.
    MSI (s) (64!3C) [17:41:33:332]: Note: 1: 2262 2: SourceHash 3: -2147287038
    MSI (s) (64!3C) [17:41:33:351]: SECREPAIR: New Hash Database creation complete.
    MSI (s) (64!3C) [17:41:33:352]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:0
    MSI (s) (64!3C) [17:41:33:357]: SECREPAIR: Crypt Provider not initialized. Error:997
    MSI (s) (64!3C) [17:41:33:357]: SECUREREPAIR: Failed to CreateContentHash of the file: 1030\SetupResources.dll: for computing its hash. Error: 997
    MSI (s) (64!3C) [17:41:33:358]: SECREPAIR: Failed to create hash for the install source files
    MSI (s) (64!3C) [17:41:33:358]: SECUREREPAIR: SecureRepair Failed. Error code: 3e5EF7244B8
    La acción se inició a las 17:41:33: CA_NgenUpdateHighestVersion_I_RB_amd64.3643236F_FC70_11D3_A536_0090278A1BB8.
    MSI (s) (64!3C) [17:41:33:360]:
    Error 997. Se está ejecutando la operación de E/S superpuesta.

    La acción terminó a las 17:41:33: CA_NgenUpdateHighestVersion_I_RB_amd64.3643236F_FC70_11D3_A536_0090278A1BB8. Valor devuelto 3.

    El problema viene descrito en una entrada de un blog de MSDN y uno de los comentarios amplía la información:
    Error 997. Overlapped I/O operation is in progress: KB2918614 breaks Windows Installer Service (MSDN Blogs)

    Hay varias formas de eludir el problema. Se puede elegir cualquiera de ellas, pero solamente una en un momento dado; si fracasa, se escoge otra. La preferible sería la 3, aunque la 2 resulta más sencilla. La 2 y la 3 se deben deshacer de forma inmediata tras la instalación, si no vuelve a fallar, para mantener la seguridad. Habría que borrar los valores y claves creados, así como modificar los existentes con el contenido que tuvieran anteriormente (por ejemplo, si había un 0 y se puso un 1, volver al 0).

    1. Desinstalar cualquier versión de .NET Framework 4.x que se tenga (sólo a partir de la 4.0) y volver a intentar la instalación de .NET 4.5.2. Las aplicaciones existentes basadas en cualquiera de las versiones de .NET 4.x dejarán de funcionar mientras tanto, ya que Windows 7 no integra ninguna versión de .NET 4.x. No sería tan traumático en Windows 8 y Windows 8.1, que retrocederían a las versiones 4.5 y 4.5.1 respectivamente.
    2. Añadir el valor del registro SecureRepairPolicy (REG_DWORD) y establecerlo a 1 en la clave del registro HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer. Se puede hacer a través de Regedit o escribiendo en una sola línea la siguiente orden en una ventana del símbolo del sistema como administrador (Inicio, escribir CMD, clic derecho y Ejecutar como administrador):

      reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v SecureRepairPolicy /t REG_DWORD /d 1 /f

      Para evitar errores de tecleo, copia la línea entera desde REG hasta /f, ya sea en un paso o por partes, y pégala en la ventana de texto usando clic derecho en la ventana, Pegar, o bien Alt+Espacio (o clic en la esquina superior izquierda), Editar, Pegar.
      Esta es la opción menos segura, pues anula el mecanismo de seguridad introducido en la actualización KB2918614.
    3. Establecer a 2 el valor SecureRepairPolicy del mismo lugar y además crear la clave SecureRepairWhitelist, una lista blanca de identificadores. Dentro de HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer\SecureRepairWhitelist, crear también un valor REG_SZ (valor de cadena) vacío cuyo nombre sea el código de producto del paquete MSI afectado, en este caso {26784146-6E05-3FF9-9335-786C7C0FB5BE} para el paquete netfx_full_GDR_x64.msi. El log lo indica en varios puntos, como se puede ver arriba.

      reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v SecureRepairPolicy /t REG_DWORD /d 2 /f

      reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\SecureRepairWhiteList /v {26784146-6E05-3FF9-9335-786C7C0FB5BE} /t REG_SZ /f

      Se puede omitir /t REG_SZ, pues se da por hecho el tipo REG_SZ si no se especifica /t. La herramienta Reg crea automáticamente la clave SecureRepairWhiteList si no existe; no hace falta un "reg add blablabla\SecureRepairWhitelist" separado.
    4. De otro equipo con el mismo producto instalado, buscar en C:\Windows\Installer el archivo SourceHash cuyo identificador coincida con el código de producto y copiarlo al equipo en el que ocurre el error. La carpeta Installer tiene atributos de oculto y sistema, escribir en ella requerirá privilegios administrativos y el acceso de lectura podría necesitarlo también.

      Ejemplo: trasladar el archivo C:\Windows\Installer\SourceHash{26784146-6E05-3FF9-9335-786C7C0FB5BE} del PC A al PC B.

      Aquí la instalación del paquete netfx_full_GDR_x64.msi de .NET Framework (basado en Windows Installer) reduce el abanico de posibilidades a versiones x64 de Windows que cumplan los siguientes requisitos:
      - Windows Vista, Windows Server 2008, Windows 7 o Windows Server 2008 R2 con .NET Framework 4.0, 4.5, 4.5.1 ó 4.5.2.
      - Windows 8 o Windows Server 2012 con .NET Framework 4.5.1 ó 4.5.2.
      - Windows 8.1 o Windows Server 2012 R2 con .NET Framework 4.5.2.
      Las ediciones x86 no valen porque el paquete netfx_full_GDR_x64.msi no va dirigido a ellas. La versión oportuna de .NET Framework 4.x ha tenido que instalarse (o quizá repararse) después de la actualización de seguridad KB2918614 para que se haya generado el fichero SourceHash correspondiente.

    Otras referencias:

    Conforme vaya aprendiendo más sobre este inconveniente y las circunstancias que lo originan, iré refinando y tratando de simplificar las opciones posibles de resolución.

    • Propuesto como respuesta Moderador M lunes, 3 de agosto de 2015 17:43
    • Marcado como respuesta Moderador M miércoles, 5 de agosto de 2015 15:48
    lunes, 3 de agosto de 2015 0:08
  • oye me podrías ayudar esto es lo que me aparece a mi en el archivo txt y tengo el mismo error "643"

    [8/3/2015, 15:0:36] === Logging started: 2015/08/03 15:00:36 ===
    [8/3/2015, 15:0:36] Executable: C:\Windows\SoftwareDistribution\Download\Install\ndp452-kb2901983-x86-x64-esn.exe v4.5.51209.34209
    [8/3/2015, 15:0:36] --- logging level: standard ---
    [8/3/2015, 15:0:36] Successfully bound to the ClusApi.dll
    [8/3/2015, 15:0:36] Error 0x80070424: Failed to open the current cluster
    [8/3/2015, 15:0:36] Cluster drive map: ''
    [8/3/2015, 15:0:36] Considering drive: 'C:\'...
    [8/3/2015, 15:0:36] Considering drive: 'D:\'...
    [8/3/2015, 15:0:36] Drive 'D:\' is rejected because of the unknown or unsuitable drive type
    [8/3/2015, 15:0:36] Drive 'C:\' has been selected as the largest fixed drive
    [8/3/2015, 15:0:36] Directory 'C:\5f17b928ac746d6d00f08f6159e9ffe7\' has been selected for file extraction
    [8/3/2015, 15:0:36] Extracting files to: C:\5f17b928ac746d6d00f08f6159e9ffe7\
    [8/3/2015, 15:0:38] Extraction took 2.371 seconds
    [8/3/2015, 15:0:38] Executing command line: 'C:\5f17b928ac746d6d00f08f6159e9ffe7\\Setup.exe  /q /norestart /chainingpackage NETFX45WURTM /x86 /x64 /lcid 3082 /lpredist'
    [8/3/2015, 15:2:2] Exiting with result code: 0x0
    [8/3/2015, 15:2:2] === Logging stopped: 2015/08/03 15:02:02 ===

    por favor ayúdame es la única actualización que me falta para instalar windows 10

    lunes, 3 de agosto de 2015 20:07
  • me podrias ayudar, esto es lo que me aparece a mi en el archivo txt

    [8/3/2015, 15:0:36] === Logging started: 2015/08/03 15:00:36 ===
    [8/3/2015, 15:0:36] Executable: C:\Windows\SoftwareDistribution\Download\Install\ndp452-kb2901983-x86-x64-esn.exe v4.5.51209.34209
    [8/3/2015, 15:0:36] --- logging level: standard ---
    [8/3/2015, 15:0:36] Successfully bound to the ClusApi.dll
    [8/3/2015, 15:0:36] Error 0x80070424: Failed to open the current cluster
    [8/3/2015, 15:0:36] Cluster drive map: ''
    [8/3/2015, 15:0:36] Considering drive: 'C:\'...
    [8/3/2015, 15:0:36] Considering drive: 'D:\'...
    [8/3/2015, 15:0:36] Drive 'D:\' is rejected because of the unknown or unsuitable drive type
    [8/3/2015, 15:0:36] Drive 'C:\' has been selected as the largest fixed drive
    [8/3/2015, 15:0:36] Directory 'C:\5f17b928ac746d6d00f08f6159e9ffe7\' has been selected for file extraction
    [8/3/2015, 15:0:36] Extracting files to: C:\5f17b928ac746d6d00f08f6159e9ffe7\
    [8/3/2015, 15:0:38] Extraction took 2.371 seconds
    [8/3/2015, 15:0:38] Executing command line: 'C:\5f17b928ac746d6d00f08f6159e9ffe7\\Setup.exe  /q /norestart /chainingpackage NETFX45WURTM /x86 /x64 /lcid 3082 /lpredist'
    [8/3/2015, 15:2:2] Exiting with result code: 0x0
    [8/3/2015, 15:2:2] === Logging stopped: 2015/08/03 15:02:02 ===

    tengo el error 643

    por favor ayúdame es la unica actualizacion que me falta para instalar windows 10 

    lunes, 3 de agosto de 2015 20:18
  • Ese extracto no es útil. ¿Seguro que es la instalación de .NET Framework 4.5.2 la que falla? De todos modos, hay que iniciar una consulta nueva y no continuar en esta, pues el problema puede ser completamente distinto.

    lunes, 3 de agosto de 2015 21:53
  • Hola Ramón,

    Muchas gracias por tu ayuda; utilicé la opción 3 y se instaló perfectamente.

    Luego borre la clave nueva y puse la otra al valor "0" (creo que ese era el valor original).

    ¿Está bien Hecho?.

    Tras instalarlo, me vinieron  actualizaciones sobre ella y se instalaron perfectamente.

    Ahora tengo problemas con 2 actualizaciones de SQL, pero para eso iniciaré un hilo nuevo; si estás por ahí, haber si también me puedes ayudar.

    Gracias de nuevo.

    domingo, 9 de agosto de 2015 16:30
  • Gracias por la confirmación. Efectivamente, si no existe el valor SecureRepairPolicy se considera igual a cero. Eliminarlo o dejarlo en cero es lo mismo, y con cero o 1 el contenido de la subclave SecureRepairWhitelist no tiene efecto (solamente lo tiene cuando es 2).
    lunes, 10 de agosto de 2015 0:00