¿Cómo puedo determinar qué causa la reparación automática de Windows Installer repetida?

  • ¿Cómo puedo registrar solo los cambios que provocan que un archivo MSI creado por Installshield 2008 se reinstale a través de ” autorreparación “?
  • ¿Cuál es el motivo de la auto reparación?
  • ¿Cómo desactivo la autorreparación de MSI utilizando Installshield 2008?

Respuesta alternativa disponible

ACTUALIZACIÓN : hay una respuesta más corta, más “enfocada en la solución” disponible , quizás pruébela primero. Esta respuesta se centra en “comprender la autorreparación” en lugar de explicar los pasos a seguir para eliminar el problema. También puede leer la primera sección de esta respuesta.


Problemas inesperados de reparación de Windows Installer – ¿Corrección rápida?

Este “artículo” se ha vuelto extenso y algo ilegible. Aquí hay un preámbulo recién escrito: la versión abreviada de ” solución temporal ” para corregir reparaciones inesperadas (a menudo se encuentran en VB6, Visual Studio, MS Office, MS Outlook, AutoCAD, etc.)

  • Si experimenta una autoreparación inesperada , lo primero que puede intentar es crear manualmente un acceso directo de escritorio directamente al ejecutable de la aplicación que está iniciando cuando se produce el problema. Esto pasa por alto el desencadenante más común de autorreparación, ” el atajo publicitado “. Si esto funciona, su problema se “resuelve” (o se evita). Aquí hay una explicación rápida y concreta
  • Si el problema persiste o su problema está relacionado con la carga de un complemento de MS Office , MS Outlook o similar (que no se puede iniciar mediante un acceso directo), es muy probable que tenga un conflicto de registro COM en su sistema , y la solución es mucho más complicada. Lo más fácil de intentar es desactivar cualquier complemento que no necesite en el cuadro de diálogo de complementos de la aplicación en cuestión y ver si esto hace que el problema desaparezca.
  • Si aún ve problemas, lo más probable es que necesite depurar un conflicto genuino de registro COM (o asociaciones conflictivas de archivos / MIME o verbos de comandos). Esto normalmente implica (al menos) dos aplicaciones conflictivas en su sistema que “luchan” actualizando el registro en cada lanzamiento después de que la otra aplicación se haya ejecutado (siempre el lanzamiento de una de las aplicaciones no activará la auto reparación, el conflicto aparece cuando alternas entre las aplicaciones). También es posible que los problemas de permisos provoquen que la misma aplicación no actualice el sistema y siga intentándolo sin parar ejecutando repetidamente la reparación automática. Y hay más posibilidades, más detalles a continuación
    • La ” solución real ” es contactar a ambos proveedores de aplicaciones y pedirles una solución para el problema (ya que una solución a menudo requiere una solución de ambas MSI de proveedores), pero en mi experiencia, esto rara vez tiene éxito. Sin embargo, pruébalo, ya que esta es la manera de ayudar a todos con una molestia de larga data. Personalmente proporcioné una configuración con arreglos para una implementación bancaria y estuve muy feliz de tener el problema resuelto en mi paquete
    • Para depurarse, necesita obtener una herramienta para abrir archivos MSI almacenados en caché en el sistema y debe “piratear” la base de datos, una tarea muy complicada que requiere habilidades de expertos , se le aconsejaría buscar un experto en instalación para obtener ayuda si el problema es muy serio para su entorno de escritorio. Puede funcionar, pero no esperes milagros.
    • Consulte la sección siguiente llamada ” Encontrar el desencadenante o el culpable de la reparación automática ” para obtener más información sobre cómo obtener una herramienta para ver y modificar archivos MSI.

El rest del “artículo” describe los problemas de auto reparación en profundidad. Hay muchas otras posibles causas de auto reparación que lo que se describe en esta sección “breve”.


Problema general: depuración del desarrollador y auto reparación

Windows Installer es una tecnología de implementación , su tarea es instalar los archivos especificados y la configuración del registro, y mantenerlos en las ubicaciones de instalación especificadas y garantizar que sean las versiones correctas; la reparación automática o la flexibilidad es un mecanismo para ese fin. Su funcionamiento entra en conflicto con los desarrolladores que necesitan intercambiar archivos sobre la marcha para la depuración, el desarrollo y las pruebas.

