⚙️ О развитии утилиты diskusage

Сегодня в рубрике "Возвращаясь к напечатанному" утилита для анализа дискового пространства, входящая в поставку Windows 11. Три года назад я публиковал в блоге подробный разбор ключевых функций.

На тот момент утилита только появилась в предварительных сборках, и у меня был ряд нареканий. С тех пор основные недочеты устранили. Давайте пройдемся по улучшениям!

⚙️ Определение размера системных файлов
На смену ключу /systemAndReserve пришли два:
• /systemFile[:N] для отображения служебных системных файлов
• /reserved для зарезервированного пространства

Ключ /systemFile[:N] отображает системные файлы, которые обычно не видны в файловых менеджерах:
diskusage /systemFile:15 /humanReadable

Результат команды на картинке↓ В отчет входят служебные файлы NTFS, включая $MFT и $UsnJrnl. В целом очень похоже на вывод:
fsutil volume allocationreport C:

Этот ключ также закрыл вопрос с теневыми копиями, которые утилита изначально могла отображать только при запуске от имени системы. Пути вида C:\{GUID}{GUID} — это теневые копии. Вроде, это первая комплектная утилита, которая показывает размер отдельных теней.

Да, хотелось бы видеть папку System Volume Information в рамках вывода самых больших папок, /TopDirectory[:N]. Но и на том спасибо 👌

⚙️ Определение объема зарезервированного пространства
Ключ /reserved, как и его предшественник, не срабатывает в сочетании с [некоторыми] другими. Если смотреть отдельно, быстрее всего натравить утилиту на пустую папку:
diskusage C:\new /reserved /humanReadable

У меня в одной из систем объем зарезервированного пространства по сведениям утилиты отличается от цифры в параметрах на 1.5 GB. При этом он почти совпадает с объёмом первой из трёх зарезервированных областей:
fsutil storagereserve query C:

В остальных тестовых системах вывод в целом соответствует значению в параметрах. Да и так известно, что резервируется около 7 GB. Но такие разночтения не повышают доверие к результатам.

🔗 Переход по символическим ссылкам и соединениям
Изначально это было поведением по умолчанию, а выключалось оно ключом /skipReparse. Я отметил, что логично было сделать наоборот.

Действительно, впоследствии стали игнорировать символические ссылки и соединения, для явного перехода по ним добавили ключ /reparse, а ключ /skipReparse убрали из справки.

📃 Изменения в синтаксисе
Для указания значений перешли от знака равно к двоеточию. Было /TopDirectory=25, стало /TopDirectory:25. Впрочем, старый синтаксис пока тоже работает.

Все ключи: было | стало.

////
Я стараюсь поддерживать все материалы блога в актуальном состоянии. Вот и на сей раз #классика блога обновлена.

И да, я знаю, о чем вы сейчас думаете: "Зачем все это, если есть TreeSize, WinDirStat, Scanner и т.д." 🤔

Однако у встроенной консольной утилиты есть два неоспоримых преимущества:
🔹 работа в огороженной системе, где нельзя просто взять и скачать стороннее ПО
🔹 дистанционная помощь без лишних телодвижений: "выполни команду - покажи результат"

🕑 Как определить, является ли происходящее следствием запущенного из планировщика задания

Или наоборот - как исключить задание из списка подозреваемых в каком-то поведении системы.

Серебряной пули не существует, но есть подходы.

1️⃣ Запись активности процессов

Если процесс запущен из планировщика, его родительским процессом будет taskeng.exe. Однако он завершается после отработки задания, поэтому отследить его можно только записью. Например, с помощью WPR или Process Monitor, как в деле об автозагрузке Windows. Там из планировщика запускался промежуточный процесс, кстати.

2️⃣ Журнал событий планировщика и аудит процессов

Иногда можно косвенно определить связь по времени, когда поведение наблюдается сразу после выполнения запланированного задания. Аудит процессов помогает сопоставить время выполнения задания и запуск процесса. Однако надо держать в уме, что после — не значит вследствие.

По умолчанию история планировщика отключена, но ее можно активировать в правой панели оснастки. Это действие эквивалентно включению журнала событий Microsoft-Windows-TaskScheduler/Operational. Именно в него пишется история планировщика.

