数週間前から、少数のお客様でOutlookアドインがアンロードされ、まだ不明な理由で無効になっているという問題に取り組んできました。「無効」とは、Outlookが次のレジストリ値を3から2に変更することを意味します。これは、事実上、次回の起動時にアドインが読み込まれないことを意味します。
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\Addins\[OurAddin.sProgID]\LoadBehavior
エラーメッセージはなく、アドインが生成するログファイルにも例外は表示されません。
LoadBehaviorの変更の問題を具体的に扱っている次のページをすでに見つけました:http://blogs.msdn.com/vsod/archive/2008/04/22/Troubleshooting-com-add-in-load-failures.aspx
ただし、そこで提案されている考えられる理由はどれも当てはまらないようです。
- アドインは、単に無効アイテムリストにリストされているだけではありません。
IDTExtensibility2メソッドにもコードの他の場所にも、未処理の例外はありません。すべてのコードは同等のtry/catchでラップされ、すべての例外出力はログファイルを介してOutputDebugStringまたはログファイルにのみ出力されます。- このエラーは、ウイルス対策ソフトウェアとは無関係のようです。つまり、エラーが無効になっている場合にも発生します。
- 他のすべてのアドインを無効にしても、エラーには影響しません。
では、他に何が原因でOutlookがアドインを無効にする可能性がありますか?
いくつかの詳細/観察:
- これまでのところ、テスト環境で問題を再現することはできなかったため、問題が発生している間はデバッガーをアタッチできませんでした。
- リモートサポート(TeamViewer)を介して何が起こるかを監視しようとしている間は、この問題は発生しません。これは、TeamViewerが実行中のすべてのプロセス(Outlookを含む)に自身を挿入するフックDLLを使用しているため、メモリレイアウト、タイミング、スレッドの順序などに影響を与えるためだと思います。
- アドインの新しいバージョンをコンパイルして新しいことを試すときはいつでも、アドインは通常、数時間または数日間は正常に動作し、最終的には再び無効になります。これが発生すると、別のビルドをコンパイルしてデプロイする(またはTeamViewer-上記を参照)。
- 通常、アドインはOutlookの起動時にアンロードされますが、Outlookが既にしばらく実行された後にもアンロードされる場合があります。このような場合のログファイルは完全に目立たないように見えます。アドインは、Outlookが正常に閉じられたかのように、通常のシャットダウン手順を実行するだけです。
- ログファイルからわかり、SysInternals ProcessMonitorで問題を観察すると、Outlookの起動時に(セッション中ではなく)アドインが無効になると、COMオブジェクト(つまり、アドイン)がインスタンス化される前でもDLLがアンロードされます。 (コンストラクターのログメッセージは表示されません)。
OutputDebugStringメッセージをセクションに配置しましたinitialization(これはDelphi DLLです)。アドインのロードに失敗した場合、それらはいずれも表示されません。この問題の影響を受けるのは、ごく一部のお客様のみです。数万のインストールがあり、これに関するレポートはありません。
更新:アドインがアンロードされる前にログに記録される最後のことの1つは、「OLEエラー800A01A8」というテキストの例外であることがよくあります(常にではありません)。その例外は、私が使用しているフレームワーク( Add-in-Express )に組み込まれているグローバル例外ハンドラーによってキャッチされ、すべてのメソッドが完全にラップされている自分のコードのどこからも発生していないように見えます
try..catch。これは通常、インスペクターのActivateイベントハンドラーからCommandBarButtonの可視性を設定した直後に発生します。
影響を受けるすべてのマシンに共通するプロパティ:
- Windows XP Professional、最新のパッチレベル
- Outlook 2003 Professional、最新のパッチレベル
- McAfee Virus Scanのさまざまなバージョン(無効にしても効果はありません-上記を参照)
- ユーザーはローカルのAdministratorsグループのメンバーです
おそらく同様に重要であることに注意するもう1つのこと(おそらく私が最初に思ったほどではないかもしれませんが):
コンパイルされたDLLを「シェル」でラップし、オンザフライでのみ解凍するサードパーティベンダーのライセンス/コピー防止モジュールを使用しています。自分のコードが実行される前にアドインがアンロードされることを知って以来、これが私の主な容疑者でした。ただし、ベンダーはコードに未処理の例外がある可能性があることを確認しましたが、保護シェルの特別なデバッグバージョンによって生成されたログファイルは、解凍プロセスが正常に完了し、Outlookがアドインをアンロードする前に制御が保護されたDLLに既に戻されたことを示しました。したがって、Outlookがアドインをアンロードする原因は、保護シェルの初期化の完了と独自のコードの間に発生するようです。
他にアイデアはありますか?