En consecuencia, muchas auto reparaciones (resiliencia) se activan simplemente por los desarrolladores que intentan depurar su aplicación instalada y intercambian archivos en caliente sobre la marcha. Consulte la sección 2 en ” Algunos escenarios típicos de problemas de reparación automática ” a continuación para saber cómo manejar esto. En otros casos, hay errores de diseño genuinos en el MSI que deben corregirse o riesgos de administración del sistema que conducen a la reparación automática, y en ocasiones la fuente del error puede ser difícil de encontrar.

He escrito sobre el problema de la reparación automática en una respuesta en serverfault.com . Palabras ligeramente diferentes destinadas a los administradores del sistema , y leyéndolas ahora podría ser una explicación más accesible que esta larga (pensada para desarrolladores). También hay otra respuesta más corta aquí en stackoverflow: ¿Por qué el instalador MSI se reconfigura si elimino un archivo? (Este es probablemente el más corto y el más fácil de entender). Y finalmente encontré un artículo muy bueno sobre la auto reparación de Vadim Rapp : Cómo arreglar los esfuerzos de Windows Installer para su reparación . Este artículo vale la pena leerlo.

No se realizará ninguna reparación automática si Windows Installer determina que el producto que se está iniciando está instalado correctamente. Cuando se produce la reparación automática, se debe modificar algo en el sistema para que la aplicación se ejecute correctamente.


Las principales causas de la auto reparación

Los detalles se presentan a continuación en la sección ” Algunos escenarios típicos de problemas de reparación automática “, pero como una lista rápida y presagiada : las principales causas son:

1. Archivos MSI corporativos mal empaquetados o fallas de diseño de MSI del proveedor (el paquete MSI mismo está mal diseñado y desencadena la reparación automática inesperadamente por una variedad de razones)

  • Uso excesivo o erróneo de archivos por usuario o claves de registro por usuario a menudo con rutas de clave erróneas configuradas en el perfil de usuario (en lugar de HKCU). Consulte la sección 5 a continuación para obtener más detalles (y una ilustración en color de dicha situación)
  • Interferencia del paquete a partir del registro erróneo del servidor COM (especialmente los archivos COM VB6 o los archivos VBA y las bibliotecas de productos como AutoCAD de Autodesk y productos similares).
    • Dos paquetes de MSI registran el mismo archivo COM (ActiveX / OCX) desde dos ubicaciones diferentes y “pelea de reparación automática” en cada inicio de aplicación para mantener su versión correctamente registrada.
    • La última aplicación para iniciar pone al registro en orden por sí mismo, y dura hasta que se lanza la otra aplicación y hace lo mismo. Una vez que alternas entre las aplicaciones, se produce el problema. Consulte la sección 7 a continuación para obtener más información sobre la reparación automática de VB / COM
  • Una ruta de clave de componente se establece en una carpeta vacía que el instalador de Windows elimina en la reparación automática (lo que desencadena un ciclo infinito de eliminación y la posterior reparación automática)
  • Problemas de permiso de locking de ACL (el usuario que inició sesión no puede acceder al archivo de clave y Windows Installer activa la reparación de forma repetida). Esto también puede ser causado por cambios en la ACL realizados externamente, pero a menudo lo hace el propio MSI
  • Este es un trabajo en progreso de serverfault.com que describe fallas comunes de diseño de MSI

2. Los archivos o claves de registro se eliminan por la interferencia de causas externas que van desde scripts (de inicio de sesión) hasta funciones estándar del sistema operativo, virus, software de seguridad, etc.

  • Los archivos temporales son eliminados automáticamente por Windows después de ser erróneamente instalados en la carpeta temporal por un paquete MSI
  • Interferencia de inicios de sesión incorrectos y activación de scripts de limpieza y aplicaciones de limpieza
  • Aplicaciones antivirus que bloquean o eliminan archivos o claves de registro para que Windows Installer ya no pueda detectarlos o acceder a ellos
  • Virus informáticos que cambian o eliminan archivos y configuraciones de registro
  • Los usuarios y usuarios de computadoras hiperactivos eliminan archivos y configuraciones que no entienden