Дальше можно смотреть в журнале событий или #PowerShell. Ниже пример отбора заданий, запущенных за последний час. Я уже разбирал в канале такую выборку с хэш-таблицей.

Get-WinEvent -ErrorAction 0 -FilterHashTable @{
LogName='Microsoft-Windows-TaskScheduler/Operational'
ID='100'
StartTime=(Get-Date).AddMinutes(-60)
#TaskName='\CreateExplorerShellUnelevatedTask'
} | ft -wrap

Здесь закомментировано имя конкретного задания. Выборка по нему сработает только в PowerShell Core. Там можно фильтровать по именованным полям событий, тем самым обходясь без передачи по конвейеру в Where-Object и ускоряя процесс.

Эти поля отображаются в XML-представлении задания↓ Помимо документации см. также мои скрипты для поиска событий аудита реестра и процессов.

Через пару дней в блоге вышла статья, для которой я сопоставлял историю заданий планировщика и запуска процессов ✌️

⚙️ Новое в блоге: Нюансы запуска проводника с полными правами

Недавно мой коллега Дмитрий с канала @winitpro_ru обновил свою классику блога про запуск проводника от имени администратора. Этот трюк в первую очередь ценен для корпоративных серверов. Дома-то можно и сторонний файловый менеджер с правами администратора запустить.

Но любопытно же покопаться в вопросе! Я ведь интересуюсь этой темой ещё с завещания мистера Гейтса, написанного в 2011 году. Сейчас Дмитрий добавил в свою статью альтернативный метод, который появился уже во времена Windows 10.

👉 Если завершить процесс explorer и сразу же запустить его с ключом /NoUACCheck, проводник получит полные права.

В Windows 11 я это не проверял. В статье Дмитрия говорилось, что должно работать. Но у меня не сработало!

➡️ Читайте в блоге: https://www.outsidethebox.ms/22306/

▶️ PowerShell vs. CMD: управление пользователями и группами

Читателям канала со стажем этот пост покажется знакомым, потому что я уже поднимал похожую тему в рубрике #PowerShellvsCMD. Однако там лейтмотивом была независимость команд от языка интерфейса ОС. А здесь в форум пришёл человек с просьбой помочь ему написать батник для отключения всех локальных юзеров, входящих в группу "Пользователи удаленного рабочего стола".

Он знал, как вывести всех пользователей и отключить отдельного:

net localgroup "Пользователи удаленного рабочего стола"
net user "Username" /active:no

И хотел связать это воедино. Впрочем, в течение часа он сам опубликовал решение, уложившись всего в 8 строк с помощью FOR и FINDSTR - классика жанра!

Между тем, на #PowerShell задача легко и надежно решается в одну строку:

Get-LocalGroupMember -SID S-1-5-32-555 | ForEach-Object {Disable-LocalUser -SID $_.SID}

Здесь S-1-5-32-555 - известный идентификатор группы пользователей удаленного рабочего стола. Выборка по SID в первой части конвейера позволяет не зависеть от языка системы, а во второй - исключает любые неожиданности с именами пользователей ✌️

- К. научил вчера ночью делать скрин Виндоус+шифт+S и вставлять в телегу клавишей V, отлично работает!

- ОМГ ты же 3 года назад не хотела слушать про это

- я и не буду пользоваться, это ж три клавиши нажать...

- в параметрах поищи Print Screen и повесь на нее!

- 🙄

Так и живем :)

⚙️ winget: исключение приложений из массового обновления

Сегодня в рубрике "Возвращаясь к напечатанному" команда pin менеджера пакетов winget. Разбирая нюансы автоматического обновления приложений осенью 2022 года, я сетовал на отсутствие такой фичи в winget. Ее добавили летом 2023 года в качестве отдельной команды.

Документация имеется, но ввиду ее автоматического перевода на русский язык прокомментирую три варианта исключений тут.

🔹 Закрепление
winget pin add powertoys

Вместо имени пакета можно использовать --id. Команда исключает приложения из обновления командой winget upgrade --all, но позволяет включить их разово ключом --include-pinned. Также работает обновление отдельного пакета: winget upgrade powertoys.

🔹 Блокировка
winget pin add powertoys --blocking

