⚙️ О параметрах программы установки Windows (setup.exe)

Недавно в форуме я увидел ошибочное утверждение, что setup.exe предназначен исключительно для установки из-под живой системы, нежели из-под Windows PE. Его автор развертывает ОС применением WIM-образа к диску, что могло повлиять на восприятие :)

Да, переустановка поверх запускается только из-под работающей Windows. Но это не единственный способ вызова программы установки!

ℹ️ Первый проход установки ОС не случайно называется windowsPE. Когда вы загружаетесь с флешки или ISO, диспетчер загрузки обращается к boot.wim. А там как раз Windows PE, которая целиком загружается в оперативную память. Поэтому setup.exe запускается именно из PE, хотя и без параметров, что видно на картинке.

👉 Читайте также: Нюансы программы установки Windows.

Однако дистрибутив может лежать на внешнем или сетевом диске. Это повод загрузиться в среду PE (чистую или условного Стрельца) и запустить setup.exe с нужными параметрами. И у Microsoft есть большой документ, описывающий ключи командной строки программы установки: Windows Setup Command-Line Options 📄

В описании каждого ключа имеется раздел Applicability с таблицей, где в первой строке "Setup.exe started from WinPE - Yes/No". То есть, работает ли этот ключ при запуске из PE.

Кстати, начиная с версии 24H2 в PE поддерживаются еще 9 ключей. В том числе:
• /CompactOS для сжатия системных файлов.
• /PostOOBE, задающий расположение setupcomplete.cmd, который иначе надо добавлять в образ напрямую или с помощью OEM-папок
• /ConfigFile, указывающий на INI-файл с ключами (однако над ними преобладают ключи, переданные в командной строке)

Вообще, документация по установке Windows очень приличная и в целом поддерживается в актуальном состоянии. Да и у меня в блоге немало статей с меткой автоустановка. Приятного чтения! ✌️

💩 Тревога В действии

Здесь на панели задач сошлись все звезды:
• #автоперевод Warning in effect
• коричневый оранжевый уровень опасности
• пиктограмма ветра (а не то что вы подумали :)

🙄 О нововведениях в современной Windows

Много лет назад в Windows Vista переосмыслили работу обычным пользователем. Тогда появился контроль учётных записей (UAC). Причём было только две опции — уведомлять всегда или никогда. Включение порождало слишком много уведомлений, и люди громко жаловались. Поэтому в Windows 7 сделали поменьше уведомлений для администраторов.

⚙️ С другой стороны, обычным пользователям стал доступен ряд настроек, для которых в Windows XP были необходимы права администратора. Например, добавление принтеров, управление электропитанием и настройка часового пояса (но не времени). Последнее регулярно пиарили на разных конференциях — посмотрите, как стало удобно!

Я вспомнил об этом, просматривая описание предварительного февральского обновления для Windows 11 24H2 — KB5050094. Моё внимание привлекло нововведение в Параметрах:

[Settings] New! You can change time zones in Settings > Time & Language > Date & Time. You don’t have to be an admin to make this change.

Ура, теперь не надо быть админом, чтобы менять часовой пояс! Но ведь у нас это было почти 20 лет назад 🤦‍♂️ Впрочем, я не знаю, как давно они сломали.

По состоянию на январь 2024 года проблема воспроизводилась в Windows 10 22H2 и Windows 11 23H2 & 24H2. В Windows 8.1 обычный пользователь может задавать часовой пояс без проблем, но там ещё нет опции автоматического выбора. Замечу, что в актуальных ОС для включения автоматики нужно в настройках конфиденциальности разрешить десктопным программам доступ к местоположению.

////

Вообще, разработчики Windows в последнее время взяли моду выдавать устранённые баги UX за нововведения 😡 Например, под таким же соусом подали исправленное перетаскивание в адресную строку Проводника спустя 9 месяцев после поломки.

Разумеется, они не считают это дефектами, если фича подвергается переработке и получает какие-то другие улучшения. Хорошо, если они понимают деградацию пользовательского опыта и сразу планируют исправление в обозримом будущем, как в случае с адресной строкой.

Но так бывает не всегда. Размещение панели задач сбоку, выпиленное из Windows 11 фактически ради дизайна, до сих пор не вернули. И сломанная смена часового пояса могла у них в бэклоге годами лежать — обычным пользователям слова не давали! Пока кто-то не решил поднять себе KPI выпуском "новой" фичи. И вот, встречайте 🎉

