Che cosa può causare che Outlook modifichi il LoadBehavior di un componente COM in 2, a parte le eccezioni non gestite?

Question

Per alcune settimane abbiamo combattuto con un problema in cui a un piccolo numero di clienti il ​​nostro addin di Outlook viene scaricato e disabilitato per motivi ancora indeterminati. Con il termine "disabile" Voglio dire che Outlook modifica il seguente valore del Registro di 3-2 che in effetti significa che il componente aggiuntivo non verrà caricato all'avvio successivo:

HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\Addins\[OurAddin.sProgID]\LoadBehavior

Non v'è alcun messaggio di errore e non fare qualsiasi le eccezioni appaiono nei file di log che il nostro addin produce da sé.

Ho già trovato la seguente pagina che tratta specificamente il problema del cambiamento LoadBehavior: http://blogs.msdn.com/vsod/archive/2008/04/22/Troubleshooting-com-add-in-load-failures.aspx

Tuttavia, nessuna delle ragioni possibili proposte ci sembrano essere applicabile:

• Il componente aggiuntivo non è solo elencato nell'elenco delle voci disabilitate.
• Non ci sono eccezioni non gestite né nei metodi IDTExtensibility2 né altrove nel codice. Tutto il codice è racchiuso tra gli equivalenti try/catch e tutte le eccezioni vengono emesse solo tramite OutputDebugString o in un file di registro.
• L'errore sembra essere indipendente dal software antivirus, vale a dire che si verifica anche con esso disabilitato.
• Anche la disattivazione di tutti gli altri componenti aggiuntivi non ha alcun effetto sull'errore.

Allora, che altro può causare Outlook per disattivare un componente aggiuntivo?

qualche dettaglio in più/osservazioni:

• Non sono stati in grado di riprodurre il problema nei nostri ambienti di test finora così non siamo ancora stati in grado di collegare un debugger mentre si verifica il problema.
• Il problema non si verifica mai mentre cerchiamo di vedere cosa succede tramite il supporto remoto (TeamViewer). Sospetto che questo sia dovuto al fatto che TeamViewer utilizza una DLL di aggancio che si inietta in tutti i processi in esecuzione (incluso Outlook) e quindi influenza il layout della memoria, i tempi, l'ordine dei thread e così via.
• Ogni volta che compiliamo una nuova versione dell'addin per provare qualcosa di nuovo, l'addin funzionerà normalmente per un paio d'ore o addirittura solo per essere nuovamente disabilitato. Una volta che questo è successo, tutti i successivi tentativi di caricare l'addin su quella macchina (cambiando manualmente il valore di LoadBehavior) falliranno (cioè LoadBehaviour tornerà semplicemente a 2) finché non compileremo e distribuiremo un'altra build (o proveremo a guardare usando TeamViewer - vedi sopra).
• In genere l'addin viene scaricato direttamente all'avvio di Outlook anche se occasionalmente si verifica anche dopo che Outlook è già in esecuzione da qualche tempo. Il file di registro in questi casi sembra completamente inconsapevole: l'addin passa semplicemente attraverso i normali passaggi di spegnimento proprio come se Outlook fosse stato chiuso normalmente.
• Per quanto mi riguarda posso dire dai nostri file di log e osservando la questione tramite SysInternals ProcessMonitor, quando il componente aggiuntivo ottenere disabilitato all'avvio di Outlook (piuttosto che durante la sessione) la DLL viene scaricata anche prima che l'oggetto COM (vale a dire il componente aggiuntivo) viene istanziato (i messaggi di registro nel costruttore non vengono mai visualizzati).
• abbiamo messo OutputDebugString messaggi in initialization sezioni (questa una DLL Delphi). Nessuno di questi viene visualizzato quando l'addin non viene caricato.

• Solo una piccola parte dei nostri clienti è interessata da questo problema. Abbiamo diverse decine di migliaia di installazioni dalle quali non abbiamo ricevuto alcuna segnalazione al riguardo.

