Строительство »

Windows x86 і використання пам'яті більш 4GB, так, можливо!

Продовження. початок дивіться тут

Куди зникає пам'ять в клієнтських версіях Windows x86

У минулій статті було показаноі, що всі призначені для користувача версії x86, починаючи з Windows XP SP2, не можуть використовувати фізичну пам'ять більше 4-гігабайт через встановленого в ядрі обмеження. Ми знайшли пояснення Microsoft, що це обмеження було зроблено для того, щоб уникнути нестійкої роботи драйверів пристроїв, написаних без підтримки режиму PAE (Physical Address Extension).
Зупинилися ми на тому, що обмеження 4 гігабайти оперативної пам'яті не тільки унеможливлює використання фізичної пам'яті більшого обсягу, а й, як ми скоро побачимо, призводить до проблем і в цьому діапазоні.
Перейдемо від теорії до практики і на реальному прикладі покажемо, чому на самому початку ми визначили кордон «великий пам'яті» для 32-розрядних операційних систем на рівні близько 3, а не 4 ГБ.

Подивимося, скільки пам'яті бачить windows 7, і що говорить про використання фізичної пам'яті в цьому комп'ютері сама операційна система
Подивимося, скільки пам'яті бачить windows 7, і що говорить про використання фізичної пам'яті в цьому комп'ютері сама операційна система

Така ось картина. Якщо вірити тому, що ми бачимо, а не вірити, начебто, підстав поки немає, то виходить, що 1,51 ГБ - "гроші на вітер".
Як же так? А все дуже просто.

Подивимося ще кілька звітів. Запустимо "Диспетчер завдань", потім "Монітор ресурсів" і відкриємо вкладку "Пам'ять"
Подивимося ще кілька звітів

Ну ось, власне, і готову відповідь на питання про використання фізичної пам'яті - скільки пам'яті бачить windows 7, або куди зникли півтора гігабайти фізичної пам'яті. Вони зарезервовані під потреби обладнання. Ні, не так. Під потреби обладнання зарезервована НЕ пам'ять, а 1,5 ГБ адресного простору в інтервалі 4 ГБ. Так як одне і теж адресний простір не може бути одночасно використано і пристроями і пам'яттю комп'ютера через неминуче конфлікту, "зайвої" фізичної пам'яті стало просто нікуди подітися і вона виявилася недоступна. Саме зарезервовано і саме віртуального адресного простору з 4 ГБ. На перший погляд такий стан речей не здається правильним і, природно, не викликає радості. Однак, як показала історія розвитку комп'ютерної техніки, рішення розмістити порти введення-виведення пристроїв в основному адресному просторі процесора було виключно вірним. Це дозволило значно збільшити швидкість обміну даними з пристроями і розвантажити центральний процесор. Як ми пам'ятаємо, першим процесором, який мав можливість адресувати 4 гігабайти оперативної пам'яті, був Intel 80386 випущений в 1985 році. Коли розроблявся комп'ютер на його основі, було прийнято рішення виділити адреси портів введення-виведення пристроїв в верхній частині 4-гігабайтного віртуального адресного простору доступного процесору, а нижню частину віддати під фізичну пам'ять.
Уявити собі в той час клієнтський комп'ютер з 4 гігабайтами оперативної пам'яті було практично неможливо. І дійсно, довгі роки адреси пристроїв і максимальний адресу встановленої фізичної пам'яті йшли на зустріч один одному, але не перетиналися, і ніяких конфліктів не виникало. Виглядало це приблизно так.
Ну ось, власне, і готову відповідь на питання про використання фізичної пам'яті - скільки пам'яті бачить windows 7, або куди зникли півтора гігабайти фізичної пам'яті

Деякий час назад реально з'явилися клієнтські комп'ютери з 3 - 4 гігабайтами оперативної пам'яті (а зараз то цим вже нікого не здивуєш) і адреси оперативної пам'яті і пристроїв "зустрілися" і перетнулися. Ось так умовно можна уявити картину рспределения адресного простору і використання фізичної пам'яті для комп'ютера з встановленими 4 гігабайтами оперативної пам'яті
Деякий час назад реально з'явилися клієнтські комп'ютери з 3 - 4 гігабайтами оперативної пам'яті (а зараз то цим вже нікого не здивуєш) і адреси оперативної пам'яті і пристроїв зустрілися і перетнулися