В этом случае обновление пакета (отдельно или массово) возможно лишь с ключом --force либо после снятия закрепления:
winget pin remove powertoys

🔹 Диапазон версий
winget pin add --id powertoys --version 0.70.*

Здесь все версии 0.70.ххх не будут обновляться. Обход ключом --force.

Наконец, можно посмотреть все исключения:
winget pin list

А также массово сбросить их:
winget pin reset --force

#Классика блога обновлена. Но помимо команды pin есть и другие улучшения. В ближайшее время я еще раз обновлю статью и расскажу об этом в канале ✌️

⚙️ Нюансы очистки записей в окне "Выполнить" (Run)

Сегодня в рубрике "Возвращаясь к напечатанному" очистка истории окна "Выполнить". Участник чата @Xodiak прочел в блоге мою статью и заметил, что там не раскрыта тема удаления отдельных записей из истории окна Run.

Статья в принципе была про адресную строку проводника, поэтому описывала только ее путь в реестре. Я добавил туда раздел реестра RunMRU, дописал "Run" в заголовок статьи и счел тему закрытой.

Однако спустя пару дней Андрей Шубин спросил, как удалить оттуда записи, которые начинаются с ms-, типа ms-gamebar://. История ввода в окно была очищена, но эти подсказки никуда не делись.

👉 Решение немедленно подсказал 4eL0wEk - очистить журнал автозаполнения! В пуск поискать Internet Options (Свойства браузера), а дальше см. картинку↓

Вы догадались, об истории какого браузера тут речь? 😎 Да, это Internet Explorer, которого как бы уже нет в Windows. На самом деле он никуда не делся. Его несложно запустить и убедиться в наличии этих записей в истории "этого компьютера".

В журнал эти записи попадают при вызове различных приложений системы, связанных с той или иной ссылкой ms-. Так, игровая панель Xbox связана в Параметрах с типом ссылки URL:ms-gamebar. И каждый раз, когда я жму Win+G, в журнал IE вносится запись об этом! Я нередко нажимаю это сочетание клавиш случайно, поэтому записей хватает :)

С момента обсуждения этой темы в чате прошло уже больше месяца. А пару дней назад я делился ссылкой на другую свою полезную статью - про автоматическую подсказку и подстановку команд. Я исторически включаю автоподстановку, чтобы максимально быстро 🚀 открывать из Win+R оснастки (devmgmt, diskmgmt), regedit и прочие утилиты из PATH.

Внезапно я заметил, что в конце этой статьи таки раскрыта тема удаления отдельных записей из окна Run. Да и про историю IE там тоже написано... еще 13 лет назад! Как всегда, новое - это хорошо забытое старое ✌️

💾 Об окне форматирования томов в Windows

На этой неделе все профильные и даже непрофильные каналы потешаются над Microsoft - мол, за 30 лет так и не обновили древний диалог 🤡

Отдельно доставило глумление над UX, который в этом окне абсолютно нормальный для классического Win32. Попадались даже придирки к непоследовательности двоеточий в названиях элементов. Да, техническим писателям или инженерам QA это бросается в глаза. Но предъявлять за такое махровому легаси... 🙄

Ноги у веселья растут из твита Дэйва Пламмера, бывшего разработчика Windows, который когда-то этот диалог и написал на коленке. Сейчас он на пенсии развлекает публику такими вот историями.

👉 При этом петросяны массово не в курсе, что диалог уже обновили! Вот же он на картинке↓ - с тёмной темой и масштабированием. Даже опция сжатия тома появилась. И с двоеточиями нет проблем.

Управление дисками начали добавлять в Параметры еще летом 2020 года, в сборке Windows 10 20197. Фичу долго мариновали в предварительных версиях, и в Windows 10 она уже не попала. Однако точный момент появления в Windows 11 трудно определить.

Разумеется, никто не будет вносить изменения в древний диалог. Ну, поправит вам разработчик двоеточия, сделает юнит-тест. А регрессионного тестирования-то нет. И вот уже ничего не форматируется 🤔

И убирать старое окно не стали намеренно. Потому что привычка вызывать его из контекстного меню диска у многих выработана годами. Можно автоматически перекидывать в Параметры, но в данном сценарии UX лучше не станет. А если еще и новый диалог сразу не открыть, пользователь точно отложит кирпич 🧱

