Come posso determinare quali sono le cause ripetute dell’autoriparazione di Windows Installer?

  • Come posso registrare solo le modifiche che causano la reinstallazione di un file MSI da parte di Installshield 2008 tramite ” autoriparazione “?
  • Qual è la ragione dietro l’auto-riparazione?
  • Come disabilitare l’auto riparazione di MSI usando Installshield 2008?

Risposta alternativa disponibile

AGGIORNAMENTO : C’è una risposta più breve, più “focalizzata sulla soluzione” , forse provacanvas prima. Questa risposta si concentra sulla “comprensione dell’auto-riparazione” piuttosto che sulla spiegazione dei passi da compiere per eliminare il problema. Potresti voler leggere anche la prima sezione di questa risposta.


Problemi di riparazione automatica di Windows Installer imprevisti – Correzione rapida?

Questo “articolo” è diventato grande e in qualche modo illeggibile. Ecco un preambolo appena scritto – la breve ” soluzione alternativa ” per la correzione di auto-riparazione inaspettata (spesso trovata in VB6, Visual Studio, MS Office, MS Outlook, AutoCAD, ecc …)

  • Se si verifica un inaspettato ripristino automatico , la prima cosa che si può provare è creare manualmente un collegamento sul desktop direttamente all’eseguibile dell’applicazione che si sta avviando quando si verifica il problema. Ciò aggira il trigger più comune di autoriparazione, ” la scorciatoia pubblicizzata “. Se funziona, il tuo problema è “risolto” (o evitato). Ecco una spiegazione rapida e dettagliata
  • Se il problema si verifica ancora o il tuo problema è correlato al caricamento di un MS Office , del componente aggiuntivo MS Outlook o simile (che non puoi avviare tramite una scorciatoia), probabilmente hai un conflitto di registrazione COM sul tuo sistema e la correzione è molto più coinvolta. Il modo più semplice per provare è disabilitare tutti i componenti aggiuntivi non necessari nella finestra di dialogo delle applicazioni dell’applicazione in questione e vedere se questo fa sì che il problema vada via
  • Se si riscontrano ancora problemi, è necessario eseguire il debug di un conflitto di registrazione COM originale (o di associazioni di file / MIME in conflitto o verbi di comando). Questo normalmente comporta (almeno) due applicazioni in conflitto sul tuo sistema che “combatteranno” aggiornando il registro ad ogni avvio dopo l’esecuzione dell’altra applicazione (il lancio di una delle app non provocherà automaticamente l’auto-riparazione – il conflitto emerge quando si alternano tra le applicazioni). È anche ansible che problemi di authorization facciano fallire la stessa applicazione di aggiornare il sistema e continua a provare all’infinito eseguendo ripetutamente l’auto-riparazione. E ci sono ulteriori possibilità, maggiori dettagli di seguito
    • La ” vera soluzione ” consiste nel contattare entrambi i fornitori di applicazioni e chiedere loro una soluzione per il problema (poiché una correzione spesso richiede una correzione di entrambi gli MSI del fornitore), ma nella mia esperienza questo è raramente successo. Provalo però – dal momento che questo è il modo per aiutare tutti con un fastidio di lunga data! Ho personalmente fornito un setup con le correzioni per l’implementazione di una banca e sono stato molto felice di aver risolto il problema nel mio pacchetto
    • Per eseguire il debug di te stesso, devi procurarti uno strumento per aprire i file MSI memorizzati nella cache sul sistema e devi “hackerare” il database – un’attività molto complessa che richiede competenze di esperti , ti consigliamo di cercare un esperto di installazione per aiuto se il problema è molto serio per il tuo ambiente desktop. Può funzionare, ma non aspettarti miracoli.
    • Per ulteriori dettagli su come ottenere uno strumento per visualizzare e modificare i file MSI, vedere la sezione seguente ” Ricerca del trigger o del colpevole per l’autoriparazione “.

Il resto dell ‘”articolo” descrive in modo approfondito i problemi di autoriparazione. Esistono molte altre potenziali cause di autoriparazione rispetto a quanto descritto in questa sezione “breve”.


Problema generale: debug dello sviluppatore e riparazione automatica

Windows Installer è una tecnologia di distribuzione , il suo compito è quello di installare i file specificati e le impostazioni del Registro di sistema e tenerli nelle posizioni di installazione specificate e garantire che siano le versioni corrette: la riparazione automatica o la resilienza è un meccanismo a tal fine. La sua operazione è in conflitto con gli sviluppatori che devono scambiare file al volo per il debug, lo sviluppo e il test.

