Архив рубрики: Windows

Внезапная перезагрузка Ryzen 5000 при слабых нагрузках. Решение.

После выхода новых процессоров Ryzen 5000 все сайты и форумы пестрили сообщениями об их непревзойденной производительности. После поступления первых партий в продажу количество восхищенных отзывов не уменьшилось, но появились первые сообщения о проблемах, с одной из которых столкнулся и я — самопроизвольная перезагрузка компьютера при простое или слабой нагрузке. При этом, все стресс-тесты проходят «на ура», тестирование отдельных компонентов также не выявляет проблем.

Я не хотел прибегать к ручному разгону, как к способу решения этой проблемы (помогает всем), но и постоянные перезагрузки с последующим появлением ошибки WHEA Logger ID 18 — Cache Hierarchy Error (или аналогичных) тоже не давали насладиться спокойной работой на мощном железе. Естественно, я обновлял BIOS, драйвера, пытался включать/отключать различные параметры в настройках BIOS, как и рекомендуют на большом количестве форумов… Не помогало ничего.

Но решить мою проблему помогла случайность. Во время очередных тестов я выставил профиль питания в Windows — Высокая производительность (High performance). Сразу внимания не обратил, но перезагрузки ушли. Затем, через некоторое время, я вернул «Сбалансированный» (Balanced performance) режим и компьютер опять начал перезагружаться. И снова это происходило либо при слабых нагрузках, либо вообще в простое. Возврат профиля «Высокая производительность» снова решил проблему.

Насколько я понял, внезапные перезагрузки возникали из-за попыток ОС Windows управлять состоянием процессора (его частотой или состоянием ядер) при простое. В профиле «Высокая производительность» минимальное состояние процессора равно 100%, т.е. частота не будет снижаться меньше базовой (3.7 ГГц для Ryzen 5900X).

Таким образом, если вы страдаете от внезапных перезагрузок на новом процессоре из серии Ryzen 5000, но ваше остальное железо точно рабочее, а БП способен вытянуть всю систему и стабильно работает под нагрузками — попробуйте поставить «Высокая производительность» в параметрах питания ОС Windows и скорее всего перезагрузки уйдут.

Outlook оставляет копии писем во входящих при перемещении правилами

После миграции с Exchange 2010 на Exchange 2016 всплыл один неприятный глюк: письма, которые автоматически сортируются правилами в аутлуке, начали оставаться в инбоксе. Более подробный анализ показал, что на самом деле они копируются в те директории, в которые они должны перемещаться по правилам.

Стоит заметить, что аутлук 2010 был настроен на хранение всей почты в локальном файле данных, а не на сервере. То есть вся почта хранилась в локальном PST-файле и автоматически удалялась с сервера.

Во всех правилах, которые перемещали письма по директориям, было установлено также действие «Stop processing more rules» (эта рекомендация также встречается при исправлении такой проблемы). Но это не помогало — часть писем исправно сыпались как в инбокс, так и в свою директорию.

После подробного анализа всех писем, которые попадали не по адресу и правил, их сортирующих, была замечена одна маленькая деталь: корректно отрабатывали те правила, в которых было добавлено условие «on this computer only». В итоге, ко всем правилам, которые отрабатывали некорректно, было применено дополнительное условие «on this computer only» и проблема исчезла.

Зависает подключение к удаленному рабочему столу (RDP) при подключении через VPN

В период массового перехода на удаленную работу, многим пришлось познакомиться с таким явлением как удаленный рабочий стол. В большинстве случаев, компании предоставляют удаленный доступ к рабочим компьютерам только при подключении через VPN — таким образом обеспечивается более высокий уровень безопасности сети компании.

При использовании RDP поверх VPN периодически могут возникать странные «зависания» удаленного рабочего стола, с последующими дисконнектами или без них или просто значительные подтормаживания интерфейса. Конечно, сначала необходимо исключить проблемы на сетевом уровне (потери пакетов, низкая скорость, высокие задержки и т.д.), но если они уже исключены, а проблемы повторяются — с большой долей вероятности ваш клиент работает по протоколу UDP. Этот режим работы стал режимом по умолчанию начиная с версии RDP 8.0. Сам по себе он призван ускорить работу с RDP, но в связке с VPN-подключением, когда пакеты начинают фрагментироваться перед отправкой в туннель и собираться заново на другом конце — могут возникать проблемы с одновременной доставкой всех «частей» пакета и невозможностью его сборки и, как следствие — задержки и зависания интерфейса.