Поэтому никуда не денется и оснастка управления дисками, не говоря уже о diskpart. Microsoft много за что можно предъявить. Но компания точно впереди планеты всей по длительности поддержки старых функций и хранения в системе разнообразного легаси. Да, выглядит оно несовременно и не масштабируется. Зато лежит под рукой и работает ✌️

📉 О производительности оболочки Windows

К сожалению, в Windows 11 обертка проводника получилась тормозной. И новые контекстные меню тому лучшее свидетельство. Они открываются с заметной задержкой, а пункты некоторых приложений иногда даже не отображаются с первого раза 🤦‍♂️

С видимыми лагами сопряжен и прямой вызов старого меню, в том числе из сторонних файловых менеджеров. При этом в моих замерах классика появляется примерно на треть быстрее нового меню 👈

Хотя с первого выпуска Windows 11 прошло уже больше двух лет, существенных улучшений в производительности не наблюдается. Прикручивание к проводнику бессмысленных вкладок только усугубило ситуацию. И окончательно подвигло меня к возврату на 💾Total Commander после многолетнего перерыва.

🙄 Однако команда оболочки Windows делает вид, что проблемы нет, и такие тормоза — нормально!

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

Исключение шести программ из меню ускорило его открытие в проводнике примерно в три раза❗️ У классического меню, вызываемого из Total Commander, разница была не столь драматичная, но все равно без программ оно открывалось на 23% быстрее.

Я тестировал MP3-файлы вне сферы облачного диска OneDrive. Конкретно с этим типом файлов были связаны две программы из шести. Остальные четыре были сопоставлены с любыми файлами.

Разумеется, скорость может сильно варьироваться в зависимости от железа, набора программ в меню и типа файлов. Но у меня нет никаких сомнений, что сейчас производительность вывода программ и прочих элементов контекстного меню ниже плинтуса 👎

Отдельно доставляет, как значки команд подгружаются уже после отображения всех пунктов меню. В ролике↓ скорость воспроизведения сначала 100%, а потом замедлена до 30%, чтобы получше рассмотреть происходящее. Первый вызов меню всегда неприемлемо тормозной, даже если несколькими минутами ранее я уже открывал его в том же окне.

📊 Недавний опрос читателей показал, что как минимум 6 из 10 человек не устраивает скорость открытия меню и/или лишние пункты в нем. Скоро я опубликую в блоге статью с подробными инструкциями по зачистке от ненужных программ контекстного меню в Windows 11 и 10. Там будет скучный ручной метод и быстрый скрипт для тех, кто не боится консоли.

Но в любом случае полная очистка контекстного меню ради ускорения не имеет смысла. Многие программы там нужны, их выпиливание лишь замедлит выполнение пользовательских задач. Проблему должны решать разработчики Windows! ✌️

⚙️ Новое в блоге: Edge - быстрая настройка браузера и отключение раздражителей скриптом

Microsoft Edge — мой основной браузер, и в целом он меня устраивает. При этом есть набор параметров, которые я всегда изменяю на своих многочисленных системах, в том числе экспериментальных ВМ.

👉 Я предпочитаю групповые политики Edge по ряду причин:

- быстрое массовое применение настроек
- наличие параметров, не доступных в графическом интерфейсе (например, первый запуск браузера)
- блокирование маркетинговых функций (если фича отключена, ее и продвигать не должны)

Я неоднократно публиковал в канале отдельные политики в виде команд reg add. Сегодня я делюсь полным скриптом #PowerShell для быстрой настройки Edge 🎉

На картинке вид новой вкладки при первом запуске браузера (или нового профиля) после применения скрипта.

➡️ Читайте в блоге: https://www.outsidethebox.ms/22326/

▶️ Простой пример оптимизации скрипта #PowerShell с помощью хэш-таблицы

Первые два отзыва на мой скрипт для настройки браузера Edge с помощью политик были критические. Мне попеняли на его перегруженность множеством вот таких↓ однотипных команд. Действительно, в них отличаются только названия параметров и значения, а всё остальное неизменно.