3. Cambios en el diseño de Windows, fallas o restricciones que causan una implementación defectuosa o defectuosa

  • Un paquete MSI anunciado por AD no se puede instalar (puede ser cancelado ya que lleva mucho tiempo instalarlo) y sigue molestando a las personas. En sentido estricto, esto no es una reparación automática, sino una instalación anunciada que se cancela, pero el resultado es el mismo: volver a instalar sin fin
  • Complicaciones del servidor terminal La autorreparación generalmente se deshabilita por completo en los servidores de terminales. Esto normalmente no causa problemas de reparación automática, pero la aplicación se instala sin los archivos requeridos por usuario o las claves de registro que se pueden agregar a través del uso benigno de la reparación automática (lea a continuación). Los archivos de usuario y las claves de registro de usuario simplemente faltan y los problemas resultan
  • Interferencia de UAC , falla de validación de certificados y otros problemas resultantes de los cambios de diseño de Windows . Para cada versión de Windows se agregan funciones de seguridad como estas y normalmente terminan agregando nuevos obstáculos para una implementación confiable
  • Incluso ciertas actualizaciones de Windows (actualizaciones, actualizaciones de seguridad, revisiones, etc.) pueden hacer cambios drásticos en la forma en que se aplica la seguridad para los paquetes MSI y, por lo tanto, provocan un comportamiento extremadamente problemático.
    • Aunque esto se relaciona con la creación de MSI, y no principalmente con su uso del usuario final, la Actualización de Windows KB3004394 que actualiza la forma en que Windows busca certificados raíz revocados , rompe la versión anterior de la línea de comandos de Installshield (para configuraciones que fueron firmadas digitalmente). En gran medida, se trata de un problema resuelto, pero una ilustración de cómo Microsoft sigue cambiando la funcionalidad básica de MSI
    • De manera similar, Installshield se bloqueó para muchos usuarios después de instalar la actualización de Microsoft MS14-037 “Actualización de seguridad para Internet Explorer versiones 6, 7, 8, 9, 10 y 11” (KB2962872)
    • Se produjo un cambio extremadamente problemático en la funcionalidad básica de Windows Installer después de instalar kb2918614 (Vista). De repente, se requirieron credenciales de administrador para una operación simple de reparación de MSI . Esto eliminó por completo un beneficio central de MSI: la capacidad de los usuarios habituales para ejecutar instalaciones aprobadas con derechos administrativos temporales . También hubo otros problemas de MSI informados después de instalar esa solución. Parece que otra actualización de Windows solucionó los problemas: kb3008627 (luego reemplazado por kb3072630)

Acerca de la auto reparación

Windows Installer está diseñado para instalar los archivos binarios, las configuraciones y los archivos de datos de su aplicación y mantenerlos instalados y asegurarse de que sean las versiones correctas. La autorreparación es un mecanismo para ese fin. El concepto general se llama resiliencia , es decir, una instalación interrumpida desencadena una reparación automática antes de que se inicie la aplicación.

La capacidad de recuperación , o reparación automática, es un concepto principal integrado de Windows Installer y no se puede desactivar de manera segura. La gente hace las cosas más increíbles a veces, como deshabilitar todo el motor de Windows Installer para detener su auto reparación. Esto obviamente nunca debe hacerse. Se debe identificar la causa de la reparación y resolver el problema en lugar de crear nuevas, o piratear el sistema.

Cada vez que inicie un acceso directo publicitado (esencialmente un acceso directo especial que apunta a una característica de Windows Installer y no directamente a un archivo), Windows Installer verificará la instalación comprobando las ” rutas clave de componentes ” para su producto. Si se encuentra una discrepancia, se activa una reparación para corregir la instalación incompleta. Las “rutas de clave de componente” son los “archivos de clave” especificados para los componentes dentro de su MSI; hay uno por componente. La auto reparación también puede ser iniciada por alguien instanciando un servidor COM (o intentando), alguien activando un archivo a través de su extensión de archivo o registro MIME, y algunas otras formas. Aquí hay un artículo completo de Symantec sobre el tema de los “puntos de entrada de autorreparación”: Inicio de funciones de reparación y publicidad con Entry Point .