Червона зона в адресному просторі, зайнятому пристроями, відображає конфлікт, який завжди вирішується не на користь фізичної пам'яті - це реальні втрати, ті самі 1,5 ГБ на малюнку вище.
Величина "втрат" залежить від того, як багато фізичної пам'яті встановлено в комп'ютері, і яке адресний простір резервують під себе пристрої. На різних комп'ютерах вона буде різною. Наприклад, на одному з пасажирів під рукою комп'ютерів під потреби обладнання резервується в два рази менше - близько 0,75 ГБ, але так як фізичної пам'яті встановлено 6 ГБ, то втрати в 32-бітної Windows складуть вже приблизно 2,7ГБ, тобто майже половину.
Скористаємося маленької діагностичної утилітою MemInfo від Alexa Ionescu. Запустимо її з правами адміністратора на нашому ноутбуці з ключем -r і подивимося як використовується фізична пам'ять
Червона зона в адресному просторі, зайнятому пристроями, відображає конфлікт, який завжди вирішується не на користь фізичної пам'яті - це реальні втрати, ті самі 1,5 ГБ на малюнку вище

А тепер відкриємо "Диспетчер пристроїв" в "Керування комп'ютером". Перемкнемо "Вид" на "Ресурси по типу" і відкриємо блок "Пам'ять"
А тепер відкриємо Диспетчер пристроїв в Керування комп'ютером

Порівнюємо верхню межу фізичної пам'яті "9F800000", певну утилітою MemInfo, з нижньою межею діапазону адрес, зарезервованих пристроями. У нашому випадку це "A0000000" для відеокарти AMD Radeon HD. Все сходиться. Є ще вікно в нижній частині в діапазоні 640 КБ - 1 МБ. Як не важко здогадатися, це атавізм, який прийшов до нас від 16-розрядного процесора 8086 і ДОС.
Такі от справи в "класичних" 32-розрядних системах. У нашому випадку система не є "класичною" через включеного режиму PAE, але виглядає абсолютно так само завдяки Microsoft-івської обмеження. Очевидно, що задіяти в таких системах повністю 4 ГБ оперативної пам'яті неможливо в принципі.
Microsoft, деяким чином, вводить користувачів в оману, декларуючи підтримку 4 гігабайт оперативної пам'яті. Насправді, як ми вже зрозуміли, система не може задіяти всю пам'ять через те, що адресний простір обмежений зверху "FFFFFFFF" (4 ГБ), а саме це і робить Microsoft не дивлячись на те, що процесор може адресувати незрівнянно більше і сама ОС давно підтримує PAE. Одну з найбільш ймовірних причин по якій це було зроблено ми торкнулися в першій частині.

По-хорошому, для того, щоб продемонструвати, як можна повернути "втрачену" пам'ять, потрібно встановити на нашому ноутбуці Linux з ядром PAE або серверну 32-розрядної версії Windows, причому таку, для якої заявлена ​​підтримка більше 4 ГБ пам'яті. Це, наприклад, Windows Server 2003 або 2008 року в редакції Enterprise. Якщо ж зняти обмеження на 4 ГБ, а про єтом нижче, то вийде щось на зразок цього.
По-хорошому, для того, щоб продемонструвати, як можна повернути втрачену пам'ять, потрібно встановити на нашому ноутбуці Linux з ядром PAE або серверну 32-розрядної версії Windows, причому таку, для якої заявлена ​​підтримка більше 4 ГБ пам'яті

Як бачимо, "загублена" пам'ять відразу знайшлася. Ще раз відкриваємо монітор ресурсів
Як бачимо, загублена пам'ять відразу знайшлася

Тут Windows намагається ввести нас в оману коли говорить, що тепер під обладнання зарезервовано всього 138 Мбайт. На сомом справі зовсім нічого не змінилося, що можна побачити з розподілу адрес в "Диспетчері пристроїв" - всі пристрої залишилися на своїх місцях в діапазоні адрес між "A0000000" і "FFFFFFFF". Тобто, насправді сірим кольором монітор ресурсів показує не розмір адресного простору, зарезервованого під потреби пристроїв, а сумарний обсяг "втраченої" пам'яті. Чому "сумарний" стане ясно, коли ми перейдемо до комп'ютера з об'ємом встановленої фізичної пам'яті більше 4 ГБ.
Діапазони зареєстрованої фізичної пам'яті за допомогою утиліти MemInfo
Тут Windows намагається ввести нас в оману коли говорить, що тепер під обладнання зарезервовано всього 138 Мбайт