New-ItemProperty -Path $path -Name HideFirstRunExperience -Type Dword -Value 1 -Force | Out-Null

Но эта история изначально была не про PowerShell, а про коллекцию политик. В скрипте же я исходил из того, что многих заинтересуют лишь некоторые твики. И такие люди будут копипастить отдельные строки прямо с веб-страницы в консоль. Я сам так неоднократно делал :)

👉 Если же не думать об этих людях и задействовать фирменные возможности PowerShell, скрипт получится намного аккуратнее и компактнее. К таким фичам относятся хэш-таблицы. Причём дальше примера из справки ходить не надо.

[hashtable]$hash = @{
HideFirstRunExperience = 1
AutoImportAtFirstRun = 4
BrowserSignin = 0
}

foreach ($key in $hash.keys) {
New-ItemProperty -Path $path -Name $key -Type Dword -Value $($hash[$key]) -Force | Out-Null
}

Хэш-таблица создается первой строкой и далее наполняется парами "параметр = значение". В реестр изменения вносятся с помощью выражения foreach - перебором всех пар.

Все прочие аспекты скрипта неизменны. Я добавил в архив версию с хэш-таблицей ✌️

🤦‍♂️ Ловушка MBR для продуктовой группы Microsoft

Сегодня в рубрике "Возвращаясь к напечатанному" эпичная ошибка в статье базы знаний (MSKB) KB5028997. А также на всех сайтах, которые перепечатали эту инструкцию по ручному увеличению раздела для установки обновления WinRE. Тысячи их ©

Upd. Вскорости после публикации моего поста ошибку исправили. Совпадение? Не думаю ©

⌛️ История и контекст
В январе 2024 года Microsoft выпустила обновление безопасности для среды восстановления Windows 10. Однако у многих оно не устанавливалась из-за слишком маленького раздела RE. В связи с чем компании пришлось выпустить инструкцию по его увеличению.

Тогда же я опубликовал в блоге большой FAQ, который поможет вам освежить память. Чтобы проникнуться эпичностью ошибки в MSKB, нужно понимать, зачем RE размещают на отдельном разделе:

Это необходимо для восстановления при включенном шифровании BitLocker. Если среда на разделе с ОС, в нее невозможно загрузиться с зашифрованного раздела. В этом случае для входа в Windows RE понадобится установочный диск.

🐞 Суть ошибки
О ней мне рассказал читатель блога Артём. Он следовал инструкциям в разметке MBR и обнаружил, что в итоге среда восстановления оказывается вовсе не на увеличенном разделе RE, а на разделе с Windows! Сопоставив инструкцию Microsoft с материалами моего блога, Артём вышел на причину ошибки - она в шаге 5.

На шаге 5a создается новый раздел. И, что несколько необычно, в команде создания сразу указывается GUID, задающий тип раздела (управление служебными атрибутами я подробно разбирал в блоге). Дальше на шаге 5b раздел форматируется в NTFS.

В разметке GPT форматирование раздела не затрагивает его служебный идентификатор (см. строки 84-105). Но в разметке MBR ИД 0х27 после форматирования сбрасывается. И раздел становится обычным, с ИД 0х7! 🙈 Я демонстрирую это на картинке↓

Upd. В исправленной версии статьи появился шаг 5c, которым в MBR заново задается правильный ИД.

Дальше включается среда восстановления, и образ должен оказаться на разделе Windows RE. Но поскольку правильного ИД у него нет, по алгоритму образ размещается на разделе с ОС - в папке C:\Recovery.

Разумеется, после этого злосчастное обновление RE устанавливается без проблем - ведь на разделе Windows полно места :) Но это делает бессмысленным всё мероприятие! Поскольку при таком раскладе в RE не загрузиться с зашифрованного диска.

⚙️ О важности тестирования
Я не случайно упомянул ресурсы, перепечатавшие инструкцию. Так, я ссылался на русскоязычный гайд COMSS в своем FAQ - там много картинок, всё как вы любите :)

Безымянный автор тщательно проследовал по шагам на MBR (!) и ничего не заметил. Хотя на первом и последнем скриншоте командной строки с выводом утилиты reagentc видно, что среда восстановления в итоге переехала с partition3 (RE) на partitoin2 (Windows).

