• «Memory Remapping»;
• «DRAM Over 4G Remapping»;
• «H/W DRAM Over 4GB Remapping»;
• «H/W Memory Hole Remapping»;
• «Hardware Memory Hole»;
• «Memory Hole Remapping»;
• «Memory Remap Feature».

Параметры нужно включить – как правило, достаточно переместить соответствующую опцию в положение «On» или «Enabled».

Нажмите F10 для сохранения изменений и загрузите компьютер.

Если вы не можете найти подходящие пункты, не исключено, что производитель заблокировал такую возможность на вашей модели «материнки». В этом случае поможет либо прошивка новой версии микропрограммы, либо замена системной платы.

Способ 4: Уменьшение памяти, используемой встроенной видеокартой

Пользователи ПК или ноутбуков без дискретной видеокарты часто сталкиваются с рассматриваемой проблемой, поскольку встроенные в процессор решения пользуются «оперативкой». Часть из неё закреплена за интегрированной графикой, причём объём задействованной ОЗУ можно изменить. Делается это следующим образом:

Войдите в БИОС (шаг 1 предыдущего способа) и переключитесь на вкладку «Advanced» или же любую, где фигурирует этот термин. Далее найдите пункты, которые отвечают за работу графической подсистемы. Они могут называться «UMA Buffer Size», «Internal GPU Buffer», «iGPU Shared Memory» и в таком роде. Обычно шаги объёма фиксированы и опустить его ниже определённого порога не получится, поэтому выставьте минимально возможное значение.

В оболочке UEFI ищите разделы «Дополнительно», «System Configuration» а также просто «Memory».

Далее откройте разделы «Конфигурация системного агента», «Расширенные настройки памяти», «Integrated Graphics Configuration» либо подобное, и задайте требуемый объём по аналогии с текстовым БИОС.

Аппаратные неисправности – одна из самых редких причин описываемой проблемы, однако и самая неприятная из возможных.

Заключение

Таким образом, мы рассказали, почему в Виндовс 10 появляется сообщение о том, что используется не вся оперативная память, а также предложили варианты устранения этой ошибки.

Оперативная память больше 4 ГБ в 32-разрядных пользовательских версиях Windows

Здравствуйте уважаемые читатели блога www.ithabits.ru. Предлагаю вашему вниманию заключительную часть цикла статей о “приключениях” большой оперативной памяти в 32-битных системах.

Коротко повторю выводы, которые были сделаны в предыдущих публикациях этой темы:

Для приложений (программ) работа системы в режиме PAE не эквивалентна переходу на x64, так как они по-прежнему имеют доступ только к 4 ГБ виртуальной памяти (Часть 1).

Сегодня мы протестируем способность Windows 7 x86 работать с оперативной памятью больше 4 ГБ.

Наверное, можно было бы не делать отдельный пост и закончить все в прошлый раз, но очень не хотелось смешивать между собой варианты “= 4 ГБ” и “> 4 ГБ”. Во-первых, 4 ГБ является официально заявленным Microsoft лимитом физической памяти для клиентских версий. Во-вторых, очень важно было разобраться с адресным пространством в этом диапазоне и понять, что тут не так. А именно, почему 4 ГБ на самом деле не поддерживаются.

Причины, которые могут мешать переходу на 64-разрядные версии Windows

Стоит ли вообще пытаться сегодня заставить 32-разрядный Windows работать с оперативной памятью более отмеренных ей Microsoft 4 гигабайт? Не проще сразу перейти на 64-разрядную версию и обо всем забыть?

На моем основном компьютере установлена Windows 7 x64. Системой я полностью доволен, ну или почти всем доволен. Из раздела недовольств:

Отсутствие непосредственной поддержки унаследованного оборудования

У меня есть МФУ Canon LaserBase MF3110, которое, дай бог ему здоровья, до сих пор исправно выполняет свои функции. Однако, печатать на него напрямую из 64-битной Windows я не могу из-за банального отсутствия соответствующих 64-разрядных драйверов. Думаю, что их не будет уже никогда.

Точно такая же ситуация, даже еще хуже, со сканером Hewlett-Packard.

Чуть позднее я обязательно расскажу как можно выйти из положения с помощью виртуализации. Ну не выкидывать же в самом деле по причине отсутствия драйверов исправно работающее, пусть и не новое, оборудование.

Сегодня унаследованное оборудование является одной из причин, которая все еще тормозит переход на 64-битные операционные системы.

То обстоятельство, что по сравнению с x32 системы x64 занимают чуть больше места на диске и в памяти, вряд ли можно считать серьезным минусом, хотя об этом и любят упоминать. Зато они работают быстрее за счет более полного использования возможностей процессора.

