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

Только штатные механизмы Windows
🍒 Скрипт работает только со штатными инструментами. И написан на встроенном в Windows языке PowerShell (95% кода). А точнее это PowerShell-программа, упакованная в CMD-оболочку.
Изменения выполняет сама Windows через свои же штатные механизмы. Например, управление Turbo/Boost выполняется через штатный Power API активного плана питания, а не прямой правкой скрытых ключей реестра.
Под каждым пунктом дано простое пояснение на русском: за что отвечает настройка и какую цифру лучше выбрать для игр, работы или слабого ПК.
Если пользователь ранее запускал сомнительные программы для "ускорения ПК", они могли прописать в реестр устаревшие ключи. Скрипт автоматически находит этот мусор, помечает и безопасно стирает его.

Скрипт не использует никаких сторонних утилит, служб или скрытых исполняемых файлов. Скрипт не трогает системные файлы (DLL, EXE) и не меняет права доступа (ACL/Permissions). Любое значение можно вернуть обратно через этот же скрипт или стандартными средствами.
Скрипт ничего не делает втайне от пользователя, это открытый код без вирусов и скрытых программ. Это обычный текстовый файл, код которого можно открыть в "Блокноте", прочитать каждую строчку и убедиться, что там нет вредоносных закладок, майнеров или сторонней рекламы.
Программа не устанавливает драйверы, службы, фильтры, DLL и другие постоянно работающие компоненты, не модифицирует системные файлы и не использует собственный "движок оптимизации".
Скрипт сам ничего не меняет без вашего разрешения, сначала только аудит состояний параметров.
Скрипт вносит изменения физически и в реальном времени.

Основной язык логики: PowerShell с прямым использованием платформы .NET (с прямым вызовом классов .NET);
Язык запуска (обертка): Windows Batch / CMD;

Запуск
Скрипт запускается с небольшой задержкой, потому что определяет ваше оборудование. Это нужно для правильной отработки по разделу "Безопасность".
Обертка в формат .cmd позволяет обойти ограничения: скрипт запускается обычным двойным кликом мыши, сам повышает свои права до администратора и исполняет безопасный код PowerShell без изменения глобальных настроек безопасности Windows.
Перезагрузка ОС после применения параметров скрипта - обязательна почти во всех случаях.

Сохранение и восстановление
Перед изменениями программа создаёт снимок состояния всех параметров, которыми она управляет.
Для резервного снимка нам не обязательно знать физическое место, где Windows хранит каждую настройку. Потому что мы можем сохранить состояние каждого параметра на уровне его официального интерфейса и потом восстановить его через тот же интерфейс.
Есть:
- сохранение текущего состояния;
- восстановление выбранного сохранения;
- откат изменений текущей сессии.
Поэтому программу удобно использовать не только для настройки, но и для тестирования отдельных твиков.

Базовые и расширенные настройки
Базовые параметры — относительно хорошо известные механизмы Windows: Memory Compression, Page Combining, файл подкачки, TRIM, длинные пути, NTFS, дампы памяти и т. п.
Расширенные параметры — настройки вроде Win32PrioritySeparation, SystemResponsiveness, DisablePagingExecutive, дополнительных рабочих потоков и BCD-таймеров. Многие из них существуют давно, но слабо представлены в обычном интерфейсе Windows и часто окружены устаревшими советами. Поэтому программа не просто предоставляет доступ к ним, а ограничивает ввод известными значениями и отделяет документированные режимы от экспериментальных рекомендаций сообщества.

Программа для всех
Для быстрого применения предусмотрен единый игровой профиль с заранее выбранным набором параметров.
При этом любой параметр можно открыть отдельно, посмотреть его состояние, назначение, допустимые значения и изменить вручную. Таким образом, новичку не нужно разбираться в десятках системных команд, а опытный пользователь не ограничен кнопкой [Оптимизировать].