Di conseguenza, molte riparazioni automatiche (resilienza) vengono triggerste semplicemente dagli sviluppatori che tentano di eseguire il debug delle applicazioni installate e dei file hot swapping al volo. Vedere la sezione 2 in ” Alcuni tipici scenari dei problemi di autoriparazione ” di seguito per come gestirlo. In altri casi ci sono errori di progettazione reali nel MSI che devono essere corretti o problemi di amministrazione del sistema che portano all’autoriparazione – e talvolta la fonte dell’errore può essere difficile da trovare.

Ho scritto sul problema dell’autodiagnosi in una risposta su serverfault.com . Parole leggermente diverse destinate agli amministratori di sistema , e leggendole ora potrebbe essere una spiegazione più accessibile di questa lunga (pensata per gli sviluppatori). C’è anche un’altra risposta più breve qui su StackOverflow: Perché riconfigura il programma di installazione MSI se cancello un file? (questo è probabilmente il più breve e più facile da capire). E infine ho trovato un articolo molto carino sull’autoriparazione di Vadim Rapp : come correggere gli sforzi di Windows Installer per l’autoriparazione. Questo articolo merita una lettura.

Non si verificherà alcuna riparazione automatica se Windows Installer determina che il prodotto avviato viene installato correttamente. Quando si esegue la riparazione automatica, è necessario modificare qualcosa sul sistema affinché l’applicazione funzioni correttamente.


Le cause primarie dell’autoriparazione

I dettagli sono presentati di seguito nella sezione ” Alcuni tipici scenari dei problemi di autoriparazione “, ma come un elenco di prefigurazioni rapide – le cause principali sono:

1. File MSI aziendali mal confezionati o difetti di progettazione MSI dal fornitore (il pacchetto MSI stesso è mal progettato e genera in modo imprevisto l’autoriproduzione per vari motivi)

  • Uso eccessivo o errato di file per utente o chiavi di registro per utente spesso con percorsi di chiavi errati impostati nel profilo utente (anziché HKCU). Vedere la sezione 5 di seguito per maggiori dettagli (e un’illustrazione a colors di tale situazione)
  • Interferenza del pacchetto da registrazione server COM errata (in particolare file COM VB6 o file VBA e librerie da prodotti come AutoCAD di Autodesk e prodotti simili).
    • Due pacchetti MSI registrano lo stesso file COM (ActiveX / OCX) da due posizioni diverse e “lotta di autoriparazione” su ogni avvio dell’applicazione per mantenere la loro versione registrata correttamente.
    • L’ultima applicazione da lanciare mette il registro di per sé, e dura fino a quando l’altra applicazione non viene lanciata e fa lo stesso. Una volta che si alternano tra le applicazioni, si verifica il problema. Vedere la sezione 7 per ulteriori dettagli sulla riparazione automatica VB / COM
  • Un percorso chiave componente è impostato su una cartella vuota che il programma di installazione di Windows rimuove durante l’auto-riparazione (innescando un ciclo infinito di rimozione e successiva riparazione automatica)
  • Problemi di authorization del blocco ACL (l’utente che ha effettuato l’accesso non può accedere al file di chiavi e i trigger di Windows Installer vengono riparati ripetutamente). Ciò può anche essere causato da modifiche ACL eseguite esternamente, ma spesso viene eseguita dallo stesso MSI
  • Qui è un serverfault.com work-in-progress che descrive difetti di progettazione comuni di MSI

2. I file o le chiavi del Registro di sistema vengono eliminati dall’interferenza causata da cause esterne che vanno dagli script (di accesso) alle funzioni del sistema operativo standard, virus, software di sicurezza, ecc …

  • I file temporanei vengono cancellati automaticamente da Windows dopo essere stati erroneamente installati nella cartella temporanea da un pacchetto MSI
  • Interferenze da accesso errato e triggerszione di script di pulizia e pulizia intuitivi
  • Applicazioni antivirus che bloccano o eliminano file o chiavi di registro in modo che Windows Installer non possa più rilevarli o accedervi
  • Virus informatici che cambiano o eliminano file e impostazioni del registro
  • Gli utenti e gli utenti di computer inattivo eliminano i file e le impostazioni che non capiscono