Финансовые затраты при смене версии Windows

Еще одна причина, которая может помешать переходу на x64 тем, кто пока еще использует 32-битные версии Windows, является финансово-организационной. Возможно, она даже более веская, чем унаследованное оборудование.

Предположим, что некоторое время назад вы купили в магазине компьютер с предустановленной 32-разрядной версией Windows, а спустя некоторое время, по той или иной причине, приняли решение перейти на 64-разрядную. Очень хорошо, но как реально осуществить это решение?

Допустим, что вас совершенно не пугает процесс перестановки системы «с нуля” с сопутствующими ему и, надо сказать, не всегда удачными, переносом данных и программ.

Цена Windows x64 не отличается от Windows x86, но где ее официально взять и не платить при этом дополнительные деньги? Если честно, то я не знаю. Если кто-то знает, поделитесь. Могу предположить, что легитимное решение проходит все же через магазин. Если при этом учесть, что официально ОЕМ версии Windows поставляются только с новыми компьютерами и выбирать придется из более дорогих коробочных вариантов, то желание немедленно осуществить задуманный переход на x64 может заметно поостыть.

Хорошо совмещать переход на x64 со сменой компьютера, но она происходит не так уж часто.

Тестирование работы Windows 7 x86 с ядром, поддерживающим до 128 ГБ оперативной памяти

Сегодня в качестве тестовой лаборатории будет выступать настольный компьютер с процессором I7 и 6 ГБ оперативной памяти.

Так как система x64 в контексте темы нам не товарищ, а виртуальная машина также не спасет в силу того, что ей не получится отдать больше 4 ГБ памяти, придется специально установить 32-разрядную Windows. Давно хотелось протестировать возможность загрузки операционной системы с виртуального диска. Вот, как раз, очень подходящий случай эту возможность опробовать.

Процесс инсталляции “Windows 7 x86 Корпоративная” на виртуальный диск оказался не очень сложным. Единственное, что не получилось сделать в системе, работающей с виртуального диска, так это определить индекс производительности – начинает мерить, потом говорит, что не может закончить оценку производительности дисковой системы. Жаль, но нам сейчас это не актуально.

P.S. Появилась статья с подробным описанием вариантов установки Windows 8.1 на виртуальный диск.

Использование физической памяти Windows 7 x86 с исходным ядром

Частично повторим то, что делали при исследовании 32-разрядной Windows 7 с 4 ГБ физической памяти >

Здесь все достаточно ожидаемо. Из 6 ГБ доступно 3,24 ГБ, что составляет всего 54% от установленной физической памяти. Потери складываются из 4 – 3,24 = 0,76 ГБ на адреса устройств и 2 ГБ, обрезанных выше 4 ГБ.

А вот “Монитор ресурсов” говорит, что под оборудование зарезервировано 2,8 ГБ, но мы этому, естественно, не поверим и запустим утилиту MemInfo:

Использование физической памяти Windows 7 x86 с ядром ntkr128g.exe

Теперь еще раз совершим противоправные действия против Microsoft во имя науки и уберем в ядре операционной системы 4 гигабайтное ограничение. В силу того, что в результате наших экспериментов с ноутбуком у меня уже есть готовое “исправленное” ядро, я не буду больше запускать патчер, а просто скопирую его в новую систему и подключу в загрузке. Для этого нужно сделать следующее:

• Копируем нужное нам ядро “ntkr128g.exe” в папку C:\Windows\System32;
• Запускаем в командной строке с правами администратора bcdedit.exe без параметров и находим секцию, которая отвечает за загрузку системы с виртуального жёсткого диска (эту секцию я прописал на предыдущем шаге, когда настраивал загрузку Windows 7 с VHD). В моем случае из основной 64-разрядной системы это будет выглядеть так >

Если загрузить систему с VHD и проделать то же самое, то мы увидим аналогичную картину, но только пути всех “device” поменяются. То, что описано ниже, можно делать из любой системы;

• Во избежание ошибки запускаем “Блокнот”, копируем в него содержимое экрана через буфер обмена (экран командной строки –> правая кнопка мыши –> “Выделить все” –> “Enter” –> “Блокнот” –> “Правка/Вставить”) и сохраняем в произвольный текстовый файл. Собственно говоря, нас интересует “Идентификатор”.
• Создаем новую загрузочную запись путем копирования найденной и даем новое имя этому варианту. Используем теперь сохраненное в блокноте в обратную сторону для удобства подстановки идентификатора:

bcdedit /copy <5c2a7c3c-a04e-11de-9dac-b90d3342b585>/d «Windows 7 VHD 128» — естественно, в вашем варианте идентификатор будет совершенно другим.

