Для начала можно единично проверит вышеописанное на рассматриваемом компьютере, к которому относятся все рассматриваемые журналы.
У меня нет прав администратора, а без них касперский не выключить. По этому приходиться взаимодействовать с другой службой.
Хорошо, ожидаем результат проверки.
Отключение касперского не помогло. Но накопали еще важный нюанс, обязательно нужно закинуть файлы (c:\Program Files\LERS\Updater) с здорового экземпляра. Вероятно утилита обновления ломает службу не обновив все файлы.
Вот что было:
Updater_broken.7z (1,9 МБ)
Я не думаю что проблема в утилите. Если бы такая ситуация имела место быть по вине Службы обновления, она возникала бы у вас на всех компьютерах, а она у вас возникает только на некоторых. Более того она возникала бы не только у вас.
Также мы собрали тестовый стенд, на который установили ЛЭРС УЧЕТ версии 3.58.3. Служба обновления успешно запустилась.
Я по прежнему считаю, что проблема связана с внешним воздействием на Службу обновления. Об этом свидетельствует отсутствие каких либо сообщений об ошибках Службы обновления в журнале приложений Windows или в журнале работы самой Службы обновления. Судя по всему процесс службы не запускается вовсе, в противном случае возникал бы результат его запуска в виде ошибки в одном из журналов.
Попробуйте у себя установить ЛЭРС УЧЕТ 3.58.3 на компьютере без Касперский и проведите процедуру обновления на нем. Сообщите результат.
Возможно конечно, что на проблемных компьютерах есть ограничение прав, приводящих к проблемам с запуском Службы обновления, так как с правами администратора Служба обновления, как вы сообщили ранее, запускается. Но нам сложно как то ориентироваться ввиду отсутствия записей в журналах. В целом у пользователя LocalSystem, под которым Служба обновления запускается по умолчанию, должны быть все необходимые права. У меня нет информации относительно возможности ограничения прав данному пользователю. Возникают опять же предположения о внешнем воздействии на Службу обновления.
По прежнему ожидаем результат процедуры обновления на обычном компьютере без Касперский. В дополнение к этому уточните, при запуске Службы обновления, на сколько я понимаю, из оснастки на проблемном компьютере ее процесс появляется в списке процессов Дипетчера задач?
На процесс не обратили внимание. Переустановка даже с включенным касперским помогает (только ставим мы актуальную версию). Вскоре будем на 3.59 переходить может еще, что появиться.
Спасибо за информацию.
Опять словил эту проблему. На ВМ поставил версию 3.59.0 и попытался обновиться на версию 3.59.1, служба не ответила. В ручную также не запустилась. Перезагрузил ВМ, служба запустилась и клиент обновился.
При этом на ВМ антивирусное ПО не установлено (кроме виндового +смартскрин, но где их логи непонятно), домена нет, учетная запись с правами администратора. Покопавшись в логах определил, что служба сразу после установки не запускалась, только после перезагрузки.
Могу дать доступ на ВМ, может Вы, что то найдете.
Нет, доступ к ВМ не нужен. Опять же нужны журналы Windows и журнал работы Службы обновления (нужен именно файл!).
Documents.zip (1,7 МБ)
По присланным журналам найти причину не удалось. У вас в журнале приложений нет ни единого события за весь предоставленный период от источника .NET Runtime, от которого приходят события падения .NET приложений, в том числе и Службы обновления. По системному журналу событий падение видно, а подробностей в журнале приложений нет, поэтому анализировать ситуацию не представляется возможным.
Уточните как именно вы устанавливали ОС на ВМ? Это какая то специальная сборка или вы используете стандартные образы “чистой” ОС? Какие настройки после разворачивания ОС производились?
Официальный “чистый” образ. Разворачивался с virtio. Это ВМ для тестирования, там ничего толком и не делалось.
Попробуйте установить этот же образ ОС в любой другой ВМ, например, VMWare, затем установите ЛЭРС УЧЕТ в установленной ОС и проверьте повторится ли ситуация.
Это проблематично, да и проблема плавающая. Может стоит посмотреть в другую сторону? Проблемы начались, когда отказались от поддержки Windows 7, и насколько я вижу в утилите обновления даже проверку добавили с сообщениями. Может и в службе, что то подкрутили и это повлияло?
В Службе ничего не “подкручивали”. Если бы проблема была именно в Службе обновления, она возникала бы не только у вас, а и у других пользователей, использующих такую же версию ОС, тоже. Даже у вас она возникает только на одной виртуальной машине.
Удалось найти два способа решения проблемы.
- Отключить сетевой интерфейс. Работает и на ВМ и на реальной машине с проблемой. Служба успешно запускается.
- Перевод IPv4 с DHCP на статическую адресацию, при этом желательно, что бы диапазон сети сменился. После этого служба запускается. Самое интересное, что если переключить назад на DHCP, служба опять же будет спокойно запускаться. Основная проблема, что это успешно работает на ВМ, но не работает на реальной машине на которой тестировали (возможно нужно на большем количестве ПК протестировать, но это проблематично).
Оба вариант проблематичны для удаленного администрирования и только нестабильный 2 вариант решал проблему полностью.
Может это поможет Вам понять, что может быть не так, потому что для меня эти решения из категории танцев с бубном.
Нам не удается воспроизвести ситуацию на своих компьютерах. Имеются тестовые компьютеры (VMWare и реальный), на которых запуск Службы обновления проходит без каких либо проблем. У других пользователей, судя по отсутствию комментариев в вашей теме с такой проблемой, она не возникает. Отсутствие информации в присланном вами журнале приложений Windows при вроде бы как падении Службы обновления также не позволяет анализировать ситуацию.
Ранее вы писали, что проблема решается, если войти в ОС под администратором. Сейчас вы приводите другие способы решения данной проблемы. Все это очень странно.
В любом случае спасибо за информацию. Если нам удастся воспроизвести ситуацию у себя, мы учтем ваши наблюдения.
Я понимаю, что Вы не можете воспроизвести проблему. Учитывая, что проблема решается довольно странными действиями, причина должна быть довольно специфична и ломает службу еще до определения версии ОС (первое сообщение логов). Может у Вас есть возможность предоставить службу обновления которая логирует каждый чих от самого старта?
Это оказалось связано с тем, что при перезагрузке служба стартует успешно. А успешно она стартует скорее всего из-за того, что сеть еще не успела запуститься.
У нас просто разные службы за разное отвечают, я только за работу ЛЭРС. Администрирование рабочих ПК это другая служба. По этому иногда получается поломанный телефон.