Видно, що внизу додався новий діапазон розміром 1,4 ГБ. Це і є наша "втрачена" пам'ять. Через те, що ми продовжуємо оперувати 32-х розрядними адресами, вийшов, як би, конфлікт. Насправді ніякого конфлікту немає в силу того, що додати діапазон фізичних адрес лежить вище "FFFFFFFF". Якщо графічно зобразити те, що вийшло після того, як було знято 4-гігабайтний обмеження
Видно, що внизу додався новий діапазон розміром 1,4 ГБ
"Розумний" чіпсет і BIOS комп'ютера перенесли конфліктну частину фізичної пам'яті вище 4 Гбайтное кордону. Завдяки цьому і працює режиму PAE, цю ділянку фізичної пам'яті став доступний операційній системі.
Тут не зайвим буде зазначити, що для того, щоб "втрачена" пам'ять могла повернутися, потрібен не тільки процесор з підтримкою PAE, але і материнська плата, яка, по-перше, підтримує більше 4 ГБ ОЗУ, по-друге, вміє переміщати адресні блоки фізичної пам'яті, що конфліктують з обладнанням, вище "FFFFFFFF". В BIOS з приводу останнього навіть може бути окрема настройка, щось типу "Memory Remapping", або це відбувається автоматично.

Як прибрати обмеження на 4 ГБ
Увага! Ця дія може виконуватися тільки в дослідницьких цілях на свій страх і ризик. Робіть резервну копію своїх даних.

Обмеження максимально доступною фізичної пам'яті встановлено в PAE ядрі, яке в Windows 7 / Vista називається NTKRNLPA.EXE. Внутрішня процедура MxMemoryLicense викликає недокументовану функцію ZwQueryLicenseValue. Така перевірка виконується два рази. Патч, запропонований дослідником Джефф Шапель (Geoff Chappell), має на увазі дуже невеликі зміни в ядрі - всього по 7 байт в кожному з двох входжень. Після зроблених змін ядро ​​продовжує викликати ZwQueryLicenseValue, але результати цієї перевірки підміняються так, що дозволений верхня межа фізичної пам'яті встановлюється в 128 ГБ.
Передбачається, що в подальшому модифіковане ядро ​​буде називатися NTKR128G.EXE.
Отримане нове ядро ​​може тепер працювати з усією встановленої пам'яттю, але є деякі перешкоди для його використання. Перше - це контрольна сума.
Для всіх виконуваних файлів, що завантажуються WINLOAD, в число яких, природно, входить ядро, контрольна сума, записана в заголовку виконуваного файлу, повинна бути правильною. В результаті модифікації ядра контрольна сума змінилася і стала недійсною. Її потрібно привести у відповідність. Це можна зробити за допомогою, наприклад, EDITBIN з Microsoft Visual Studio.
editbin / release ntkr128g.exe

Друге - цифровий підпис.
Ядро є одним з виконуваних файлів, який повинен бути підписаний сертифікатом, отриманим від одного з нечисленних кореневих центів. Публічні ключі кореневих центрів жорстко прописані в засобі завантаження. Виправлене ядро ​​матиме недійсні цифрові підписи. Але і цю перешкоду можна подолати.
Одним з таких способів є використання тестового режиму, який Microsoft надає для тестування драйверів в процесі їх розробки. У тестовому режимі завантажувач дозволяє виконувати файли, підписані будь-яким кореневих сертифікатом. Можна створити свій власний тестовий сертифікат і підписати їм змінену копію ядра. Після цього воно буде завантажуватися при старті Windows в тестовому режимі (TESTSIGNING). Несуттєвою неприємністю цього варіанту буде поява попереджувального напису в правому нижньому куті робочого столу.
Відповідними інструментами для реалізації такого способу можуть служити Windows Software Development Kit (SDK) або Windows Driver Kit (WDK). З їх допомогою можна зробити свій власний сертифікат:
makecert -r -ss my -n "CN = My Own Testing Authority"
Це команда створить кореневий сертифікат з ім'ям "My Own Testing Authority» і встановить його в особисте сховище сертифікатів. Підписати модифіковане ядро ​​цим сертифікатом можна виконавши команду:
signtool sign -s my -n "My Own Testing Authority" ntkr128g.exe