Внимательные читатели заметят на картинке ещё одну новую старую фичу. Но по крайней мере создание папки не выпиливали из классического контекстного меню, которое до сих пор доступно.

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

🔁 Новое в блоге: Нюансы восстановления параметров и приложений из современного бэкапа Windows

Мой товарищ устанавливал систему на новенький Surface, и его заинтриговала возможность восстановить настройки и файлы со старого ПК уже в процессе установки. Правда, не прошло и полчаса, как его постигло жестокое разочарование. В системе не оказалось и половины ожидаемых настроек! 😡

Эта история побудила меня вернуться к теме современного резервного копирования и восстановления в Windows. Я поднял ее осенью 2023 года разбором приложения Windows Backup, но не касался восстановления. Теперь настал и его черед.

К сожалению, похвастаться там особо нечем 🤷‍♂️ Современное резервное копирование и восстановление в Windows – это фактически обертка, в которую завернут старый, хорошо обсосанный леденец.

➡️ Читайте в блоге, как я пришел к такому выводу: https://www.outsidethebox.ms/22565/

🙏 Мой блог https://www.outsidethebox.ms/ снова доступен. И вы можете прочесть свежую статью из утреннего анонса↑

Спасибо всем, кто сообщал о проблеме и благодарил за труды. Иногда надо ощутить нехватку чего-либо, чтобы осознать ценность :)

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

🕒 Как получить сведения о запланированном задании в PowerShell

Смотрел тут свои старые скрипты, решил поделиться. Задача несложная, однако в зависимости от цели может понадобиться три разных запроса.

1️⃣ Состояние задания - Get-ScheduledTask

Годится запрос по имени задания, в том числе неполному. Заодно выведем чуть больше инфо - полное имя, состояние, адрес.

Get-ScheduledTask -TaskName '*sync*lang*' | fl TaskName,State,URI

TaskName : Synchronize Language Settings
State    : Ready
URI      : \Microsoft\Windows\International\Synchronize Language Settings

Задание синхронизации языковых настроек включено.

2️⃣ Сведения о последним запуске задания - Get-ScheduledTaskInfo

Здесь наряду с именем задания требуется еще и путь в -TaskPath. Либо в качестве имени указывайте URI из запроса выше.

Get-ScheduledTaskInfo -TaskName '\Microsoft\Windows\International\Synchronize Language Settings

LastRunTime        : 1/25/2025 10:22:22
LastTaskResult     : 0
NextRunTime        :
NumberOfMissedRuns : 0
TaskName           : \Microsoft\Windows\International\Synchronize Language Settings

LastTaskResult выводит код завершения предыдущего запуска. 0 означает успех, 1 - неудачу, остальное надо смотреть по коду.

⏩ На практике задачи 1 и 2 чаще объединяются в конвейер. Причем можно сходу фильтровать по неполным именам нескольких заданий, обходясь без Where-Object.

Get-ScheduledTask -TaskName *backup*,*sync* | Get-ScheduledTaskInfo | fl TaskName,LastRunTime

3️⃣ Параметры задания - Export-ScheduledTask

Export-ScheduledTask -TaskName '\Microsoft\Windows\International\Synchronize Language Settings'

Выводится XML, как в экспорте задания из планировщика. PowerShell легко перемещается по узлам.

[xml]$task = Export-ScheduledTask -TaskName '\Microsoft\Windows\International\Synchronize Language Settings'
$task.Task.Triggers.LogonTrigger.Delay

PT30S

Задание отложено на 30 секунд после входа в систему.

////

Создание запланированного задания в #PowerShell будет посложнее. Я показывал это в блоге, в том числе в сравнении с утилитой schtasks. Бывает проще импортировать подготовленный XML. Пример уже был на канале ✌️

🧹 Удаление временных файлов из служебных профилей

Недавно я анализировал недостаток дискового пространства на одной системе. Помимо прочего утилита dfp выдала такое:

1.6G      527      191 C:\Windows\ServiceProfiles
1.6G      287       81 C:\Windows\ServiceProfiles\NetworkService
1.6G      281       71 C:\Windows\ServiceProfiles\NetworkService\AppData
1.6G      244       39 C:\Windows\ServiceProfiles\NetworkService\AppData\Local
1.6G      243       34 C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp

Я натравил её на папку Temp и выяснил, что 1.6 GB занято древней папкой с именем типа E58DAD6F-63DE-461C-AB9F-7F58DDC916D9

ℹ️ NetworkService и LocalService - служебные аккаунты, чьи профили хранятся в папке Windows. Их содержимое аналогично профилям интерактивных пользователей из папки C:\Users.

Удаление временных файлов безвредно, причем ухищрений не требуется. В смысле не надо ломиться в системные папки как лось, меняя на ходу разрешения NTFS. Просто в #PowerShell от имени администратора:

Remove-Item -Force -Recurse -Path 'C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\E58D*'

Total Commander или FАR от админа тоже годятся ✌️

😎 Знакомая прислала скриншот веб-редактора аудиофайлов

- какую кнопку нажать, чтобы выйти из этого режима?
- Esc
- сын то же самое сказал, не срабатывает... очень много работы сделала(((
- в смысле боишься потерять?
- да, уже было такое
- перетащи туда файл
- я никогда так не делала
- повод попробовать :)
- ура!!!

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

⚙️ Нюансы префетчинга приложений в Windows

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

• В 2013 году я разбирал префетчинг в рамках мифов оптимизации SSD
• В 2019 году он снова попал в фокус в статье Нюансы отключения службы SysMain в Windows

Niks спросил, работает ли префетчинг по умолчанию, когда система установлена на SSD. Да, работает, и это легко проверить по мотивам статьи про SysMain:

Get-MMagent

ApplicationLaunchPrefetching : True
ApplicationPreLaunch         : True
MaxOperationAPIFiles         : 512
MemoryCompression            : True
OperationAPI                 : True
PageCombining                : True

Параметр ApplicationLaunchPrefetching - это он. Вообще, этот префетчинг еще времён XP, и по большому счету с тех пор ничего не изменилось. Однако сравнивая вывод наших команд, я заметил, что отличается значение MaxOperationAPIFiles. Это предельное количество файлов в сфере префетчинга.

🔢 В Windows 10 и ранее оно по умолчанию 256, а в Windows 11 — 512 (так же и в серверных ОС). Думаю изменение связано с тем, что сама ОС разрослась с 2006 года и запускает больше своих исполняемых файлов.

Niks интересовался, стоит ли увеличить значение до 2048. Чтобы ответить на этот вопрос, нужно:

1. Понимать, запускаются ли .EXE с жесткого диска
2. Проанализировать файлы в папке C:\Windows\Prefetch\

Я не думаю, что древний префетчинг способен ускорить запуск программ с твердотельных накопителей. Но запуск исполняемых файлов (например, игр) с жесткого диска еще может быть актуален. Для оценки можно посчитать количество файлов в папке и сопоставить с лимитом. В #PowerShell от имени администратора:

(Get-ChildItem "C:\Windows\Prefetch\*.pf" -File).Count

ℹ️ На количество файлов могут влиять разные факторы. Например, едва установив систему, вы начинаете ставить и запускать любимые приложения. Каждый установщик - это как минимум один исполняемый файл. С другой стороны, после чистой установки система сама оптимизирует себя, что может быть сопряжено с запуском различных .EXE.

Все это оседает в папке Prefetch. По достижении предела старые записи будут вытеснены автоматически, но "одноразовые" установщики и не нужны.

Если в обжитой системе вы запускаете .EXE с HDD, а количество PF-файлов близко к лимиту, может иметь смысл увеличить предельное значение.

Set-MMAgent -MaxOperationAPIFiles 1024

Так, у Niks спустя две недели после очистки и увеличения лимита в папке стало 354 PF-файла. Что превышает стандартный предел в его Windows 10, но далеко от 512 в Windows 11.

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

😎 Коммунальные услуги теперь и в вашем SSD

Говорят, пока только для москвичей ;)

Наверняка в оригинале - utilities. Основное значение слова - организации, осуществляющие поставку газа, воды и электричества потребителям. А не вот этих ваших утилит :)

Спасибо dartraiden и ԤИОНЕР за очередной #автоперевод ✌️

🌐 О приоритете записей в файле hosts

В чате обсуждали использование файла hosts с целью запретить приложению подключение к своим адресам. Речь зашла о возможных дубликатах записей. Один опытный участник заявил:

hosts читается сверху вниз и будет использован последний дубликат

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