Отключить работу через UDP можно двумя способами:

  1. Правка реестра. В ветке HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client необходимо создать параметр fClientDisableUDP и установить значение 1.
  2. Групповые политики. Необходимо перейти в Computer Configuration -> Administration Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client и установить настройку «Turn Off UDP On Client» в Enabled.

После этого зависания должны прекратиться.

Миграция dual-boot Windows 7 + Windows 10 на другой HDD с загрузкой по UEFI

После переноса ОС на другой HDD (или SSD) путем клонирования или при помощи «специальных тулов» для миграции, могут возникнуть проблемы с загрузкой Windows 10. В частности, частой проблемой является черный экран после загрузки, на котором виден только курсор. Ожидание не приносит результатов, загрузка в безопасном режиме тоже ничего не решает. Инструмент автоматического решения проблем при загрузке не помогает. При этом первая система (Windows 7) работает отлично и грузится без проблем.

Для «лечения» нам понадобится загрузить компьютер при помощи установочного диска Windows 10, затем:

  • Открыть командную строку;
  • Запустить diskpart;
  • Найти загрузочный раздел при помощи команды list volume и букву системного диска;
  • select volume X (X — загрузочный раздел fat32);
  • assign letter w (назначаем букву, чтобы получить доступ к файлам);
  • exit (выходим из diskpart);
  • bcdboot Y:\Windows /s w: /f UEFI (где Y — буква диска, на котором находится папка Windows);
  • Перезагружаем систему и при загрузке выбираем новый пункт меню (если он появился);
  • Открываем msconfig и удаляем из пунктов загрузки «старую» опцию \Windows, оставляем только C:\Windows для нашей windows 10 и пункт с загрузкой Windows 7 (при наличии).

The application-specific permission settings do not grant Local Activation permission for the COM Server application…

На разных серверах в разное время возникают ошибки вида:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {8D8F4F83-3594-4F07-8369-FC3C3CAE4919}
  and APPID
 {F72671A9-012C-4725-9D2F-2A4D32D65169}
  to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

Чаще всего они остаются без внимания, т.к. вроде бы все работает без проблем и нет ни малейшего желания разбираться с ошибками, которые ни на что не влияют. Ровно до тех пор, пока не возникает необходимость мониторить ошибки на всех серверах и как-то их обрабатывать. Вот тогда-то они и начинают мозолить глаз.

Итак, для исправления этой ошибки нам необходимо выдать соответствующей учетной записи те права, которых ей не хватает. Для этого надо:
1. Запустить Component services из administrative tools;
2. Перейти по дереву в Component Services -> Computers ->My Computer -> DCOM Config;
3. Кликнуть ПКМ на DCOM Config, выбрать View->Detail;
4. Справа мы увидим список приложений с их Application ID. Список не сортируется и вам придется вручную найти APPID из вашей ошибки. Находим и кликаем по нему ПКМ, заходим в Properties;
5. Переходим на вкладку Security;
6. Выбираем в блоке Launch and Activation Permissions пункт Customize и нажимаем Edit;
7. Добавляем NT AUTHORITY\SYSTEM в список и разрешаем ему Local launch и Local activation;
8. Перезапускаем сервис, использующий этот AppID (или перезагружаем компьютер/сервер). Ошибки должны исчезнуть.

А теперь поговорим о том, что же делать, если на вкладке Security ничего нельзя выбрать (как это и бывает в большинстве случаев), т.е. если все контролы отключены. Для этого запускаем Regedit, дальше:
1. Идем в HKLM\SOFTWARE\Classes\AppID;
2. Находим наш AppID в списке;
3. Кликаем ПКМ, открываем Permissions;
4. Переходим в Advanced;
5. Меняем владельца на свою учетную запись (изначально там TrustedInstaller), в противном случае не сможем поменять свои права;
6. Добавляем себе права на Full Control;
7. Возвращаемся в Component Services и проделываем пункты 1-8;
8. Возвращаем владельца ветки реестра, а для этого указываем в качестве владельца NT service\TrustedInstaller. Если компьютер в домене — не забываем выбрать локальный компьютер в качестве области поиска пользователя.

На этом всё, ошибка не будет больше досаждать.