Тепер є модифіковане ядро ​​для тестування можливості використання в 32-розрядної Windows фізичної пам'яті вище 4 ГБ. Його потрібно скопіювати в каталог C: \ Windows \ System32 і створити новий варіант завантаження за допомогою bcdedit.exe .
Нову завантажувальний запис створюємо шляхом копіювання поточної (current) і даємо їй нове ім'я, наприклад, «Windows Using All My Memory»:
bcdedit / copy {current} / d "Windows Using All My Memory"
Якщо запустити bcdedit без параметрів то можна дізнатися {ідентифікатор} нового запису.

Далі необхідно додати директиви:

bcdedit / set {ідентифікатор} kernel ntkr128g.exe
- вказуємо, яке ядро ​​потрібно завантажити;
bcdedit / set {ідентифікатор} testsigning Yes
- говоримо, що працюємо в тестовому режимі;
bcdedit / set {ідентифікатор} pae ForceEnable
- на всякий випадок.

Якщо після патчеванія і перезавантаження з новим ядром подивитися відомості про пам'ять то можна побачити
Якщо після патчеванія і перезавантаження з новим ядром подивитися відомості про пам'ять то можна побачити

Судячи з того, що говорить про себе система, вона тепер працює з усіма 6 ГБ фізичної пам'яті
Судячи з того, що говорить про себе система, вона тепер працює з усіма 6 ГБ фізичної пам'яті

"Монітор ресурсів" повідомляє, що під обладнання практично нічого не зарезервовано. Але насправді зарезервовані всі ті ж 0,76 ГБ адресного простору, але воно тепер не вираховується з 4 ГБ обсягу пам'яті.
Дивимося діапазони зареєстрованої в системі пам'яті
Монітор ресурсів повідомляє, що під обладнання практично нічого не зарезервовано

Як і очікувалося, додався новий великий діапазон пам'яті вище 4 ГБ.

Стосовно до Windows 7 x86 робити все описане вище "ручками", швидше за все, не знадобиться. У вільному доступі є програми, які автоматизують весь цей процес. Знайти їх в мережі дуже легко.
Один з комплектів називався ReadyFor4GB. Він примітний тим, що складається з трьох окремих модулів, перші два з яких повторюють описані вище етапи. Третій модуль являє собою утиліту для видалення Watermark (попереджувальний напис на робочому столі після завантаження з новим ядром).
З огляду на, що в комплекті є керівництво російською мовою, в якому чітко прописано послідовність запуску програм і відповіді на їхні запитання, докладний опис процесу буде тут зайвим. Досить робити все строго по порядку. Всі програми потрібно запускати з правами адміністратора. Найпростіше в провіднику Windows - «підсвічувати» мишею файл програми, яку потрібно запустити, натискаємо праву кнопку миші і в контекстному меню вибираємо «Запуск від імені адміністратора». Або запустити від імені адміністратора cmd
В силу того, що "рідне" ядро ​​залишається в незмінному вигляді, систему в будь-який момент можна повернути в початковий стан. Завдяки цьому, описаний патч можна вважати відносно безпечним.

Зовсім не зайвим буде до початку запуску Патчер зробити експорт вмісту системного сховища в файл. Ви можете зберегти файл в будь-якому місці і дати йому довільне ім'я (головне згадати потім назва файлу і де він лежить). Цю копію згодом можна використовувати для швидкого і простого відновлення первісного стану системного сховища, що рівносильно скасування всіх зроблених змін.
Досить запустити командний рядок з правами адміністратора:
bcdedit / export "C: \ Backup \ bcd-backup"
де C: \ Backup \ - довільно обрана для зберігання папка, а bcd-backup - довільне ім'я файлу копії сховища.
Коли захочеться припинити всі експерименти з пам'яттю, досить буде набрати:
bcdedit / import "C: \ Backup \ bcd-backup"

Ще один варіант Патчер називається 4GB-7600_RTM_x86. У ньому взагалі один єдиний виконуваний файл, тобто «все в одному флаконі». Не так давно з'явився патч, який позиціонується як універсальний для всіх версій Windows, включаючи і Windows 8.

Як видно, обмеження на 4 ГБ в 32-х розрядних ОС - це "творіння" виключно Microsoft, яке, на щастя, можна обійти.

джерело: ithabits.ru

Як же так?