Я поинтересовался у автора заявления, как бы он его проверял. Тот предложил вписать в файл две строчки и пропинговать.

127.0.0.1 ya.ru
127.0.0.2 ya.ru

Я бы тоже так делал! И вот результат:

gc "C:\Windows\System32\drivers\etc\hosts" -Tail 2; ping ya.ru
127.0.0.1 ya.ru
127.0.0.2 ya.ru

Pinging ya.ru [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

👉 Получается, что Windows использует первый адрес. И Linux тоже!

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

📄 Несколько человек поднимали вопрос о влиянии кэша DNS. Однако в соответствии с одной из старейших актуальных статей базы знаний Microsoft, Microsoft TCP/IP Host Name Resolution Order, клиент Windows смотрит в локальный файл hosts прежде чем опрашивать серверы DNS. Кэш DNS в статье явно не упомянут, но это производная от серверов.

Сторонние же программы могут применять свой алгоритм чтения файла hosts либо вообще игнорировать его. Например, разработчикам Firefox пришлось реализовывать свой парсер hosts, чтобы он не игнорировался при использовании встроенного в браузер резолвера DoH (спасибо, dartraiden). А в Linux всегда найдется какой-нибудь дистрибутив с альтернативной реализацией 🐧

Я сам когда-то думал, что выигрывает последняя запись. Пока не столкнулся с этим по работе. У тестовых серверов поменялись IP-адреса, и я добавил новые записи в конец файла hosts. Однако рабочее приложение не смогло подключиться по доменному имени. Так и узнал ✌️

🚀 Ускорение загрузки файлов в PowerShell

Недавно я перепроверял давно опубликованный в блоге скрипт для скачивания файла с помощью #PowerShell, и слишком уж долго шла загрузка. Хочу поделиться решениями.

1️⃣ Отключение прогресса

$ProgressPreference = 'SilentlyContinue'

В принципе, эта переменная может слегка ускорить процесс и снизить нагрузку на ЦП не только при скачивании файлов. Но конкретно для командлета Invoke-WebRequest (псевдоним iwr) разница значительная! Один и тот же файл размером 175 мегабайт без прогресса у меня на разных системах скачивался от 16 до 42 секунд, а с прогрессом - от 3 до 13 минут! 🤔

У этого командлета проблема наблюдается только в Windows PowerShell 5.1, но не в PowerShell Core. Я писал об этом в канале 7 лет назад :) И недавно краем глаза где-то видел, что якобы в 5.1 уже починили. Мои тесты это не подтверждают.

2️⃣ Подстановка юзер-агента
На самом деле даже без прогресса у меня Invoke-WebRequest качал слишком долго. Я предположил, что сайт специально притормаживает отдачу, и решил прикинуться браузером.

-UserAgent "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

После этого скорость окончательно наладилась!

3️⃣ Загрузка с помощью BITS
В Windows помимо командлетов Invoke-WebRequest и Invoke-RestMethod также можно скачивать файлы с помощью Start-BitsTransfer. Этот командлет запускает джоб с помощью службы BITS (фоновая интеллектуальная служба передачи данных). Именно ее использует центр обновления Windows.

Это не совсем про ускорение, а про альтернативы. Но в моем случае был сайт Microsoft, и родную BITS он не тормозил в отличие от iwr без юзер-агента.

////

▶️ Скрипт для экспериментов:

$file = "$env:temp\mpam-fe.exe"
$uri = 'https://go.microsoft.com/fwlink/?LinkID=121721&arch=x64'
$u = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'
$ProgressPreference = 'SilentlyContinue'

Measure-Command {
    Invoke-WebRequest -Uri $uri -OutFile $file -UserAgent $u
}
Measure-Command {
    Start-BitsTransfer -Source $uri -Destination $file 
    }

Скрипт скачивает актуальный файл сигнатур защитника Windows с этой страницы. Но учтите, что для обновления сигнатур из консоли есть методы получше ✌️

🔍 Расследование: кто перезагрузил Windows

В чате участник A S. сообщил, что в Windows 11 политика NoAutoRebootWithLoggedOnUsers не предотвращает перезагрузку после установки обновлений. Статью про это я написал в 2018 году и с тех пор не перепроверял. Причем 4 года спустя эту политику наряду с другими объявили устаревшей и не поддерживаемой в Windows 11. И пообещали в будущем выпилить.