3. Cambiamenti nella progettazione di Windows, difetti o restrizioni che causano un’implementazione difettosa o problematica

  • Un pacchetto MSI pubblicizzato da AD non riesce a essere installato (potrebbe essere annullato poiché richiede troppo tempo per l’installazione) e continua a infastidire le persone. Questo in senso stretto non è auto-riparazione, ma un’installazione pubblicizzata che viene interrotta, ma il risultato è lo stesso: una reinstallazione senza fine
  • Complicazioni del server terminal . L’auto-riparazione è generalmente disabilitata del tutto sui server terminal. Questo normalmente non causa problemi di autoriparazione, ma installazioni di applicazioni senza i file per utente richiesti o le chiavi di registro che possono essere aggiunte tramite un uso benigno dell’auto-riparazione (leggi sotto). I file utente e le chiavi del registro utente sono semplicemente mancanti e ne risultano dei problemi
  • Interferenza UAC , errore di convalida del certificato e altri problemi derivanti dalle modifiche al design di Windows . Per ogni versione di Windows vengono aggiunte funzionalità di sicurezza come queste e in genere si aggiungono nuovi ostacoli per una distribuzione affidabile
  • Anche alcuni aggiornamenti di Windows (aggiornamenti, aggiornamenti di sicurezza, hotfix, ecc …) possono apportare drastiche modifiche al modo in cui viene applicata la sicurezza per i pacchetti MSI, e quindi causare un comportamento estremamente problematico
    • Anche se questo si riferisce alla creazione di MSI, e non principalmente al loro uso dell’utente finale, il KB3004394 di Windows Update che aggiorna il modo in cui Windows verifica i certificati di root revocati , interrompe la versione precedente della build della riga di comando di Installshield (per le configurazioni che erano firmate digitalmente). È ormai un problema risolto, ma un’illustrazione di come Microsoft continua a modificare le funzionalità principali di MSI
    • Analogamente, Installshield si è arrestato in modo anomalo per molti utenti dopo l’installazione dell’aggiornamento Microsoft MS14-037 “Aggiornamento della sicurezza per le versioni di Internet Explorer 6, 7, 8, 9, 10 e 11” (KB2962872)
    • Una modifica estremamente problematica della funzionalità di base di Windows Installer si è verificata dopo l’installazione di kb2918614 (Vista). All’improvviso sono state richieste credenziali di amministratore per una semplice operazione di riparazione MSI . Ciò ha vanificato un vantaggio fondamentale di MSI: la capacità degli utenti regolari di eseguire installazioni approvate con diritti di amministratore temporanei . C’erano anche altri problemi MSI segnalati dopo l’installazione di quella correzione. Sembra che un altro aggiornamento di Windows abbia risolto i problemi: kb3008627 (in seguito sostituito da kb3072630)

Informazioni sull’autoriparazione

Windows Installer è progettato per installare i file binari, le impostazioni e i file di dati dell’applicazione e mantenerli installati, assicurandosi che siano le versioni corrette. L’auto-riparazione è un meccanismo a tal fine. Il concetto generale è chiamato resilienza , ovvero un’installazione interrotta triggers un’autoprotezione prima dell’avvio dell’applicazione.

La resilienza o la riparazione automatica è un concetto principale incorporato di Windows Installer e non può essere distriggersto in alcun modo sicuro. Le persone fanno le cose più incredibili a volte, come disabilitare l’intero motore di Windows Installer per fermare la loro auto-riparazione. Questo ovviamente non deve mai essere fatto. La causa della riparazione deve essere identificata e il problema risolto piuttosto che crearne di nuovi o hackerare il sistema.

Ogni volta che lanci un collegamento pubblicizzato (essenzialmente un collegamento speciale che punta a una funzione di Windows Installer e non direttamente a un file), Windows Installer verificherà l’installazione controllando i ” percorsi chiave dei componenti ” per il tuo prodotto. Se viene rilevata una discrepanza, viene avviata una riparazione per correggere l’installazione incompleta. I “percorsi chiave dei componenti” sono i “file chiave” specificati per i componenti all’interno dell’MSI: ce n’è uno per componente. L’autoriparazione può essere avviata anche da qualcuno che crea un’istanza di un server COM (o che tenta di farlo), qualcuno che triggers un file tramite la sua estensione di file o la registrazione MIME e alcuni altri modi. Ecco un articolo completo di Symantec in tema di “punti di ingresso per la riparazione automatica”: avvio delle funzionalità di autoriparazione e pubblicità con punto di ingresso .

