В течение нескольких лет мы страдали от периодических сообщений от клиентов о неописанном сообщении об ошибке «Невозможно установить распределение», которое появляется при запуске нашего приложения. До сих пор нам никогда не удавалось воспроизвести проблему в наших собственных тестовых средах. Теперь у меня закончились идеи, чтобы попытаться отследить это. Вот коллекция наблюдений, которые накопились с течением времени:
- Текст сообщения об ошибке гласит «Невозможно установить выделения» (обратите внимание на отсутствие пунктуации).
- Заголовок окна просто читается как «Ошибка» (или локализованный эквивалент).
- Текст «Невозможно установить выделения» всегда на английском языке независимо от локали ОС.
До сих пор я не смог найти DLL или EXE-файл, содержащий текст сообщения.
Google переполнен сообщениями об этой ошибке для множества различных продуктов - но без решений.
Единственный объединяющий аспект между затронутыми продуктами, которые я мог разглядеть до сих пор, заключался в том, что все они выглядят в виде библиотек DLL, которые загружаются в сторонние процессы (такие как надстройки для Visual Studio или оболочки Windows Explorer расширения).
Наше приложение на самом деле является условно-бесплатным надстройкой COM для MS Outlook, написанным на Delphi (т.е. нативный код - нет .NET).
Главным подозреваемым в нашем случае является сторонний лицензионный упаковщик, который мы используем, который расшифровывает и распаковывает нашу DLL в память на лету. Очевидно, что я не мог просто предоставить незащищенную версию нашего приложения пострадавшим клиентам, чтобы проверить это подозрение. Возможно, другие поставщики, против которых сообщалось об этом, используют аналогичные продукты.
Отладочные версии оболочки защиты, предоставленные нам поставщиком лицензий, не дали результатов: файлы журналов выглядели точно так же, как в сеансах, в которых ошибка не возникала. Очевидно, что «внутренняя» DLL все-таки дешифруется и распаковывается, но по какой-то причине все еще не может быть загружена хост-процессом.
Создавая незащищенную DLL-библиотеку-загрузчик, мы смогли точно определить возникновение ошибки где-то за LoadLibrary вызовом, который должен загружать нашу DLL в память.
Обширная регистрация и глобальные перехваты исключений в нашем собственном коде (как незащищенный загрузчик, так и защищенный "core" -DLL) вообще не дали никаких результатов. Ошибка явно возникает где-то еще.
Проблема, описанная в этом моем предыдущем вопросе , была, вероятно, вызвана той же проблемой. Это было до того, как мы создали незащищенную заглушку загрузчика.
Ошибка возникает только у 1-2% наших клиентов - тогда как обычно все установки на любом из затронутых сайтов клиента затрагиваются одинаково.
- Иногда ошибка исчезает после выпуска новой версии, но часто она возвращается снова через пару недель или месяцев.
- Как только ошибка начинает возникать на машине, это происходит последовательно.
Ошибка никогда не возникает при подключении к уязвимому компьютеру через удаленный доступ (например, VNC, RDP, TeamViewer и т. Д.), И ни один из затронутых клиентов не находится в пределах досягаемости от нас, поэтому все, что нам нужно пройти, это файлы журналов и «отчеты свидетелей».
Один клиент сообщил, что диалоговое окно сообщения об ошибке, по-видимому, было немодальным, то есть он мог просто переместить диалоговое окно в сторону и продолжить работу с приложением (за исключением функциональности, которую обеспечивала бы наша DLL) , Не уверен, что это универсально верно и во всех других случаях.
В некоторых случаях клиенты могли навсегда избавиться от ошибки, отключив или удалив другие надстройки от других поставщиков, которые делили хост-приложение с нашим собственным продуктом.
Ошибка до сих пор наблюдалась в Windows XP, Vista и 7.
В течение последних нескольких недель мы получили множество отчетов от пользователей Outlook 2003 / Windows 7. Может ли ситуация ухудшиться в результате недавнего обновления Windows / Office?