У ТС все подробности свелись к "отхожу на несколько часов". Обычно, так быстро сразу после установки обновлений перезагрузка не происходит. Стандартно - в 3 часа ночи, но дальше может в любой момент вне активных часов 🕒

Проще проверить всё самому, и я зарядил виртуалку. За несколько часов ничего не произошло, как и с утра. Однако ночью я сплю, и моя основная ОС тоже, т.е. ВМ в ней неактивны. Поэтому наутро я изменил часовой пояс ВМ и продолжил тест.

👉 Перезагрузка произошла! Но чтобы обвинить в ней обновление Windows, надо ответить на второй по важности вопрос всех времен и народов: какие ваши доказательства?

Они собраны в журнале событий, поэтому пост публикуется в рубрике "Гадание по логам" с помощью #PowerShell.

1️⃣ Смотрим время загрузки ОС - сразу после 3 часов ночи. Уже горячо!

(Get-CimInstance Win32_OperatingSystem).LastBootUpTime

Sunday, February 2, 2025 3:01:46 AM

2️⃣ Выясняем, какие процессы это вызвали - событие 1074 в журнале Система:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074} | 
Select-Object TimeCreated, Message | Format-List

TimeCreated : 2/2/2025 3:00:03 AM
Message     : 
The process C:\WINDOWS\uus\AMD64\MoUsoCoreWorker.exe (DESKTOP-GQKOJ6B) 
has initiated the restart of computer DESKTOP-GQKOJ6B on behalf of 
user NT AUTHORITY\SYSTEM for the following reason: 
Operating System: Service pack (Planned) 
Reason Code: 0x80020010 
Shutdown Type: restart.

3️⃣ Проверяем связь с планировщиком - поиском по части имени файла MoUsoCoreWorker. Время совпадает!

Get-ScheduledTask | where TaskName -match 'Uso' | Get-ScheduledTaskInfo

LastRunTime        : 2/2/2025 3:00:05 AM
LastTaskResult     : 2147942402
NextRunTime        : 2/3/2025 10:48:35 PM
NumberOfMissedRuns : 0
TaskName           : USO_UxBroker
TaskPath           : \Microsoft\Windows\UpdateOrchestrator\

4️⃣ Но это еще не всё! Надо определить, был ли в это время выполнен вход пользователя в систему. Ведь политика должна предотвращать перезагрузку только в этом случае.

Здесь фильтруем события входа и выхода, затем ищем нужные по части SID - 1001 в конце у администраторов.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4634,4647} | 
where message -match '1001' | Select-Object Id, TimeCreated, Message -First 15 | 
ft -AutoSize

  Id TimeCreated          Message
  -- -----------          -------
4634 2/2/2025 3:20:10 AM  An account was logged off....
4624 2/2/2025 3:03:05 AM  An account was successfully logged on....
4647 2/2/2025 3:00:05 AM  User initiated logoff:...
4624 2/1/2025 11:33:32 PM An account was successfully logged on....

Событие 4647! Выход четко совпадает по времени с выполнением запланированного задания оркестратора. Указано, что пользователь инициировал выход, но это издержки регистрации в журналах. По факту он стал неактивен, не отреагировал вовремя на уведомление о перезагрузке, и его выход форсировали.

////

☑️ Итак, мы однозначно определили, что перезагрузку выполнил оркестратор обновлений, проигнорировав групповую политику и завершив пользовательский сеанс.

В Windows 10 политика NoAutoRebootWithLoggedOnUsers продолжает выполнять свою функцию. А в Windows 11 уже нет поддерживаемого способа предотвратить форсированный перезапуск после установки обновлений. Единственный обходной путь - ручное планирование перезагрузки, что позволяет отложить ее максимум на неделю ✌️

🆘 О самостоятельной техподдержке в организации

Однажды в пятницу вечером мне написала коллега. Она уже полностью отчаялась решить проблему - её виртуальный десктоп Windows 365 завис при входе.

🤖 Сначала она долго пробивалась через чат-бота поддержки. Он сыпал бесполезными советами и отказывался звать человека.

Кожаные мешки в итоге оказались не лучше. Первый создал базовый инцидент, но уже второй закрыл его - якобы, вместо инцидента надо было создавать запрос (на самом деле - нет). Сам его создал, но повесил на неправильную группу. Та с лёгким сердцем его и закрыла 🤦‍♂️ Вообще, попадание тикета в нужные руки - это одна из нерешённых пока глобальных проблем человечества :)