Si los archivos se eliminan, mueven o simplemente se sobrescriben (manualmente por un usuario o de alguna manera automáticamente), puede producirse una reparación automática (si el archivo o la configuración del registro no están configurados como una ruta clave, no se activa la reparación automática).


Encontrar el desencadenante o culpable de la auto reparación

En general, es posible encontrar el desencadenante de la reparación automática en el visor de eventos en el sistema en el que se realizó la autoreparación. Siga estos pasos para abrir el visor de eventos :

  • Haga clic derecho en “Mi computadora”
  • Haga clic Administrar
  • Haga clic en continuar si recibe un aviso de UAC
  • Vaya a la sección Visor de eventos y verifique los registros de Windows

Alternativamente, puede hacer: Start => Run … => eventvwr.exe solo para el visor de eventos. Si no ve ejecutar en el menú de inicio, presione WINKEY + R.

enter image description here

  • Consulte la ” sección de la aplicación ” del registro de eventos y encontrará advertencias del origen del evento “MsiInstaller” con los ID 1001 y 1004.
  • En la captura de pantalla de muestra que se muestra arriba, el código del producto se muestra dentro del cuadro rojo
  • Para determinar para qué producto es el código del producto, puede buscar el nombre del producto mediante el procedimiento que se explica aquí: ¿Cómo puedo encontrar el GUID del producto de una instalación de MSI instalada?
  • Si realmente desea profundizar y verificar el contenido real del archivo MSI, debe obtener una herramienta capaz de ver un archivo MSI ( como Orca, Installshield, Advanced Installer o similar ). A continuación, abra el paquete enumerado en la lista de ruta “LocalPackage” como se ilustra en la captura de pantalla que se encuentra en la respuesta vinculada en el punto anterior.
  • La modificación real del archivo MSI en caché del sistema y / o el registro para eliminar los puntos de entrada publicitados, como los accesos directos (publicitados), el registro COM, las asociaciones de archivos, las asociaciones MIME o los verbos de comando es un trabajo de especialistas. Es muy complicado y no es una buena práctica, pero es el único “último recurso” que conozco.
  • Finalmente, es posible que una aplicación llame explícitamente al instalador de Windows para activar la reparación automática de los componentes compartidos, por ejemplo, un corrector ortográfico. Creo que algunas versiones de Microsoft Access hicieron esto, y este comportamiento no puede ser modificado ni solucionado, hasta donde yo sé.

El experto en MSI y MVP Stefan Krüger tiene un artículo sobre el mismo problema de auto reparación. Y él analiza de manera crucial las entradas de registro de eventos reales y lo que significan. Por favor, lea sobre el procedimiento de depuración real allí .


Algunos escenarios típicos de problemas de reparación automática:

Esta es la “explicación detallada” de varios escenarios de problemas de auto reparación ya descritos en la descripción anterior.

  1. Una ruta de clave de componente está configurada en una carpeta vacía que el instalador de Windows elimina en la reparación automática (desencadenando un ciclo infinito de eliminación y posterior reparación automática). Esto se resuelve agregando la carpeta a la tabla CreateFolder en su lugar ( equivalente a Wix ). En mi experiencia, este es el escenario más común para la auto reparación no deseada. Muy común
  2. Muchos problemas de auto reparación son causados ​​por desarrolladores que intentan depurar sus aplicaciones reemplazando archivos sobre la marcha, eliminando archivos o renombrandolos. O pueden usar scripts de registro de limpieza y / o scripts por lotes para anular el registro y registrar archivos COM, COM-Interop, archivos GAC, asociaciones de archivos u otras tareas comunes de depuración y desarrollo de desarrolladores.

    • Este intercambio en caliente puede desencadenar la autorreparación cuando se inicia la aplicación a través de un acceso directo publicitado.

    • Un consejo importante para los desarrolladores que luchan con la reparación automática durante la depuración de la aplicación es no iniciar la aplicación desde un acceso directo publicitado , sino ejecutar el EXE principal directamente desde el Explorador de Windows o desde un acceso directo creado manualmente. Esto omitirá el ” punto de entrada de reparación automática ” más común: el acceso directo publicitado . La reparación automática aún puede resultar de datos COM quebrados, asociaciones de archivos publicitadas y algunos otros casos especiales ( lea este artículo de Symantec para obtener información sobre el punto de entrada).

  3. Otras aplicaciones o, más bien, otros paquetes de MSI pueden interrumpir la instalación y causar una reparación automática al interferir con los datos del registro, generalmente la configuración COM, pero también con otras configuraciones y archivos. Estos pueden ser algunos de los casos más difíciles de resolver, ya que las aplicaciones básicamente están luchando y el último en ejecutarse actualizará el registro cada vez. Normalmente, ambos archivos MSI deben rediseñarse para que las aplicaciones operen en la misma máquina. O, como es el orden del día, toda la aplicación puede ser virtualizada (por ejemplo: paquetes virtuales Microsoft App-V ) y ejecutarse en su propio entorno limitado, que parece ser lo que cada vez se hace más en las empresas en estos días. Este escenario de error a menudo se ve con un conjunto de aplicaciones mal reempaquetadas en un entorno corporativo . Los fragmentos COM de diferentes paquetes sobrescriben la ruta del disco del servidor COM desde otro paquete, y se produce una lucha de reparación automática en cada lanzamiento de la aplicación a través de un acceso directo publicitado. El mismo nombre de archivo con diferentes versiones de archivos también se puede registrar desde diferentes ubicaciones de archivos y compartir algunas configuraciones de registro que interfieren. Por lo que recuerdo, al menos 7 variables o configuraciones en el sistema de archivos y el registro deben estar sincronizadas para que un servidor COM sea apropiadamente instanciable. Consulte la sección 7 a continuación para obtener una descripción más especializada de la interferencia COM en el contexto de las aplicaciones VB6 y VBA COM.

  4. Una ruta de clave de componente apunta a un archivo temporal que ha sido eliminado por la aplicación o será eliminado por el sistema eventualmente a través de algún tipo de mecanismo de limpieza (también puede ser una herramienta de limpieza como ccleaner). Esto es común para los archivos en la carpeta temporal en sí. Esto se resuelve al no instalar el archivo temporal o al colocar el archivo en otro lugar y hacerlo permanente. He visto este error con más frecuencia en el mundo del reempaquetado de aplicaciones corporativas, donde una limpieza defectuosa de la imagen capturada conduce a la instalación de un archivo temporal que no debería haber sido incluido en el paquete. A menudo pueden ser archivos temporales que esperan que se instale un reinicio en su ubicación deseada, tal vez protegida, y el reinicio nunca se realizó, un error común de empaquetado de la aplicación. En menor grado, lo he visto en paquetes autogenerados que salen de sistemas de comstackción automatizados.

  5. Problemas de permiso : si un archivo de clave para un componente está instalado en una ubicación que no es accesible para el usuario que invoca la aplicación. Es posible que Windows Installer no “vea” la ruta del archivo / clave instalada o que no pueda agregar el archivo a la carpeta. Estos problemas pueden ser más exóticos de depurar , y pueden no ocurrir tan a menudo. Hay varias variaciones sobre este tema:

    • Un ejemplo de esto es cuando instala un archivo en una ruta% USERPROFILE% y olvida establecer una ruta clave de registro HKCU, y en su lugar establece la ruta clave para que apunte a la carpeta / archivo% USERPROFILE%. En general, esto produce una ruta de clave codificada rígida e inaccesible que es específica del usuario: C: \ Documents and settings \ user1 \ Desktop . Esta ruta no se encontrará para que otro usuario inicie sesión y la reparación automática se ejecutará en círculos. Aquí hay una ilustración en color .
    • Otro ejemplo son las rutas clave configuradas en carpetas que no se pueden escribir en la cuenta del sistema. Esto puede parecer exótico, pero puede ser el resultado de la modificación defectuosa del MSI de las entradas de ACL del sistema, o de una extraña configuración de seguridad del administrador del sistema, o de cualquier otro descriptor de seguridad / ACL no estándar.
  6. Surge otra clase de problemas de reparación automática en relación con los servidores de terminales y Citrix . El servicio de instalación de Windows completo podría estar bloqueado, por lo que cualquier reparación automática invocada para agregar datos por usuario podría fallar y, en consecuencia, la reparación automática podría fallar o, más probablemente, no ejecutarse. Esta es una razón suficiente para no confiar en la reparación automática como una forma de agregar datos de usuario como lo hacen algunos archivos MSI, y dichos constructos deben reemplazarse con la implementación de aplicaciones de archivos de usuario copiados de ubicaciones por máquina o la función ActiveSetup menos efectiva de Microsoft. que se ejecuta una vez por usuario.

  7. Se sabe que las aplicaciones VB6 y VBA , que están fuertemente basadas en COM con un enorme potencial de interferencia COM (configuraciones COM que se sobrescriben y se vuelven inconsistentes), desencadenan varios misteriosos problemas de reparación automática, la mayoría de los cuales no se han explicado correctamente. Esto también puede ocurrir en el lanzamiento de Visual Basic 6 (VB6) o Visual Studio (y muchas otras aplicaciones). El denominador común es que algún error en el estado de instalación actual desencadenó la reparación automática, y puede rastrear el producto culpable y el componente siguiendo los pasos descritos en la sección anterior llamada ” Encontrar el desencadenante o culpable de la auto reparación ” . Asegúrese de informar sus hallazgos aquí (ya nunca uso VB6 o VBA, sus hallazgos detallados podrían ayudar a otros con una molestia de larga data).

    • Aunque nunca he depurado estos problemas de VB6 con gran detalle, parecería que los problemas son el resultado de aplicaciones que instalan controles comunes , archivos VB6 COM , plantillas y archivos VBA y bibliotecas que entran en conflicto con los archivos existentes y las configuraciones de registro y registros en la caja. o puede que sea necesario agregar una clave de registro por usuario o un archivo de perfil de usuario una vez por usuario (permita que la auto reparación se complete una vez y vea si el problema desaparece). En particular, he oído hablar de estos misteriosos problemas de reparación automática al lanzar AutoCAD (de Autodesk), Visual Basic 6 y muchos otros productos (a menudo con la automatización de VBA disponible en la herramienta).
    • Algunas aplicaciones incluso erróneamente instalan bits y piezas del tiempo de ejecución de VB6 por sí solos, causando que estas configuraciones sean “arrancadas” en la desinstalación de esas aplicaciones. Esto ciertamente puede provocar que se active la auto reparación para reparar el tiempo de ejecución de VB6 ahora (¿parcialmente?) Roto. Hay varias variantes de este problema, y ​​la solución “catch all” es probablemente una desinstalación y reinstalación completas del tiempo de ejecución de VB6. Aquí hay una descripción de un problema “específico” muy común que involucra algunas claves de registro COM . Ilustra muy bien lo que sucede en este escenario.
    • Si experimenta autoreparación inesperada al iniciar VB6 , AutoCAD , Visual Studio u otros productos, primero puede intentar una solución alternativa para evitar que estas auto reparaciones inesperadas ocurran en primer lugar (esto no resuelve el problema, pero puede omitir sus síntomas): ¿por qué el instalador de Windows se inicia cada vez que inicio visual basic 6
    • Vea mi comentario a la pregunta en este tema para una de las reparaciones de estilo VB6 más típicas: ¿Por qué mi aplicación desencadena el instalador de otra aplicación? (Control ActiveX registrado dos veces desde dos ubicaciones diferentes en el disco).
    • En mi opinión, la ” solución general ” (que siempre debería funcionar) para los problemas de reparación automática de VB-COM es hacer que el proveedor actualice su proyecto en cuestión para usar el último control ActiveX oficial y correctamente instalado y compartido disponible, y no confiar en su propia versión instalada de forma redundante y registrada en la ubicación incorrecta.
  8. Un caso especial de reparación o reparación automática de Windows Installer que vale la pena mencionar para completarlo, fue el problema con Microsoft Office hace varios años en el que se activaría una reparación automática , y se le solicitaría que inserte los medios de instalación de Microsoft Office (en esos días CD-ROMs o DVDs – hoy quizás unidades USB). Por lo que recuerdo, esto estaba relacionado con una llamada errónea a la acción estándar incorporada de Windows Installer ” ResolveSource ” que inesperadamente (e innecesariamente) activó la solicitud de los medios de instalación. Un llamado de soporte muy común en el día y mencionado aquí para completar. Es importante tener en cuenta que este problema aún puede ocurrir cada vez que se instala MS Office desde cualquier medio extraíble (en lugar de la mejor opción de un recurso compartido de red ). Esto sucede cuando MS Office detecta que necesita instalar componentes adicionales, opcionales (y generalmente compartidos) del producto que no se instalaron originalmente. Por ejemplo, correctores ortográficos inusuales, varias plantillas o herramientas específicas y poco utilizadas. Es posible instalar estos componentes para “instalar al primer uso” (las características anunciadas son el término apropiado de Windows Installer).

  9. Hay muchos otros escenarios posibles. Por mencionar algunos:

    • una secuencia de comandos de inicio de sesión incorrecta puede eliminar cosas en el sistema y desencadenar la auto reparación
    • un paquete publicitado AD puede fallar al instalar y seguir molestando a las personas
    • dos aplicaciones pueden comenzar a luchar por las mismas asociaciones de archivos
    • los manipuladores de computadoras y los piratas informáticos pueden eliminar manualmente los datos que desencadenan la auto reparación
    • el antivirus puede poner en cuarentena los archivos y las configuraciones de registro que provocan la reparación
    • un virus puede cambiar o eliminar cosas y desencadenar la auto reparación
    • una herramienta de limpieza de disco y registro como ccleaner puede eliminar archivos y desencadenar la reparación automática
    • y sin duda muchos otros escenarios …