Я, кстати, протестировал инструкцию Microsoft, прежде чем советовать её. Но только на GPT. С MBR у меня сейчас и виртуалок-то нет. Видимо, так же обстоят дела и у продуктовой группы, которая опубликовала инструкцию в MSKB :)

В заключение я просто оставлю здесь практические советы по переходу с MBR на GPT ✌️

⚙️ Облачная переустановка поверх в параметрах Windows 11

Осенью 2019 года в Windows появилась функция облачного сброса. Тогда я доставил ПМу, что куда полезнее была бы функция переустановки поверх, которая сохраняет программы и настройки в отличие от сброса.

По его просьбе я отправил развёрнутые аргументы в центр отзывов, и ныне удаленное предложение набрало более 100 голосов 👍 Это очень много для такой технической функции. На русском языке я озвучил тезисы в канале. Прочтите их, чтобы прочувствовать важность фичи!

🎉 И спустя 4.5 года в параметрах появилась облачная переустановка поверх!

Фичу доставили в рамках обновления Moment 5. Она описана в статье базы знаний KB5036436. Помимо прочего там:

• отмечается, что в центре обновления может появиться предложение выполнить облачную переустановку в случае неудачной установки исправлений
• приводится список условий и групповых политик, при наличии которых функция недоступна

🔄 Прогресс загрузки установочных файлов и ход установки отображаются в центре обновления. В целом - это стандартный процесс переустановки поверх, хотя и без присущих ему экранов. Кстати, в РФ фича обретает дополнительную ценность на фоне препятствий загрузке MCT и ISO.

Но есть и ложка дегтя 🤷‍♂️ Поскольку процесс завязан на Windows Update, неподдерживаемые конфигурации блокируются. И не прокатит обходной путь AllowUpgradesWithUnsupportedTPMOrCPU, т.к. он для установки с флэшки.

Так или иначе, фича ценная, и новость отличная! #Классика блога про переустановку поверх обновлена ✌️

🔒 KeePass: автоматический ввод учетных данных в браузере по URL страницы

Я уже рассказывал в канале про годную функцию автонабора у KeePass. И как выяснилось, почти половина пользователей этого менеджера паролей о ней не знала. Там речь шла о порядке записей в результатах поиска. Сегодня - о вводе в браузерах, причем без плагинов KeePass.

На картинке↓ настройки автоматического ввода, где цифрами отмечены ключевые. Пункты 2 и 3 по сути относятся только к браузерам. Давайте разберем их на примере входа в GitHub https://github.com/login

1️⃣ В заголовке окна есть совпадение с названием записи KeePass

Здесь заголовок - Sign in to GitHub · GitHub. Поэтому сработает любое из этих слов в названии записи KeePass - например, Sign in и GitHub. Но во избежание ложных срабатываний лучше использовать что-то уникальное - строку целиком или ее существенную часть.

Это - самый удобный способ, но не лишенный недостатков. С ними я регулярно сталкиваюсь в рабочей среде. Например, заголовок страницы авторизации у разных внутренних веб-сервисов одинаковый - Sign in. Или он более информативный, но одинаковый в разных средах разработки ПО - Dev, QA, Integration.

2️⃣ В заголовке окна есть URL целиком из записи KeePass

Это - большая редкость, т.к. сайтам нет смысла прописывать адрес страницы в её заголовок. И как раз это я разберу подробнее чуть ниже.

3️⃣ В заголовке окна есть домен, который присутствует в URL из записи KeePass

Это чаще встречается у иностранных сайтов. Допустим, прописав https://www.google.com/ в поле URL, вы сможете входить на любой странице сервисов компании. Потому что слово Google есть в заголовке страницы и в поле URL. С GitHub та же история. Но у прочих сервисов Microsoft такое не сработает, равно как у Яндекс и Госуслуг.

////

В итоге пункт 2 выглядит самым бесполезным, однако он очень перспективный! Как справедливо заметил в чате dartraiden, если в KeePass корректно заполнено поле URL, задача сводятся к тому, чтобы прописать URL веб-страницы в её заголовок 👈
И она элементарно решается с помощью расширений для Chromium и Firefox.