Всё это происходило небыстро, и девушка пыталась повлиять на процесс с помощью своего менеджера. Тот сказал обращаться в поддержку.

Так прошло две недели 😱

У меня было два простых совета.

1️⃣ Создавать инциденты самостоятельно с помощью формы на портале, нежели через чат с ботом и затем с первой линией поддержки. Экономия времени значительная! Заодно в тикет идёт изложенная своими словами проблема, а не в пересказе туговатового сотрудника техподдержки, нанятого за 2 песо. Об этом написано в руководстве для сотрудников проекта, но кто ж его читает.

2️⃣ Перезагрузить виртуальный десктоп. Неважно, установлена Windows на физическом железе или на виртуальной машине - живительный ребут никто не отменял! Кстати, недавно случайно узнал, что некоторые коллеги не понимали значение слова reboot - слишком технический термин 🤷‍♂️

Но тут был интересный нюанс: как перезагрузить Windows, когда она висит на входе, а кнопки питания нет нигде? 🤔 Более того, эти десктопы в принципе настроены так, что из графического интерфейса Windows убраны все опции перезагрузки и выключения. И даже консольные блокируются за исключением одного - в PowerShell от администратора Restart-Computer. Но права админа просто так не дают.

👉 Однако облачные десктопы зачастую можно перезагрузить "снаружи". В данном случае нужно зайти на windows365.microsoft.com с аккаунтом организации. А там есть перезагрузка, откат к снимку системы и сброс. Это тоже было описано во внутреннем руководстве, кстати.

///

Вскорости после разговора коллега сообщила, что перезагрузка десктопа помогла, хотя и не сразу. Я не стал уточнять, что означала эта оговорка. Можно считать и сразу, когда за полчаса решаешь вопрос, с которым мучилась две недели ✅

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

⚙️ Как удалить ассоциацию программы с типом файлов

В чате Zubastic задал этот вопрос в контексте файлов без расширения - некая программа предательски захватила ассоциацию с ними.

Вариантов регистрации много. Самый простой и работающий с незапамятных времен - программа прописывает себя в разделе HKCR\ProgramName, в том числе команду на запуск в разделе HKCR\ProgramName\shell\open\command. А для каждого расширения вносит указатель на этот раздел в HKCR\.ext, где ext - расширение.

ℹ️ В случае с файлами без расширения - раздел будет HKCR\.. По умолчанию он отсутствует. Более того, Windows не позволяет вам создать его путем "Открыть с помощью": для файлов без расширений нет опции всегда открывать этой программой! Однако вот пример связи таких файлов с блокнотом по описанной выше схеме старыми добрыми командами assoc и ftype.

assoc .=NoExtFile
ftype NoExtFile="notepad.exe" "%1"

В нашем случае автор вопроса в безуспешных попытках решить проблему удалил раздел HKCR\., тем самым уничтожив указатель на программу. А назвать свой подраздел в HKCR она могла как угодно. С помощью Process Monitor мы определили конкретное название раздела - HKCR\PhotonWorkShop. После его удаления проблема решилась ☑️

Но заодно создалась другая. Она не волновала ТС, хотя это скорее исключение. Теперь даже легитимно связанные с программой типы файлов в ней не откроются, потому что их расширения в реестре ссылаются на отсутствующий раздел. Кроме того, остался нераскрытым вопрос, почему даже после удаления раздела HKCR\. файлы без расширения продолжали открываться в этой программе 🤷‍♂️

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

Пользовательская регистрация расширений прописана в разделе
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\

Для каждого расширения там есть подразделы:
• OpenWithList - список программ в "Открыть с помощью"
• OpenWithProgids - список зарегистрированных программ или отсылка к типу файлов в HKCR
• UserChoice - текущая программа по умолчанию, выбранная пользователем (при наличии - преобладает над подразделами выше)

✅ Отсюда следует решение вынесенного в заголовок вопроса.

🔹 Если вы желаете сменить одну зарегистрированную программу на другую, не нужно лезть в реестр. Это можно сделать из диалога "Открыть с помощью" (за исключением файлов без расширений).

🔹 Если вы хотите удалить пользовательские ассоциации и убрать указатели на них в "Открыть с помощью", зачищайте подразделы OpenWithProgids и OpenWithList в HKCU. В этом случае при открытии файла будут отображаться системные ассоциации ↓