Se i file vengono cancellati, spostati o semplicemente sovrascritti (manualmente da un utente o in qualche modo automaticamente), può verificarsi il ripristino automatico (se l’impostazione del file o del registro non è impostata come percorso automatico, l’autoriparazione non viene triggersta).


Trovare il trigger o il colpevole per l’auto-riparazione

Il trigger per l’auto-riparazione è generalmente ansible trovare nel tuo event viewer sul sistema in cui è avvenuta l’auto-riparazione. Segui questi passaggi per aprire il visualizzatore di eventi :

  • Fare clic destro “Risorse del computer”
  • Fai clic su Gestisci
  • Fai clic su Continua se ricevi un prompt UAC
  • Vai alla sezione Visualizzatore eventi e controlla i registri di Windows

In alternativa puoi fare: Start => Esegui … => eventvwr.exe solo per il visualizzatore di eventi. Se non vedi eseguito nel menu Start, premi WINKEY + R.

inserisci la descrizione dell'immagine qui

  • Cerca nella sezione ” Applicazione ” del registro eventi e dovresti trovare gli avvisi dall’origine evento “MsiInstaller” con ID 1001 e 1004
  • Nella schermata di esempio sopra il codice prodotto è mostrato all’interno del riquadro rosso
  • Per determinare a quale prodotto è destinato il codice prodotto, è ansible cercare il nome del prodotto tramite la procedura spiegata qui: Come posso trovare il GUID del prodotto di una configurazione MSI installata?
  • Se in realtà si desidera approfondire e controllare il contenuto effettivo del file MSI, è necessario procurarsi uno strumento in grado di visualizzare un file MSI ( come Orca, Installshield, Advanced Installer o simile ). Quindi apri il pacchetto elencato nell’elenco dei percorsi “LocalPackage” come illustrato nella schermata trovata nella risposta collegata al punto elenco precedente.
  • La modifica effettiva del file MSI memorizzato nella cache di sistema e / o del registro per rimuovere i punti di ingresso annunciati quali scorciatoie (pubblicizzate), registrazione COM, associazioni di file, associazioni MIME o verbi di comando è un lavoro specializzato. È molto coinvolto e non è una buona pratica, ma è l’unica “ultima risorsa” che conosco.
  • Infine, è ansible che un’applicazione invochi esplicitamente Windows Installer per triggersre l’auto-riparazione dei componenti condivisi, ad esempio un correttore ortografico. Credo che alcune versioni di Microsoft Access lo abbiano fatto e questo comportamento non può essere modificato o aggirato per quanto ne so.

L’esperto di MSI e MVP Stefan Krüger ha un articolo sullo stesso problema di autoriparazione. E discute in modo cruciale le voci del registro eventi effettive e il loro significato. Si prega di leggere sulla procedura di debug attuale lì .


Alcuni scenari tipici di problemi di autoriparazione:

Questa è la “spiegazione dettagliata” di diversi scenari di problemi di autoriparazione già delineati nella panoramica sopra.

  1. Un percorso chiave componente è impostato su una cartella vuota che il programma di installazione di Windows rimuove in fase di autoriparazione (triggersndo un ciclo infinito di rimozione e successiva auto-riparazione). Questo è risolto aggiungendo la cartella alla tabella CreateFolder ( equivalente Wix ). Nella mia esperienza questo è lo scenario più comune per l’auto-riparazione indesiderata. Molto comune
  2. Molti problemi di autoriparazione sono in realtà causati dagli sviluppatori che tentano di eseguire il debug delle loro applicazioni sostituendo al volo i file, eliminando i file o rinominandoli. Oppure possono utilizzare gli script di pulizia del registro e / o gli script batch per annullare la registrazione e registrare i file COM, COM-Interop, file GAC, associazioni di file o altri comuni compiti di debug e sviluppo degli sviluppatori.

    • Questo hot-swap può triggersre l’auto-riparazione quando l’applicazione viene avviata tramite un collegamento pubblicizzato.

    • Un consiglio importante per gli sviluppatori che hanno difficoltà con l’autoriparazione durante il debug dell’applicazione è di non avviare l’applicazione da un collegamento annunciato , ma di avviare l’EXE principale direttamente da Windows Explorer o da un collegamento creato manualmente. Questo eviterà il più comune ” punto di ingresso per la riparazione automatica ” – la scorciatoia pubblicizzata . L’autoriparazione può ancora risultare da dati COM danneggiati, associazioni di file pubblicizzate e alcuni altri casi speciali ( leggere questo articolo di Symantec per informazioni sul punto di ingresso).

  3. Altre applicazioni o altri pacchetti MSI possono interrompere l’installazione e causare l’autoriparazione interferendo con i dati del registro, in genere le impostazioni COM, ma anche con altre impostazioni e file. Questi possono essere alcuni dei casi più difficili da risolvere, dal momento che le applicazioni stanno fondamentalmente combattendo e l’ultimo ad essere eseguito aggiorna il registro ogni volta. In genere, entrambi i file MSI devono essere riprogettati affinché le applicazioni possano operare sulla stessa macchina. Oppure, come è l’ordine del giorno, l’intera applicazione può essere virtualizzata (ad esempio: pacchetti virtuali Microsoft App-V ) ed eseguire nella propria sandbox che sembra essere ciò che viene fatto sempre più spesso nelle aziende. Questo scenario di errore è spesso visto con una suite di applicazioni mal confezionate in un ambiente aziendale . I frammenti COM di diversi pacchetti sovrascrivono il percorso del disco del server COM da un altro pacchetto e si verificano conflitti di autoriparazione per ogni avvio dell’applicazione tramite una scorciatoia pubblicizzata. Lo stesso nome di file con diverse versioni di file può anche essere registrato da diversi percorsi di file e condividere alcune impostazioni di registro che interferiscono. Per quanto ricordo, almeno 7 variabili o impostazioni nel file system e nel registro devono essere sincronizzati affinché un server COM sia correttamente istanziabile. Vedere la sezione 7 di seguito per una descrizione più specialistica dell’interferenza COM nel contesto delle applicazioni VB6 e VBA COM.

  4. Un percorso chiave componente punta a un file temporaneo che è stato eliminato dall’applicazione o che verrà eliminato dal sistema tramite una sorta di meccanismo di pulizia (può anche essere uno strumento di pulizia come ccleaner). Questo è comune per i file nella stessa cartella temporanea. Questo problema viene risolto non installando il file temporaneo o mettendo il file da qualche altra parte e rendendolo permanente. Ho visto questo errore più spesso nel mondo del riconfezionamento delle applicazioni aziendali in cui una ripulitura errata dell’immagine catturata porta all’installazione di un file temporaneo che non dovrebbe essere stato incluso nel pacchetto. Spesso possono essere file temporanei in attesa di un riavvio da installare nella posizione prevista, forse protetta, e il riavvio non è mai stato eseguito – un errore di impacchettamento dell’applicazione comune. In misura minore l’ho visto in pacchetti generati automaticamente provenienti da sistemi di compilazione automatizzati.

  5. Problemi di authorization : se un file chiave per un componente viene installato in una posizione non accessibile per l’utente che richiama l’applicazione. Windows Installer potrebbe non “vedere” il percorso file / chiave installato o non essere in grado di aggiungere il file alla cartella. Questi problemi possono essere più esotici per il debug e potrebbero non accadere così spesso. Esistono diverse varianti su questo problema:

    • Un esempio di ciò è quando si installa un file in un percorso% USERPROFILE% e poi si dimentica di impostare un keypath di registro HKCU e invece di impostare il keypath in modo che faccia riferimento alla cartella% / file% USERPROFILE. Questo generalmente genera un inaccessibile tracciato della chiave hard cod che è specifico per l’utente: C: \ Documents and settings \ user1 \ Desktop . Questo percorso non verrà trovato per l’accesso di un altro utente e l’esecuzione di auto-riparazione nelle cerchie. Ecco un’illustrazione a colors .
    • Un altro esempio sono i percorsi chiave impostati su cartelle che non sono scrivibili per l’account di sistema. Questo può sembrare esotico ma può derivare dalla modifica errata delle voci ACL del sistema da parte di MSI o da una strana configurazione di sicurezza dell’amministratore di sistema o da qualsiasi altro ACL / Descrittore di sicurezza non standard.
  6. Un’altra class di problemi di autoriparazione emerge in relazione ai terminal server e Citrix . L’intero servizio di installazione di Windows potrebbe essere bloccato in modo tale che qualsiasi auto-riparazione invocata per aggiungere dati per utente potrebbe fallire e di conseguenza l’auto-riparazione potrebbe non riuscire o più probabilmente non funzionare affatto. Questo è un motivo sufficiente per non fare affidamento sull’autoriparazione come metodo per aggiungere dati utente come fanno alcuni file MSI e tali costrutti devono essere sostituiti con la distribuzione dell’applicazione di file utente copiati da posizioni per macchina o la funzione ActiveSetup meno efficace da Microsoft che viene eseguito una volta per utente.

  7. Le applicazioni VB6 e le applicazioni VBA , che sono pesantemente basate sulla COM con un enorme potenziale di interferenza COM (le impostazioni COM si sovrascrivono e diventano incoerenti), sono note per innescare diversi misteriosi problemi di autoriparazione, la maggior parte delle quali non sono state adeguatamente spiegate. Questo può accadere anche all’avvio di Visual Basic 6 (VB6) o Visual Studio (e molte altre applicazioni). Il comune denominatore è che qualche errore nello stato di installazione corrente ha innescato l’auto-riparazione, e puoi rintracciare il prodotto colpevole e il componente seguendo i passaggi descritti nella sezione precedente chiamata ” Trovare il trigger o il colpevole per l’auto-riparazione ” . Assicurati di riportare i risultati qui (non uso mai più VB6 o VBA – i tuoi risultati dettagliati potrebbero aiutare gli altri con un fastidio di lunga data).

    • Anche se non ho mai debugato tali problemi VB6 in modo molto dettagliato, sembrerebbe che i problemi derivino da applicazioni che installano controlli comuni , file COM VB6 , modelli e file VBA e librerie che sono in conflitto con i file esistenti e le impostazioni del registro e le registrazioni sulla scatola, o potrebbe essere necessario aggiungere una o più chiavi del registro per utente o file profilo utente una volta per utente (consentire all’autoriparazione di completarsi una sola volta e vedere se il problema scompare). In particolare, ho sentito parlare di questi misteriosi problemi di autoriparazione durante l’avvio di AutoCAD (da Autodesk), Visual Basic 6 e molti altri prodotti (spesso con l’automazione VBA disponibile nello strumento).
    • Alcune applicazioni installano erroneamente bit e frammenti dal runtime VB6 da soli causando la “rimozione” di queste impostazioni alla disinstallazione di tali applicazioni. Questo può certamente causare l’auto-riparazione da triggersre per risolvere il runtime VB6 (parzialmente?) Guasto. Esistono diverse varianti di questo problema e la soluzione “catch all” è probabilmente una disinstallazione completa e la reinstallazione del runtime VB6. Ecco una descrizione di un problema “specifico” molto comune che coinvolge alcune chiavi di registro COM . Illustra chiaramente cosa succede in questo scenario.
    • Se si verificano auto-riparazione inaspettata all’avvio di VB6 , AutoCAD , Visual Studio o altri prodotti, è ansible provare prima una soluzione alternativa per evitare che queste auto-riparazioni impreviste si verifichino in primo luogo (ciò non risolve il problema, ma potrebbe bypassare i suoi sintomi): perché si avvia Windows Installer ogni volta che avvio Visual Basic 6
    • Vedere il mio commento alla domanda in questo argomento per uno dei più tipici self-repair in stile VB6: Perché la mia applicazione triggers il programma di installazione di un’altra applicazione? (Controllo ActiveX registrato due volte da due posizioni diverse su disco).
    • A mio parere, la ” correzione generale “, che dovrebbe sempre funzionare, per i problemi di riparazione automatica di VB-COM, consiste nel far sì che il fornitore aggiorni il progetto in questione per utilizzare l’ultimo controllo ActiveX ufficiale e correttamente installato e condiviso / OCX disponibile, e non fare affidamento sulla propria versione installata in modo ridondante e registrata nella posizione sbagliata.
  8. Un caso speciale di riparazione o di riparazione automatica di Windows Installer che vale la pena menzionare per completezza, è stato il problema con Microsoft Office diversi anni fa in cui si sarebbe triggersto un auto-riparazione e si sarebbe chiesto di inserire il supporto di installazione di Microsoft Office (in quei giorni CD-ROM o DVD – oggi forse thumb drive). Per quanto ricordo, ciò era correlato a una chiamata errata all’azione standard ” ResolveSource ” incorporata in Windows Installer che inaspettatamente (e inutilmente) ha triggersto il prompt per il supporto di installazione. Un supporto molto comune richiama durante il giorno e menzionato qui per completezza. È importante notare che questo problema può ancora verificarsi ogni volta che MS Office viene installato da qualsiasi supporto rimovibile (piuttosto che l’opzione migliore di una condivisione di rete ). Ciò accade quando MS Office rileva che è necessario installare ulteriori componenti opzionali (e generalmente condivisi) del prodotto che non sono stati installati originariamente. Ad esempio insoliti correttori ortografici, vari modelli o strumenti specifici e usati raramente. È ansible installare questi componenti per “installare al primo utilizzo” (le funzionalità pubblicizzate sono il termine corretto di Windows Installer).

  9. Ci sono molti altri possibili scenari. Per citarne alcuni:

    • uno script di accesso errato può eliminare elementi nel sistema e triggersre l’autoriparazione
    • un pacchetto pubblicizzato AD potrebbe non riuscire a installare e a tenere sotto controllo le persone
    • due applicazioni potrebbero iniziare a combattere per le stesse associazioni di file
    • i produttori di computer e gli hacker possono eliminare manualmente i dati che triggersno l’autoriparazione
    • l’anti-virus può mettere in quarantena i file e le impostazioni del registro che triggersno la riparazione
    • un virus può modificare o eliminare le cose e triggersre l’auto-riparazione
    • uno strumento di pulizia del disco e del registro di sistema come ccleaner può eliminare i file e triggersre l’auto-riparazione
    • e senza dubbio numerosi altri scenari …