Открытый код и проверка сборки
Основной файл программы распространяется бесплатно с открытым исходным кодом по лицензии MPL 2.0. Закрытый авторский комплект и ключ официальной подписи в публичную поставку не входят. Рекламы нет.
CMD-файл можно открыть в обычном текстовом редакторе и проверить его содержимое.
При запуске программа проверяет подпись и целостность файла по протоколу BMIO-SIGN/1. Так определяется, относится ли сборка к официальным выпускам. Изменённые версии открытого кода могут работать, но официальными не считаются и получают соответствующую отметку.
Опытный программист может удалить проверку и подделать подпись, но либо получит форк, либо всегда будет отставать от официальных сборок по изменениям.

Совместимость
Поддерживаются:
Intel / AMD
Windows 11 x64 24H2 и новее
Windows 10 x64 22H2 build 19045 и новее — в режиме совместимости.
Старые версии Windows, Windows Server и 32-разрядные системы не поддерживаются.

В самом ЦП есть специальные режимы и инструкции, которые позволяют создавать [закрытые зоны] памяти. Далее я объясню, как они рождаются и какие параметры этим управляют.
Сначала определения.

Микрокод. В файле прошивки UEFI/BIOS лежит не только код для старта МП, но и пакеты микрокода (микро-программа) для разных процессоров. При каждом включении ПК блок микрокода попадает в ЦП [в сверхбыструю статическую память SRAM (Ucode RAM)] через регистры MSR. Часть МП при отсутствии/повреждении микрокод-блока в UEFI откажется проходить POST - для пользователя это выглядит как "кирпич". Но это решение прошивки, а не предел процессора: сам ЦП на заводском Mask ROM-микрокоде исполняет весь набор инструкций x86 и способен загрузить ОС [например, Linux с параметром ядра dis_ucode_ldr (запрет OS-загрузки микрокода) грузится и работает]. Патч из BIOS - это исправления ошибок и уязвимостей поверх полного заводского микрокода, а не недостающая для работы часть.
Патч микрокода загружается в ЦП каждый раз при включении ПК [потому что встраивание энергонезависимой памяти (embedded Flash) это экономически и технически невыгодно: ухудшает выход годных кристаллов и снижает максимальные частоты соседней логики].
Причем загрузка двухступенчатая: сначала патч применяет прошивка UEFI (еще до reset-вектора, через таблицу FIT, либо в ранней фазе POST), а затем ОС при загрузке накатывает свою копию поверх - но только если ее ревизия новее (Windows: mcupdate_GenuineIntel.dll и mcupdate_AuthenticAMD.dll для AMD, обновляется через Windows Update). Действует всегда более новая ревизия.
Микрокод исправляет аппаратные ошибки, меняет логику инструкций, таблицы вольтажей/частот (V/F curve, CEP, TVB) и алгоритмы безопасности. Именно микрокод исправляет ошибки в работе [закрытых зон] (например, закрывает уязвимости Spectre, Meltdown, Downfall, Retbleed; Inception (SRSO) — уязвимость AMD Zen, к микрокоду Intel отношения не имеет).

Meltdown / Rogue Data Cache Load: начиная с Cascade Lake / Coffee Lake Refresh (степпинг R0) и Ice Lake - исправлено аппаратно;
Spectre v2 (Branch Target Injection): аппаратный барьер eIBRS, начиная с Cascade Lake / Coffee Lake Refresh, включается ОС; полностью не закрыт - атака BHI (2022) обходит eIBRS на Alder Lake / Raptor Lake;
Downfall (Gather Data Sampling): начиная с Alder Lake / Raptor Lake / Arrow Lake - исправлено аппаратно;

Параметр SpeculativeMitigations01 как раз говорит Windows: "Используй те исправления, которые уже есть в прошивке процессора".
Если микрокод содержит критическую ошибку, процессор нельзя "окирпичить" — при снятии питания SRAM сбрасывается к фабричному Mask ROM. Вредоносное ПО не может закрепиться в процессоре на постоянной основе.