Однако мне не нравится, что только ради этого расширение получает право читать и изменять данные на всех сайтах. Поэтому я предпочел более контролируемый вариант - скрипт для Tampermonkey 🐵 Сходу нагуглился такой. Из коробки результат страшноват, но это легко допилить. И не забыть отключить автоматическое обновление скрипта!

С браузерами разобрались, но остается проблема с однотипными окнами Sign in в других приложениях. Она, кстати, недавно обострилась у меня на работе. И я обязательно поделюсь решением в канале ✌️

ℹ️ Все записи по теме: #autotype

⚙️ Как настроить открытие ссылок в приложении YouTube Revanced без рута и ADB

Мой друг на новом телефоне возжелал привычный YouTube с фоновым воспроизведением. С установкой клиента Revanced проблем не возникло. Однако ссылки на видео все равно открывались в официальном приложении, которое нельзя просто взять и удалить. Телефон Xiaomi с MIUI, но такое возможно и с другими оболочками.

В настройках Android есть управление ссылками, но пляски с бубном вокруг обоих клиентов YouTube ни к чему не привели. Я спросил чат - Niks быстро доставил решение. И оказалось, что именно его я применил когда-то на своем телефоне, о чем успешно забыл 🤦‍♂️ Поэтому оставлю его здесь - в своей публичной записной книжке.

⏯ Процесс показан на видео, которое надо смотреть во весь экран.

1. Установите Better Open With.
2. В разделе Browser выберите из списка сайтов YouTube и задайте приложение для открытия ссылок.

Поскольку у обоих приложений одинаковые значки, Revanced определяется экспериментально. Чтобы не путаться, можно задать разные темы оформления✌️

⚙️ Новое в блоге: Как убрать ненужные программы из контекстного меню Windows

Проводник Windows 11 получил новое контекстное меню и способы интеграции приложений в него. Поначалу в меню было пустовато. Но со временем разработчики освоились и начали добавлять туда свои программы.

Сегодня я расскажу, как убрать ненужные пункты, чтобы улучшить UX и ускорить открытие меню. И нет, старые утилиты от NirSoft вам с этим не помогут.

В этой статье:
🔹 принцип регистрации в новых меню (а заодно и в старых, т.е. в Windows 10)
🔹 ручной способ удаления ненужных программ
🔹 скрипт #PowerShell для быстрого удаления 🚀
🔹 различные нюансы

➡️ Читайте в блоге: https://www.outsidethebox.ms/22361/

❌ Об ошибках в журналах событий Windows

Помимо пристрастия к чистке реестра есть еще один тип виндовой озабоченности, хотя и менее распространенный. Это устранение ошибок из журналов событий. Читатель блога WhiteRabbit попросил в почте разобраться с некой ошибкой, но даже с двух попыток не смог объяснить, в чем конкретно проблема. В смысле, проблемой он считал сам факт наличия ошибки в журнале 🙄

Это не так работает. У журналов событий три основных применения:

🔹 Проверка работы конкретных процессов или компонентов, аудит и прочий превентивный мониторинг. Это больше свойственно организациям.

🔹 Изучение работы Windows. Выполнили какое-то действие - посмотрели, что записалось в журнал.

🔹 Устранение неполадок. Это самый распространенный сценарий. Однако здесь изначально должна быть какая-то проблема 👈 Далее вы используете журнал событий в качестве диагностического средства, чтобы выйти на причину проблемы. Примеры в канале: раз, два.

В многочисленных журналах регистрируются тысячи ошибок. В моей системе #PowerShell насчитал↓ 463 обычные и критические ошибки за последние 24 часа, треть из которых Windows провела во сне. Но многие по сути даже не являются ошибками!

Например, у меня практически каждая перезагрузка основной ОС сопровождается событием 100 с критической ошибкой. Система перезапускается в основном для установки обновлений. Поэтому длительность процесса выходит за рамки нормы. Ну и ладно, я вообще в это время сплю!

ℹ️ В базе знаний Microsoft описано немало безвредных ошибок, которые можно можно смело игнорировать. Вот некоторые примеры. Видимо, объем обращений по ним в поддержку вынудил продуктовые группы отразить это в документации.

Резюме: жизнь слишком коротка, чтобы пытаться устранить все ошибки в журналах событий Windows ✌️