🔹 Если требуется удалить системную связь программы с расширением, анализируйте раздел HKCR\.ext. Там тоже могут быть подразделы OpenWithProgids и OpenWithList. Универсального рецепта здесь нет ввиду различных способов регистрации.

У проблемной программы был еще один нюанс. После своего обновления она восстанавливала ассоциации файлов. В таком случае придется регулярно зачищать их скриптом. Альтернатива - отобрать разрешения на пользовательский раздел реестра по такой же схеме как с нежелательным значком OneDrive в панели навигации проводника ✌️

😎 Сегодня у меня для вас рекомендации по автообрастаниям и автосхрюнку (или автохрюнку, это неточно :)

И не отрежьте там себе ничего автосхромкой! 🪚

Microsoft прогрессирует - переходит от ручного ухуренивания к автоухрюнку.

Этот #автоперевод документации SQL Server прислал Romchik Alekseev ✌️

▶️ Простой и эффективный поиск текста в PowerShell - Select-String

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

Как правило, люди открывают Notepad++, загружают туда пачку логов и выполняют поиск во всех открытых файлах. На предложение использовать скрипт пожимают плечами - мол, это же разовая задача. И так сойдет 👌

У этого подхода много проблем:
1. Медленно.
2. Не выгружается сводка и найденные данные.
3. При большом количестве / размере файлов это работает плохо или вообще никак.

Да и не разовая это у них задача, поэтому скрипт подходит отлично.

👉 В #PowerShell для этой цели есть командлет Select-String. Он умеет искать простое совпадение или регулярное выражение.

Select-String -Path 'C:\logs\*.log*' -Pattern '0x800f0805' -SimpleMatch
Select-String -Path 'C:\logs\*.log*' -Pattern '0x800f0805|0x80070490'

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

🤖 Чат-боту задача по поиску текста ставится общими словами. Например, найди все строки с 'exception ' в этих файлах, посчитай количество на каждый файл, запиши в файл эту строку и 20 следующих, выведи на экран сводку и т.д.

И бот быстро пишет рабочий скрипт. Только он зачастую использует другой командлет - Get-Content и передает весь массив на поиск командлету Where-Object. А для такой задачи это неэффективно - слишком медленно!

Простое сравнение. Ищем ошибку '0x800f0805' десяти файлах cbs.log общим объемом около 1.2GB.

$logpath = "C:\temp\logs\*cbs*.log"
Measure-Command {
    $a = Select-String -Path $logpath -Pattern '0x800f0805' -SimpleMatch
}
$a.count
Measure-Command {
    $b = Get-Content -Path $logpath | where $_ -match '0x800f0805'
}
$b.count

У меня Select-String справился за 7.5 секунд, а Get-Content | where понадобилось 4 мин и 40 секунд.

💡 И кстати по поводу контекста, у Select-String есть очень полезный параметр -Context, который выводит строки до и после найденного совпадения.

Select-String -Path $logpath -Pattern 'exception ' -SimpleMatch -Context 2,20

////

В общем, если вам нужно дальше работать с чистыми найденными строками в качестве объектов, Get-Content имеет смысл. Но просто для поиска текста Select-String вполне достаточно. И да, можно сказать чат-боту, чтобы применял конкретный командлет!

🍪 Бонус - #классика канала про мониторинг логов в реальном времени при помощи:
• командлета PowerShell
• утилиты CMTrace

⚙ Об изменениях в создании локальной учётной записи при установке Windows

В конце прошлой недели всплыли две новости.

1️⃣ Файл bypassnro.cmd выпилят из дистрибутива 25H2. Сам метод пока работать не перестанет, но вместо одной короткой команды для запуска файла придётся вводить две, которые в нём содержались. Это внесение изменений в реестр и перезагрузка.

2️⃣ Нашлась другая короткая команда, которая открывает диалог создания локальной учётной записи.

На первом экране OOBE нажмите Shift+F10, ткните в окно командной строки и введите:

start ms-cxh:localonly

Предположу, что это выпилят довольно быстро - может не дожить до 25H2. И напомню, что все это время неизменно рабочим способом остаётся файл ответов. Его можно применять:

🔹 с первого этапа установки
🔹 для автоматизации этапа OOBE

Учите матчасть ✌