Гипервизор (Windows Hypervisor) — это в первую очередь технология создания и изоляции виртуальных машин.
UEFI передаёт управление загрузчику Windows: \EFI\Microsoft\Boot\bootmgfw.efi. Загрузчик считывает параметры BCD и вызывает hvloader.efi (Hypervisor Loader), который инициализирует Windows Hypervisor (hvix64.exe) и переводит процессор в аппаратный режим VMX Root (уровень под ядром) и отдаёт гипервизору прямой контроль над железом. Сама Windows 11 загружается в так называемом родительском разделе (Root Partition) в режиме VMX Non-Root.
Гипервизор перехватывает инструкции процессора через VM-Exit, управляет таблицами памяти EPT/SLAT и изолирует виртуальные машины (разделы/partitions) друг от друга.
Гипервизор помогает запретить выполнение непроверенного кода и не позволяет одной странице памяти одновременно быть произвольно изменяемой и исполняемой. Сам по себе гипервизор таких политик не навязывает — он лишь предоставляет механизм (таблицы SLAT/EPT). Правило [страница либо изменяемая, либо исполняемая] (Write XOR Execute) начинает действовать только тогда, когда поверх гипервизора включён HVCI.
Гипервизор это слой абстракции Windows, который запускается до того, как загрузится сама Windows. Причем hvix64.exe — это полностью автономный, самостоятельный бинарник (но часть поставки дистрибутива Windows).
Гипервизор инициализируется, когда ядра Windows (ntoskrnl.exe) ещё даже нет в оперативной памяти.
Гипервизор может работать вообще без созданных пользователем виртуальных машин.

[Hardware (Физическое железо)]
🎃[Гипервизор (Windows Hypervisor / hvix64.exe — Ring-1)]
[Слой HAL (hal.dll — Hardware Abstraction Layer)]
[Ядро Windows (ntoskrnl.exe — Kernel Mode / Ring 0)]
[Пользовательский режим (User Mode / Ring 3)]

Как самому проверить статус гипервизора
Самый надежный и быстрый способ - через конвейер и Select-Object (Через CIM, командлет Get-CimInstance обращается напрямую к репозиторию CIM (Common Information Model) и пространству имён root\cimv2 через интерфейс WMI/MI.)
True — в текущей загрузке обнаружен работающий гипервизор;
False — гипервизор не запущен. Система работает так: [Hardware] -> [HAL] -> [ntoskrnl.exe (Ring 0)] -> [User Mode (Ring 3)];
В терминале PowerShell от администратора вводим:

VBS — Virtualization‑Based Security.
VBS — это просто защищённая область. VBS — Virtualization‑Based Security, "безопасность на основе виртуализации". Это не второй гипервизор. VBS использует уже запущенный Hyper‑V и создаёт внутри Windows два уровня виртуального доверия (VTL — Virtual Trust Levels):
VTL 0: Windows 10/11 (драйверы видеокарты, службы, ядро ntoskrnl.exe).
VTL 1: Защищённая область с Secure Kernel. Доступ к такой физической памяти гипервизор наглухо блокирует через таблицы EPT. Даже если ядро VTL 0 полностью скомпрометировано (получен Ring 0), оно физически не может прочитать память VTL 1. Microsoft использует гипервизор, чтобы вынести модуль проверки целостности (skci.dll) в изолированный домен в области VTL 1, куда даже ядро с правами администратора заглянуть не может.
VBS может обслуживать не только HVCI. Например, Credential Guard помещает чувствительные данные авторизации в изолированную область.
Дополнительные потребители VBS
- VBS Key Protection — хранение криптографических ключей в изолированной среде;
- Machine Identity Isolation — защита пароля учётной записи доменного компьютера через Credential Guard;
- защищённые процессы IUM — Isolated User Mode;
- виртуальные TPM и Shielded VM в соответствующих серверных/виртуальных конфигурациях;
- дополнительные корпоративные защищённые компоненты и trustlet-процессы.

Как самому проверить состояние VBS
Команда помогает понять, используется ли работающий гипервизор системой защиты VBS. Гипервизор — базовый слой виртуализации, а VBS — один из его потребителей. Команда только отделяет VBS от остальных возможных потребителей.
В терминале PowerShell от администратора вводим:
HypervisorPresent=True, VBS=2 — гипервизор запущен, и VBS использует его;
HypervisorPresent=True, VBS=0 — гипервизор запущен, но VBS не работает. Причина может быть связана с Hyper-V, WSL2, Sandbox или другой функцией;
HypervisorPresent=False, VBS=0 — не работают ни гипервизор, ни VBS.