Запустим еще раз bcdedit без параметра и убедимся, что новая запись появилась. Пока она ничем кроме имени не отличается от исходной.

• Новую запись надо дополнить:

bcdedit /set <5c2a7c3c-a04e-11de-9dac-b90d3342b585>kernel ntkr128g.exe – указываем, какое ядро нужно грузить;

bcdedit /set <5c2a7c3c-a04e-11de-9dac-b90d3342b585>testsigning Yes – в связи с тем, что контрольная сумма ядра у нас изменилась, говорим, что работаем в тестовом режиме;

bcdedit /set <5c2a7c3c-a04e-11de-9dac-b90d3342b585>pae ForceEnable – на всякий случай;

Смотрим, что получилось >

Запускаем новую систему и смотрим результат >

Судя по тому, что говорит о себе система, она теперь работает со всеми 6 ГБ физической памяти.

“Монитор ресурсов” сообщает, что под оборудование практически ничего не зарезервировано. Как мы теперь хорошо понимаем, на самом деле зарезервированы все те же 0,76 ГБ адресного пространства, но оно теперь не вычитается из установленного объема памяти (надо будет при случае посмотреть, как это место звучит в оригинале на английском языке. Возможно это “трудности перевода”).

Смотрим диапазоны зарегистрированной в системе памяти >

Как и ожидалось, добавился новый большой диапазон памяти выше 4 ГБ.

Сравнительное тестирование работы Windows 7 x86 с ядром ntkr128g.exe

Для того, чтобы развеять последние сомнения и подвести окончательный итог наших изысканий, запустим что-нибудь требующее много оперативной памяти. Самое первое, что приходит на ум, это виртуальные машины в VirtualBox. У меня уже есть несколько готовых виртуальных машин, созданных в основной рабочей системе с Windows 7 x64.

Наша тестовая система с Windows 7 x86 хоть и работает с виртуального диска, но ничего общего, кроме диска VHD, с виртуальной машиной не имеет. Она прекрасно видит все физические диски, которые установлены в моем компьютере, благодаря чему подключить готовые виртуальные машины в VirtualBox не составляет труда. Естественно, в новой Windows 7 x86 предварительно надо установить сам VirtualBox.

Назначим каждой виртуальной машине, скажем, по 1 ГБ памяти и начнем запускать их по очереди, сначала в исходной системе, которая видит лишь 3,24 ГБ, а затем в “скорректированной”.

В исходной системе удалось стартовать четырем виртуальным машинам, однако, как видно из представленного фрагмента экрана, на этом все и закончилось – “Unable to allocate and lock memory… Please close applications to free up memory…”. Виртуальные машины ни на что не реагировали и выключать их пришлось аварийно.

А теперь повторим наш экстремальный эксперимент в “скорректированной” Windows 7 x86 >

Как видно из представленного фрагмента экрана, запущены четыре виртуальные машины Linux, которым отведено по 1 ГБ памяти, и одна Windows XP с 512 МБ ОЗУ.

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

Стоит ли использовать Windows 7 x86 с модифицированным ядром (с поддержкой до 128 ГБ оперативной памяти)

Рекомендовать со страниц блога использовать рассмотренный вариант увеличения доступной физической памяти для 32-разрядных пользовательских версий Windows я, естественно, не могу и не буду. Тому есть две веские причины:

1. Нарушение лицензионного соглашения с Microsoft, причем как бы не в трех местах, а мы ничего нарушать не хотим. Конечно, при желании можно найти несколько смягчающих вину обстоятельств. Например, таких как, то, что стоимость однотипных версий Windows разной разрядности одинакова и своими действиями мы не наносим финансового вреда Microsoft. Или то, что при установке в компьютере памяти размером 4 ГБ надо еще посмотреть, кто кому и что должен – в лицензии поддержка такого объема заявлена, но, как мы теперь знаем, на самом деле ее нет. Но, все же, нарушение оно нарушение и есть. Будем считать, что все, что мы делали, было временным и на благо науки ;
2. Нет никакой гарантии, что в вашем компьютере не используются устройства с “глупыми” драйверами, работа которых в режиме PAE с адресами физической памяти выше 4 ГБ приведет к краху системы.

Видимо придется закончить наше обсуждение секретов большой памяти в 32-битных операционных системах банальной рекомендацией – если планируете увеличить оперативную память компьютера до 4-х и более ГБ, или собираетесь приобрести новый компьютер с таким объемом памяти, задумайтесь о переходе на 64-разрядную операционную систему.

Ну если уж с x64 отношения не складываются категорически – читайте все еще раз внимательнее.