• UPDATE: Sembra che spesso (ma non sempre) una delle ultime cose che viene effettuato l'accesso prima che il componente aggiuntivo viene scaricato è un'eccezione con il testo "l'errore 800A01A8 OLE". Tale eccezione viene catturata da un gestore di eccezioni globale incorporato nel framework che sto utilizzando (Add-in-Express) e non viene originato da qualsiasi parte del mio codice, ogni singolo metodo di cui è ora interamente racchiuso in try..catch. Ciò si verifica in genere subito dopo aver impostato la visibilità dei miei CommandBarButtons da un gestore di eventi Activate di Inspector.

proprietà comuni di tutti i computer interessati:

• Windows XP Professional, up-to-date livello di patch
• Outlook 2003 Professional, up-to-date livello di patch
• versioni diverse di McAfee Virus Scan (sebbene disabilitarlo non ha alcun effetto - vedi sopra)
• Gli utenti sono membri del gruppo Administrators locale

Un'altra cosa da notare che molto probabilmente è significativa (anche se forse non tanto quanto ho pensato prima):
Stiamo usando un modulo di protezione delle licenze/copia da un fornitore di terze parti che avvolge la DLL compilata in una "shell" e lo decomprime solo al volo. Da quando ho scoperto che l'addin viene scaricato anche prima che il nostro codice venga eseguito, questo è stato il mio principale sospetto. Tuttavia, mentre il venditore ha confermato che potrebbero esserci eccezioni non gestite nel proprio codice, un file di registro prodotto da una versione di debug speciale della shell di protezione ha mostrato che il processo di decompressione è stato completato correttamente e il controllo è stato già restituito alla DLL protetta prima che Outlook scaricasse l'addin . Quindi sembra che qualunque cosa induca Outlook a scaricare il nostro addin avviene tra il completamento dell'inizializzazione della shell di protezione e il nostro codice.

Altre idee?

Answer 1

solo chiudere questo in su: Il problema ha finalmente si rivelano essere causato da un bug nella confezione delle licenze di terze parti che stavamo usando. È stato confermato dal fornitore ed è stato corretto nelle versioni più recenti.

Answer 2