Аппаратная виртуализация в BIOS/UEFI Intel
[Intel VT‑x] — аппаратная поддержка виртуализации процессора; Включённый VT‑x означает только: "процессор разрешает использовать виртуализацию". Это не означает, что Hyper‑V действительно запущен. Отключение VT‑x может заодно отключить Kernel DMA Protection или повлиять на доступность VT‑d, то есть одновременно изменятся несколько условий. Microsoft прямо указывает, что аппаратная защита DMA может требовать одновременно VT‑x и VT‑d, хотя сама она не требует VBS; Можно оставить включённым;
[Intel VT‑d] — управление прямым доступом устройств к памяти через IOMMU; Для ПСП и задержки ОЗУ, VT‑d практически нейтрален, потому что IOMMU переводит адреса только для DMA-операций устройств + современные IOMMU используют собственный кэш переводов — IOTLB. VT‑d позволяет Windows ограничить участки памяти, доступные конкретному PCIe-устройству. Это защищает от DMA-атак и ошибочных обращений устройств. Windows может использовать такую защиту даже без VBS и без работающего Hyper‑V (т.е. Vt-d может быть включен при выключенном гипервизоре). Т.о. VT‑d отключать вместе с гипервизором не нужно.

Изоляция ядра (HVCI / Memory Integrity). Жесткий аппаратный механизм контроля целостности страниц памяти, реализующий принцип Write XOR Execute — память либо исполняемая, либо перезаписываемая, но никогда одновременно.
Что делает механизм:
Запрет на исполнение неподписанного кода в ядре: При включенном HVCI ядро VTL 0 лишено права самостоятельно выставлять бит исполнения в таблицах страниц.
Запрос на авторизацию: При загрузке драйвера обычное ядро (VTL 0) отправляет его на проверку в защищённую область (VTL 1), где модуль skci.dll валидирует цифровую подпись (WHQL / Microsoft).
Аппаратная блокировка: Если подпись верна, гипервизор делает память драйвера "Исполняемой, но только для чтения". Код ядра нельзя изменить на лету - любая попытка перезаписи автоматически лишает эту память права на исполнение.
HVCI не отключает обычную проверку подписей драйверов Windows, но убирает дополнительный защищённый уровень проверки через гипервизор.

Для чистого теста AIDA64 [тест кеша и памяти] целевое состояние такое
[Intel VT-d / IOMMU] Включено в UEFI;
[Intel VT‑x] Можно оставить включённым; Если после полного отключения гипервизора и перезагрузки, диагностика [D] всё равно показывает HypervisorPresent=True, то отключить VT‑x будет правильным решением;
[HypervisorPresent] False;
[VirtualizationBasedSecurityStatus] 0;
[SecurityServicesRunning] Нет;
[hypervisorlaunchtype] Off;
Существенное улучшение результатов теста AIDA64 после отключения VT‑d обычно означает, что одновременно изменилось ещё какое-то состояние системы, а не исчезла прямая задержка IOMMU.
Гораздо вероятнее влияют работающий гипервизор/VBS, частоты Ring/Cache, режим Gear, тайминги памяти, энергосбережение и фоновые процессы.

[v11, 23.08.2026]:
- Исправлены параметры Win32PrioritySeparation на релевантные;
- Встроен централизованный фильтр релевантности ручного ввода (неверные значения теперь блокируются);
- Добавил отступы между смысловыми блоками справки;

[v11.2, 24.08.2026]:
- Добавил удаление устаревших сохранений (срок 7 дней) автоматически при запуске программы; Сохранения хранятся здесь: C:\ProgramData\BaseMemIOTweaksOS\Backups\; В папке хранятся не более 3-х сохранений, независимо от даты;

[v11.3, 24.08.2026]:
- Изменен игровой профиль: Win32PrioritySeparation: 42 / 0x2A стал 38 / 0x26; DisablePagingExecutive=1 - удален; Turbo / Boost процессора = [3] Агрессивный (только для сети) - добавлен;
- Все фиксированные профили теперь сначала показывают список изменяемых параметров в формате текущее -> целевое, а потом спрашивают подтверждение; Принцип прозрачности!
- Улучшено форматирование информационных блоков;