Usos benignos para la auto reparación

Finalmente, hay usos benignos para la auto reparación que ocurren una vez y no constituyen errores. Este es el uso legal y adecuado de la reparación automática, aunque puede ser tan molesto como los errores de diseño, y con la intervención del usuario pueden aparecer una y otra vez:

  • La auto reparación se usa a veces para agregar datos por usuario a HKCU y al perfil del usuario . Este diseño funciona principalmente, pero empeora para cada versión de Windows a medida que se implementan nuevos obstáculos para su implementación. Por un lado, la auto reparación generalmente no funciona en absoluto en los servidores de terminales, lo que hace que la configuración sea incompleta. Aunque es además del punto de esta discusión, es mejor que la aplicación copie los archivos en las ubicaciones por usuario. Otro problema es UAC. Otros problemas aparecen con cada nueva versión de Windows e incluso con algunas actualizaciones de Windows como se describió anteriormente (redireccionamientos de carpetas virtuales, solicitudes de certificados, restricciones de rutas de destino previamente inexistentes, etc …).
  • Cuando se necesita una reparación automática para configurar los datos del usuario , puede tomar tanto tiempo que el usuario lo interrumpa y continúe haciéndolo . Esto hace que la reparación automática vuelva a aparecer todo el tiempo hasta que se termine. Una llamada de soporte común .
  • También es posible instalar un producto con ” características anunciadas ” que están diseñadas para instalarse ” a pedido ” durante el uso de la aplicación. Pocas aplicaciones usan esto, pero cuando se utiliza, puede ejecutarse un largo instalador de “estilo de reparación automática”, lo que reduce los archivos y configuraciones necesarios. Si se cancela este proceso, la instalación de la función se retrotrae y se puede volver a activar . Esta instalación puede ser lenta por varias razones :
    • Si el instalador usó archivos CAB comprimidos grandes que primero se descargan y luego se extraen localmente en un disco lento donde el antivirus comienza a escanear toda la cabina y luego cada archivo extraído la operación puede llevar mucho tiempo.
    • La operación también puede ser lenta si la conexión de red es inalámbrica y hay muchos archivos pequeños para descargar ( alta latencia ), y nuevamente el antivirus podría ralentizar las cosas.
    • Si se instala desde un medio extraíble, podría recibir instrucciones para insertar el medio de origen para permitir que se copien los archivos. Una llamada de soporte muy común si se utilizan medios extraíbles en un entorno de oficina (no debería ser así: use una instalación de administrador en un recurso compartido de red )
    • Etc …