Sto anche lavorando al componente aggiuntivo di Outlook e conosco un motivo quando il componente aggiuntivo viene disabilitato. un po 'di tempo in cui Outlook si spegne bruscamente o l'utente chiude con forza l'Outlook, il componente aggiuntivo viene disabilitato. Non sono sicuro che questa sia la ragione nel tuo caso, ma potrebbe anche darti qualche indicazione su cui riflettere. Un po 'di tempo uso questo metodo (chiudendo l'outlook con il task manager mentre sta ancora caricando) per simulare questo comportamento e in realtà ho sviluppato uno strumento che analizza tutte le macchine a lui fornite e controlla se l'add-in è disabilitato su un macchina e se sì cambia il valore del registro per abilitarlo.

Answer 3

La mia azienda ha sopportato quello che sembra lo stesso problema che si vede da anni. Il plug-in che abbiamo è un componente aggiuntivo VB6 COM per Outlook 2003 ed è distribuito su diverse centinaia di macchine che ottengono centinaia di cicli (se non migliaia) di volte al giorno. Analizziamo molto i cicli di carico e scarico.

Otteniamo un bel po 'degli errori generali in cui il plug-in è caricato ma non connesso e lo gestiamo nel codice.(Ovviamente non la qualità della produzione)

Dim outlook As outlook.Application 
Set outlook = CreateObject("Outlook.Application") 
outlook.COMAddIns("MyFancyDancyPlugin").Connect = True 

Raramente, ma non così rara che non è un fastidio, vediamo il plug-in raggiungere uno stato in cui viene caricato e lo possiamo vedere in “Strumenti> Opzioni > Altri> Opzioni avanzate> Componenti aggiuntivi Com ", ma non possiamo connetterci alla cosa. Se provi a connetterti non ricevi un errore, torna semplicemente a disconnected. [L'equivalente di tornare a un 2 nella chiave di registro] L'oggetto COM, per quanto posso dire, non viene mai creato. L'articolo non è elencato negli elementi Disabled.

In realtà non è necessario ridistribuire per correggere questo errore. Rimuovendo l'oggetto tramite il dialogo Componenti aggiuntivi Com e quindi aggiungendolo nuovamente, sembra che il problema venga risolto. Questa soluzione non è ancora accettabile, ma ripristina e ripristina le cose senza una reinstallazione.

• Windows XP Professional, up-to-date livello di patch
• Outlook 2003 professionale, livello di patch up-to-date
• variando versioni di McAfee Virus Scan (anche se la disattivazione ha nessun effetto - vedi sopra)
• Gli utenti sono membri del gruppo Administrators locale

Questo sembra andare bene, non usiamo McAfee ma il virus scanner anche non interagisce con Outlook o componenti aggiuntivi COM. Inoltre, non utilizziamo un'app di protezione dalla copia.

Mi dispiace non posso essere di maggiore aiuto, ma mi piacerebbe causa principale questo.

Answer 4

forse sei una vittima della politica di lockback. aggiungi una chiave di bypass al registro, quindi funziona. versioni di office moderne o vsto crea la chiave durante l'installazione. l'effetto è: installa anche un ufficio moderno e ora l'adddin viene caricato anche in un vecchio ufficio. si prega di dare un'occhiata

frammento di codice tratto da NetOffice http://netoffice.codeplex.com

public static void RegisterFunction(Type type) 
{ 
      try 
      { 
       // add codebase value 
       Assembly thisAssembly = Assembly.GetAssembly(typeof(ExampleClassicAddin)); 
       RegistryKey key = Registry.ClassesRoot.CreateSubKey("CLSID\\{" + type.GUID.ToString().ToUpper() + "}\\InprocServer32\\1.0.0.0"); 
       key.SetValue("CodeBase", thisAssembly.CodeBase); 
       key.Close(); 

       key = Registry.ClassesRoot.CreateSubKey("CLSID\\{" + type.GUID.ToString().ToUpper() + "}\\InprocServer32"); 
       key.SetValue("CodeBase", thisAssembly.CodeBase); 
       key.Close(); 

       // add bypass key 
       // http://support.microsoft.com/kb/948461 
       key = Registry.ClassesRoot.CreateSubKey("Interface\\{000C0601-0000-0000-C000-000000000046}"); 
       string defaultValue = key.GetValue("") as string; 
       if (null == defaultValue) 
        key.SetValue("", "Office .NET Framework Lockback Bypass Key"); 
       key.Close(); 

       // add addin key 
       Registry.ClassesRoot.CreateSubKey(@"CLSID\{" + type.GUID.ToString().ToUpper() + @"}\Programmable"); 
       Registry.CurrentUser.CreateSubKey(_addinRegistryKey + _prodId); 
       RegistryKey rk = Registry.CurrentUser.OpenSubKey(_addinRegistryKey + _prodId, true); 
       rk.SetValue("LoadBehavior", Convert.ToInt32(3)); 
       rk.SetValue("FriendlyName", _addinName); 
       rk.SetValue("Description", "NetOffice COMAddinExample with classic UI"); 
       rk.Close(); 
      } 
      catch (Exception ex) 
      { 
       string details = string.Format("{1}{1}Details:{1}{1}{0}", ex.Message, Environment.NewLine); 
       MessageBox.Show("An error occured." + details, "Register " + _addinName, MessageBoxButtons.OK, MessageBoxIcon.Error); 
      } 
} 

Answer 5

Se avete la possibilità per gli utenti di eseguire un programma di debug per ottenere ulteriori informazioni sul problema quando accade, provare a utilizzare Add-in Spia da Microsoft.

http://msdn.microsoft.com/en-us/library/cc984533(v=office.12).aspx

stavo avendo un add-in non riescono a caricare e scoprì che stava accadendo a causa di una dipendenza non si stava precaricato. Questo strumento dovrebbe essere in grado di dirti quale errore specifico si verifica quando il componente aggiuntivo di Outlook non viene caricato.