[v11.4, 25.08.2026]:
- Расширен и переработан раздел [Безопасность и защита]
- Расширена диагностика [D], появилась возможность проверять статус гипервизора и 5 связанных с ним параметров;
- Появился номер версии на главной странице
- Оптимизирован код

[v12.2.1, 27.08.2026]. Это большая реконструкция:
- Пересмотрен список всех параметров: было 36 -> стало 31 параметр; Удалены устаревшие/сомнительные: IoPageLockLimit, SystemCacheDirtyPageThreshold, SecondLevelDataCache, ThirdLevelDataCache, WorkerThreads, IRQ8Priority, TcpWindowSize; Добавлены Game Mode и [PERFEPP]/[PERFEPP1];
- Каталог перестроен: 7 -> 6 логичных разделов, спорные настройки вынесены в расширенное меню [X]; В [X] теперь 19 параметров: разрешён принудительный ввод всех допустимых значений с предупреждением и подтверждением;
- Игровой профиль переделан: вместо 15 спорных действий — 6 проверяемых целей + безопасная проверка pagefile; Из игрового профиля исключены MMCSS, таймеры, Win32PrioritySeparation, параметры безопасности и другие неоднозначные твики;
- Настройки Boost и EPP применяются через штатный Windows Power API, только от сети; батарея не изменяется;
- Расширена совместимость с Windows 10 22H2: проверяется фактическая доступность каждого API и параметра;
- Расширена диагностика [D]: 20 проверок, VBS/HVCI/Hyper‑V, Large Pages, IOMMU и состояние загрузчика;
- Переработаны интерфейс и справка: понятная расшифровка 0/1; убрал из интерфейса команды на кириллице (Д/Н) - теперь только Yes/No латиницей; стали понятны "обратные" параметры (содержащие Disabled в названии);
- Усилена надёжность: встроенная SHA‑256, проверка синтаксиса, самопроверка профилей, резервирование и автоматический откат;

[v12.2.2, 27.08.2026]:
- изменен header (шапка) программы;

[v12.2.11, 29.08.2026]. Добавлена криптографическая проверка официального происхождения сборки:
- Сохранён прежний набор: 31 параметр, 6 категорий и 6 целей игрового профиля.
- Добавлен показ точного технического значения и понятного результата настройки.
- Исправлено описание EPP (Energy Performance Preference) — политики Windows, задающей приоритет между производительностью и энергосбережением процессора; 0 — производительность, 100 — экономия. Это условная шкала, а не процент частоты или мощности;
- Уточнены параметры с обратным смыслом и неизвестные состояния.
- Улучшено форматирование: компактное отображение значений без нарушения колонок; Шапка автоматически центрируется единым блоком; текст внутри остаётся выровненным слева; Исправлены отступы и выравнивание во всех меню и предпросмотрах профилей;
- Оформление переведено на единую CSS-подобную систему стилей;
- Добавлена проверка официальной сборки по протоколу BMIO-SIGN/1; Официальный файл защищён SHA-256 и подписью RSA-3072; Сторонние и изменённые версии запускаются как FOSS, но не признаются официальными;
- Лицензия уточнена до Mozilla Public License 2.0 (MPL-2.0);
- Обновлены аннотация, списки параметров и документ "Microsoft vs Experts";

[v12.2.12, 29.08.2026]:
- Исправлен сброс экрана после нажатия [V];
- Уточнены описания EPP и PERFBOOSTMODE=2;
- Добавлена проверка SysMain без изменения службы;
- Уточнены LongPathsEnabled, Game Mode и совместимость с Windows 10;
- Обновлены документация и официальная подпись сборки;
- Исправлено примечание диагностики гипервизора: удалено некорректное обобщение о Hyper-V/WSL2/Sandbox при BCD Off; наличие компонентов теперь явно отделено от фактического запуска гипервизора;
- Состав программы не изменён: 31 параметр и 6 целей игрового профиля.