Usi benigni per l’autoriparazione

Infine ci sono usi benevoli per l’auto-riparazione che si verificano una volta e non costituiscono errori. Questo è l’uso legale e corretto dell’autoriparazione anche se può essere altrettanto fastidioso degli errori di progettazione, e con l’intervento dell’utente possono apparire più e più volte:

  • A volte l’auto-riparazione viene utilizzata per aggiungere dati per utente a HKCU e al profilo utente . Questo design funziona per lo più, ma peggiora per ogni versione di Windows poiché vengono introdotti nuovi ostacoli per l’implementazione. Per una cosa, la riparazione automatica in genere non funziona affatto sui server terminal, rendendo l’installazione incompleta. Anche se è oltre il punto di questa discussione, è meglio che l’applicazione copi i file in posizioni per utente. Un altro problema è UAC. Altri problemi si presentano con ogni nuova versione di Windows e anche con alcuni aggiornamenti di Windows come descritto sopra (reindirizzamenti di cartelle virtuali, richieste di certificati, restrizioni del percorso di destinazione precedentemente non esistenti, ecc …).
  • Quando è necessario eseguire l’auto-riparazione per impostare i dati dell’utente , potrebbe volerci così tanto tempo che l’ utente lo abortisca e continua a farlo . Ciò fa sì che l’auto-riparazione riappaia continuamente finché non è permesso di terminare. Una chiamata di supporto comune .
  • È anche ansible installare un prodotto con ” funzioni pubblicizzate ” progettate per essere installate ” su richiesta ” triggerste durante l’utilizzo dell’applicazione. Poche applicazioni lo usano, ma quando viene utilizzato può essere eseguito un lungo programma di “autoriparazione”, che consente di eseguire il download dei file e delle impostazioni richiesti. Se questo processo viene annullato, l’installazione della funzione viene ripristinata e può essere nuovamente triggersta . Questa installazione può essere lenta per diversi motivi :
    • Se il programma di installazione utilizzava file CAB compressi di grandi dimensioni che vengono prima scaricati e quindi estratti localmente su un disco lento in cui l’ anti virus inizia a eseguire la scansione dell’intera cabina e quindi ogni file estratto l’operazione può richiedere molto tempo.
    • L’operazione può anche essere lenta se la connessione di rete è wireless e ci sono molti piccoli file da scaricare ( alta latenza ), e di nuovo l’anti virus potrebbe rallentare le cose.
    • Se installato da un supporto rimovibile, è ansible ottenere prompt per inserire il supporto di origine per consentire la copia dei file. Una chiamata di supporto molto comune se il supporto rimovibile viene utilizzato in un ambiente di ufficio (non dovrebbe essere: utilizzare un’installazione di amministrazione su una condivisione di rete )
    • Eccetera…