2. NtfsDisable8dot3NameCreation отключает автоматическую генерацию коротких псевдонимов файлов в формате MS-DOS (8 символов на имя + 3 на расширение, например, DOCUMENT~1.TXT для DocumentLongName.txt).
На современных SSD в Windows 11 отключение этой функции не даёт никакого ощутимого прироста скорости в играх, работе приложений или повседневном использовании системы.
Если вы не занимаетесь регулярной сгенерированной записью миллионов мелких файлов в одну папку, этот параметр лучше оставить по умолчанию.
Можно оставить просто для диагностики состояния.

3. NtfsMemoryUsage отвечает за размер выгружаемого пула оперативной памяти (paged pool), который файловая система NTFS выделяет под свои внутренние структуры (кэш метаданных, списки просмотра lookaside lists и дескрипторы файлов).
Для игр влияние 0% (абсолютный ноль). Это не даёт никакого прироста FPS, 0.1% Low или скорости загрузки игр.
Для рабочих задач влияет при массовой работе с сотнями тысяч мелких файлов [компиляция кода, файловые серверы, гигантские репозитории Git, веб-сервер (IIS/Nginx на Windows)]. Но Если ПК уже активно использует память для других приложений или кэша, увеличение лимитов NTFS уменьшает доступную память пула для остальных процессов, что может снизить общую производительность системы.
Короче, параметр специальный, но нужный для некоторых задач. Поэтому в будущей версии я этот параметр оставлю только для служебных целей и проверки состояния.

4. LongPathsEnabled (лимит длины пути к файлу); === очень нужно для торрентов, например; Не все программы умеют сами поддерживать длинные пути. Z-Zip - умеет, а вот MS Offce 2019 - нет. Некоторые ПО полагаются на этот параметр, а некоторые тупят даже с ним. Но лучше, чтобы было ВКЛ, ибо это точно ничему не мешает.

5. NtfsDisableDeleteNotify (TRIM) *в реестре у меня нет записи; === Это нормально === Значение по умолчанию в драйвере (ntfs.sys): В Windows 10/11 поддержка TRIM включена из коробки. Если в ветке реестра HKLM\SYSTEM\CurrentControlSet\Control\FileSystem параметр NtfsDisableDeleteNotify отсутствует, драйвер файловой системы автоматически использует зашитое в него значение по умолчанию — 0 (TRIM включён). Т.е. по идее в этом параметре нет смысла. Но это не так. Выключение NtfsDisableDeleteNotify (TRIM) может быть необходимо: если вы занимаетесь восстановлением файлов (при включённом TRIM контроллер SSD очищает ссылки на удалённые блоки); если есть баг, вызывающий stuttering системы во время массовой отправки команд TRIM (отключение функции возвращает плавность работы); если есть несовместимость с RAID-контроллером; если есть виртуальная среда с динамическими дисками (Thin Provisioning), то постоянная отправка TRIM при каждом мелком файловом действии может создавать избыточные задержки (latency) на гипервизоре;
Поэтому в будущей версии я этот параметр оставлю только для служебных целей и проверки состояния.

7. AdditionalCriticalWorkerThreads увеличивает количество системных потоков ядра (Critical Kernel Worker Threads), которые обрабатывают критически важные задержки и операции ввода-вывода. Их стеки постоянно находятся в физической памяти (RAM) и не сбрасываются в файл подкачки. Этот параметр имеет смысл изменять в основном на высоконагруженных рабочих станциях, что тоже не редкость. А скрипт пишется для всех. По официальным рекомендациям Microsoft, параметр напрямую влияет на количество потоков, которые кэш файловой системы использует для операций предчтения (read-ahead) и отложенной записи (write-behind). Штатный пул потоков ядра не успевает разбирать очереди команд от драйверов контроллеров при работе с быстрыми дисковыми массивами (NVMe RAID, SAN, NAS) в условиях огромного потока асинхронных операций I/O. Нужен для нагруженных СУБД и веб-серверов (SQL Server, IIS) при обрабатывании десятков тысяч параллельных транзакций при фоновых системных вызовов через ядро ОС.
Нехватку критических потоков ядра диагностируется с помощью системного монитора (PerfMon) и утилиты Process Explorer. Необходимость увеличения AdditionalCriticalWorkerThreads подтверждается наличием очередей задач в ядре при отсутствии полного 100% насыщения процессора.
Короче, тоже кому-то все-таки нужен.