Управление ОЗУ, виртуальной памятью, подкачками страниц и памятью в Windows
Исходная версия продукта: Windows 7 Пакет обновления 1, Windows Server 2012 R2
Исходный номер КБ: 2160852
Аннотация
В этой статье содержатся основные сведения о реализации виртуальной памяти в 32-битных версиях Windows.
В современных операционных системах, таких как Windows, приложения и многие системные процессы всегда ссылались на память с помощью адресов виртуальной памяти. Виртуальные адреса памяти автоматически преобразуются оборудованием в реальные (ОЗУ) адреса. Только основные части ядра операционной системы обходят этот перевод адресов и напрямую используют реальные адреса памяти.
Виртуальная память всегда используется, даже если объем памяти, требуемой для всех запущенных процессов, не превышает объем оперативной памяти, установленной в системе.
Процессы и адресные пространства
Всем процессам (например, исполняемым приложениям), работающим под 32-битными версиями Windows, назначены адреса виртуальной памяти (виртуальное адресное пространство), в диапазоне от 0 до 4 294 967 295 (2*32-1 = 4 ГБ), независимо от того, какой объем ОЗУ установлен на компьютере.
В конфигурации Windows по умолчанию 2 гигабайта (ГБ) этого виртуального адресного пространства предназначены для частного использования каждого процесса, а остальные 2 ГБ совместно используются всеми процессами и операционной системой. Как правило, приложения (например, Блокнот, Word, Excel и Acrobat Reader) используют только часть 2 ГБ частного адресного пространства. Операционная система назначает кадры страниц ОЗУ только используемым страницам виртуальной памяти.
Расширение физического адреса (PAE) — это функция 32-битной архитектуры Intel, которая расширяет адрес физической памяти (ОЗУ) до 36 битов. PAE не меняет размер виртуального адресного пространства (который остается на уровне 4 ГБ), а только объем фактической оперативной памяти, который может быть решен процессором.
Перевод между 32-битным адресом виртуальной памяти, используемым кодом, который работает в процессе, и 36-битным ОЗУ-адресом автоматически и прозрачно обрабатывается оборудованием компьютера в соответствии с таблицами перевода, которые поддерживаются операционной системой. Любая виртуальная страница памяти (32-битный адрес) может быть связана с любой физической страницей ОЗУ (36-битным адресом).
В следующем списке описывается, сколько ОЗУ поддерживается различными версиями и выпусками Windows (в мае 2010 г.):
| Версия Windows | ОЗУ |
|---|---|
| Windows NT 4.0 | 4 ГБ |
| Windows 2000 Professional | 4 ГБ |
| Windows 2000 Standard Server | 4 ГБ |
| Windows 2000 Advanced Server | 8 ГБ |
| Windows 2000 Datacenter Server | 32 ГБ |
| Windows XP Professional | 4 ГБ |
| Windows Server 2003 Web Edition | 2 ГБ |
| Windows Server 2003 Standard Edition | 4 ГБ |
| Windows Server 2003 Enterprise Edition | 32 ГБ |
| Windows Server 2003 Datacenter Edition | 64 ГБ |
| Windows Vista | 4 ГБ |
| Windows Server 2008 Standard | 4 ГБ |
| Windows Server 2008 Enterprise | 64 ГБ |
| Windows Server 2008 Datacenter | 64 ГБ |
| Windows 7 | 4 ГБ |
Файл подкачки
ОЗУ — это ограниченный ресурс, тогда как в большинстве практических целей виртуальная память не ограничена. Может быть много процессов, каждый из которых имеет собственное 2 ГБ частного виртуального адресного пространства. Если память, используемая всеми существующими процессами, превышает объем доступной оперативной памяти, операционная система перемещает страницы (4 КБ) одного или более виртуальных адресных пространств на жесткий диск компьютера. Это освободит кадр ОЗУ для других видов использования. В системах Windows эти страницы с страницами хранятся в одном или Pagefile.sys файлах в корне раздела. В каждом разделе диска может быть один такой файл. Расположение и размер файла страницы настраиваются в свойствах системы (нажмите кнопку «Дополнительные»,«Производительность» и нажмите кнопку «Параметры»).
Пользователи часто задают вопрос о том, насколько большим должен быть этот pagefile? На этот вопрос не существует одного ответа, так как он зависит от объема установленной оперативной памяти и объема виртуальной памяти, требуемой для рабочей нагрузки. Если других сведений нет, то в качестве отправной точки является обычная рекомендация в 1,5 раза больше установленной оперативной памяти. В серверных системах обычно необходимо иметь достаточный объем оперативной памяти, чтобы не было нехватки и не использовался pagefile. В этих системах не может быть полезного предназначения для обслуживания большого pagefile. С другой стороны, если место на диске достаточно, то сохранение большого размера (например, в 1,5 раза больше установленного ОЗУ) не вызывает проблем, а также избавляет от необходимости беспокоиться о том, насколько большим будет размер ОЗУ.
Производительность, ограничения архитектуры и ОЗУ
В любой компьютерной системе по мере увеличения нагрузки (количества пользователей, объема работы) производительность снижается, но нелинейно. Любое увеличение нагрузки или спроса после определенного момента приводит к существенному снижению производительности. Это означает, что некоторым ресурсам не хватает ресурсов и они стали узким местом.
В определенный момент не удается увеличить ресурс, который находится в нехватке. Это означает, что достигнут предел архитектуры. Ниже lyly reported architectural limits in Windows include the following:
- 2 ГБ общего виртуального адресного пространства для системы (ядро)
- 2 ГБ частного виртуального адресного пространства на процесс (режим пользователя)
- 660 МБ системного хранилища PTE (Windows Server 2003 и более ранних версиях)
- 470 МБ хранилища пула страниц (Windows Server 2003 и более ранних версиях)
- 256 МБ невыгваряемого хранилища пула (Windows Server 2003 и более ранние версии)
Это относится в частности к Windows Server 2003, но также может применяться к Windows XP и Windows 2000. Однако в Windows Vista, Windows Server 2008 и Windows 7 не все эти архитектурные ограничения имеются. Ограничения на объем памяти пользователя и ядра (здесь цифры 1 и 2) одинаковы, но ресурсы ядра, такие как PTES и различные пулы памяти, являются динамическими. Эта новая функция позволяет использовать как страницную, так и невыгежную память. Это также позволяет PTES и пулу сеансов увеличиваться за пределы, которые были рассмотрены ранее, до того момента, когда все ядро исчерпано.
Часто найденные и кавычках:
На сервере терминалов до использования 4 ГБ ОЗУ будет использоваться 2 ГБ общего адресного пространства.
В некоторых случаях это может быть верно. Однако необходимо отслеживать систему, чтобы узнать, применимы ли они к конкретной системе. В некоторых случаях эти заявления являются выводами определенных Windows NT 4.0 или Windows 2000 и не обязательно применимы к Windows Server 2003. В Windows Server 2003 были внесены значительные изменения, чтобы снизить вероятность того, что эти архитектурные ограничения будут фактически достигнуто на практике. Например, некоторые процессы, которые находились в ядре, были перемещены в процессы без ядра, чтобы уменьшить объем памяти, используемый в общем виртуальном адресной области.
Мониторинг использования ОЗУ и виртуальной памяти
Системный монитор — это инструмент, который позволяет отслеживать производительность системы и определять местоположение узкого места. Чтобы запустить монитор производительности, нажмите кнопку «Начните», выберите «Панель управления»,«Администрирование» и дважды щелкните «Монитор производительности». Вот сводка по некоторым важным счетчикам и их сведениям:
Память, зафиксированные вбайтах: этот счетчик является показателем потребности в виртуальной памяти.
Здесь показано, сколько бытов было выделено процессами и на что операционная система зафиксирует кадр страницы ОЗУ или слот страницы в этом окле (или, возможно, и то, и другое). По мере того как размер фиксных данных превышает объем доступной оперативной памяти, увеличивается размер подкачка, а используемый размер подкачка также увеличивается. В определенный момент действия по разгонам начинают значительно влиять на производительность.
Процесс, рабочий набор, _Total: этот счетчик является показателем активного использования виртуальной памяти.
Этот счетчик показывает, сколько ОЗУ требуется для того, чтобы виртуальная память, используемая для всех процессов, была в оперативной памяти. Это значение всегда является кратным 4096, что является размером страницы, используемой в Windows. Так как потребность в виртуальной памяти выходит за пределы доступной оперативной памяти, операционная система настраивает объем виртуальной памяти процесса в рабочем наборе, чтобы оптимизировать доступное использование ОЗУ и свести к минимуму разгибание по сети.
Файл подкачка, используемый %pagefile: этот счетчик является показателем того, какая часть файла страниц фактически используется.
Этот счетчик используется для определения размера подкачка. Если этот счетчик достигает 100, то подкачка заполнена, и все будет работать. В зависимости от настояния рабочей нагрузки, возможно, необходимо, чтобы размер подкачка был достаточно большим, чтобы он использовался не более 50–075 процентов. Если используется большая часть подкачка, наличие более одного на разных физических дисках может повысить производительность.
Память, страницы/с: этот счетчик является одной из наиболее распространенных мер.
Высокое значение этого счетчика не обязательно означает, что узкое место производительности связано с нехваткой ОЗУ. Операционная система использует систему подкачки для других целей, кроме замены страниц из-за чрезмерного обязательства памяти.
Память, выходные данные страниц/с: этот счетчик показывает, сколько страниц виртуальной памяти было записано на страницу, чтобы освободить кадры страниц ОЗУ для других целей каждую секунду.
Это лучший счетчик для отслеживания, если вы подозреваете, что разгон является узким местом производительности. Даже если количество зафиксированных данных больше установленного ОЗУ, если в большинстве периодов времени значение выходных данных страниц в секунду низкое или нулевое, проблем с производительностью недостаточного объема ОЗУ не возникает.
Память, кэш-память, невыгкупаемая память пула, память, количество на странице пула, память, общее количество системных кодов, память, общее количествобайтов системного драйвера:
Сумма этих счетчиков является показателем того, сколько из 2 ГБ общей части виртуального адресного пространства размером 4 ГБ фактически используется. Используйте их, чтобы определить, достигает ли ваша система одного из ограничений архитектуры, которые были рассмотрены ранее.
Память, доступное МБайт: этот счетчик измеряет объем ОЗУ, доступный для удовлетворения требований к виртуальной памяти (либо для новых выделений, либо для восстановления страницы из подкачка).
Если ОЗУ не хватает (например, «Зафиксированные», больше установленного ОЗУ), операционная система попытается сохранить определенную часть установленной оперативной памяти доступной для немедленного использования путем копирования страниц виртуальной памяти, которые не используются в активном режиме, на этот подкачка. Таким образом, этот счетчик не достигает нуля и не обязательно является хорошим показателем того, не хватает ли системе ОЗУ.
Размер виртуального адресного пространства ос windows
Limits of Virtual Memory in Windows — Ограничения виртуальной памяти в Windows
Автор: egor23, 29.05.2008 14:34, последнее обновление 13.12.2009 21:55
обсуждение обзора на форуме
Предисловие
Данный обзор рассказывает об ограничениях виртуального адресного пространства (Virtual Address Space — VAS) процесса в 32-bit Windows, и в 64-bit Windows для 32-bit приложений. А также раскрывает причины появлений сообщений — «Недостаточно памяти». Если раньше при появлении неинформативного сообщения — «Недостаточно памяти», это списывалось на то, что установлено мало оперативной (физической) памяти, то теперь списывать на это не получается (установлено часто 2ГБ и более оперативной памяти), и возникает вопрос: Почему не хватает памяти?
Теория:
- Ограничения Windows.
Полный список ограничений по памяти можно посмотреть на страничке Memory Limits for Windows Releases.
Нас же интересуют только ограничения виртуального адресного пространства:
до 3 ГБ, если приложение компилируется с параметром IMAGE_FILE_LARGE_ADDRESS_AWARE и система загружается с ключом /3GB
4 ГБ, если приложение компилируется с параметром IMAGE_FILE_LARGE_ADDRESS_AWARE
x64: 8 ТБ, если приложение компилируется с параметром IMAGE_FILE_LARGE_ADDRESS_AWARE
Intel IPF: 7 ТБ, если приложение компилируется с параметром IMAGE_FILE_LARGE_ADDRESS_AWARE
Виртуальная память — В Windows реализована система виртуальной памяти, основанная на плоском (линейном) адресном пространстве. Она создаёт каждому процессу иллюзию того, что у него есть собственное большое и закрытое адресное пространство [1, c.15].
Следующие термины, в данном обзоре, равносильны:
1. Виртуальное адресное пространство процесса;
2. Виртуальная память процесса;
3. Виртуальная память.
В 32-bit Windows:
Размер виртуального адресного пространства — 4ГБ, распределено:
2ГБ — user mode (пользовательский режим), 2ГБ — kernel mode (режим ядра).
Т.е. приложению (процессу) доступно примерно 2ГБ виртуального адресного пространства в независимости от количества установленной физической памяти. Размер виртуального адресного пространства в режиме пользователя можно увеличить до 3ГБ используя специальные параметры (ключи) загрузки, 4-gigabyte tuning (4GT):
Windows Vista \ Windows 2008 \ Windows 7
BCDEdit /set increaseuserva xxxx (xxxx в МБ в диапазоне 2048 — 3072), BCDEdit /set.
Windows XP \ Windows 2003
/3GB /userva=xxxx (xxxx в МБ в диапазоне 2048 — 3072) в файле Boot.ini (Параметры, используемые в файле Boot.ini), рекомендуемый максимум значений userva 2900–3030, более детально можно узнать в статье.
Примечание: Ограничение VAS для режима ядра до 1 ГБ оказывает влияние на работу всей операционной системы, а не только на приложения, которым нужен большой объём VAS. Ключ /3GB влияет на все компоненты ядра, включая все драйверы. Включение /3GB может вызвать такие отрицательные эффекты, как снижение производительности и отказы распределения памяти с остановкой системы.
Чтобы приложение смогло использовать виртуальное адресное пространство больше 2ГБ оно должно быть скомпилировано с параметром IMAGE_FILE_LARGE_ADDRESS_AWARE.
Старшие 2ГБ (0x80000000 — 0xFFFFFFFF)
Младшие 2ГБ (0x00000000 — 0x7FFFFFFF)
Старшие 1ГБ (0xC0000000 — 0xFFFFFFFF)
Младшие 3ГБ (0x00000000 — 0xBFFFFFFF)
В 64-bit Windows для 32-bit процесса доступно:
2ГБ и 4ГБ (если приложение компилируется с параметром IMAGE_FILE_LARGE_ADDRESS_AWARE).
«Барьеры» в адресном пространстве.
У каждого приложения, dll-ки и т.п., есть стартовый адрес (Image Base Address), с которого она должна начать загрузку. При загрузке приложения в его адресное пространство подгружаются разные dll-ки, которые использует приложение, а также dll-ки от других программ (Firewall, Antivirus, FileBox eXtender, Prio, ABBYY Lingvo, и т.п.). В результате в адресном пространстве появляются «барьеры».
Также «барьеры» появляются в результате работы приложения, представляют собой «занятые» блоки адресного пространства.
Большинство приложений резервируют адресное пространство всегда непрерывными блоками, и если им это не удаётся, то приложения или выдают сообщение: Недостаточно памяти; или «вываливаются» с ошибкой: Ошибка произошла т.к. недостаточно памяти; или «вываливаются» с ошибкой, которая мало о чём говорит; или виснут.
Практика:
В примерах использовались ОС Windows:
32-bit Windows — Windows XP Professional SP2
64-bit Windows — Windows XP Professional x64 Edition SP2
1. Почему не хватает памяти?!
Есть приложения у которых нет проблем из-за нехватки VAS: Adobe Photoshop, GIMP и т.п:
1. Память «не выделяется большими кусками».
2. Если «виртуальной памяти» недостаточно есть temp-файл, т.е. нет зависимости от размера VAS.
Из п.1 теории видно, что памяти даётся 32-bit приложению много 2ГБ (по-умолчанию), но в п.2 и п.3 описываются «подводные камни», на которых спотыкаются ряд приложений, далее пойдёт речь о таких приложениях и каким образом можно обходить эти «подводные камни».
Если приложение выделяет память «небольшими кусочками», то оно займёт всю доступную виртуальную память и уже после выдаст сообщение о нехватке памяти или вывалиться с ошибкой.
Если приложение выделяет память большими блоками, то оно практически сразу выдаст сообщение:
| недостаточно памяти для выполнения операции. |
7-zip, Squeez, WinRK и т.п. — при создании\распаковке архива;
Paint.NET, Xnview и т.п. — при создании\открытии изображения;
и т.п. список приложений в которых возникают такие проблемы большой.
Связано это с тем, что первые 2ГБ виртуального адресного пространства процесса фрагментированы, разбиты на непрерывные области, и при попытке зарезервировать область памяти больше имеющейся приложение говорит, что недостаточно памяти.
Чтобы увидеть, как фрагментировано адресное пространство конкретного процесса, в данный момент времени, воспользуемся утилитой VMMap, офф.сайт. Для примера возьмём приложение 7-zip 32bit, процесс 7zG.exe (7-Zip GUI) — вызывается из контекстного меню — 7-zip — Добавить к архиву.
Выберем Type Free (свободные области памяти), отсортируем столбец Size по убыванию:
Максимальная свободная область виртуальной памяти — 1201.6МБ (1230488кБ).
В столбце Largest показаны области самого большого размера в каждом типе памяти.
В Options отметим Show Free Regions (отображать свободные области памяти), выберем Type Total (все области памяти), отсортируем столбец Address по возрастанию, в итоге видим, как поделено адресное пространство виртуальной памяти процесса:
Ниже на картинке показано, как это выглядит «на плоскости»:
2. Флаг IMAGE_FILE_LARGE_ADDRESS_AWARE
Если программист забыл или не помнил про флаг IMAGE_FILE_LARGE_ADDRESS_AWARE ничего это дело поправимое. Информация находится в заголовке исполняемого файла (PE).
Для начала надо определится стоит флаг или нет. Для это можно воспользоваться приложениями выводящими информация о PE (PE Viewer) или использовать редактор PE (PE editor), или т.п.
Для просмотра можно воспользоваться следующими приложениями:
Если флаг не выставлен, то его можно выставить хоть вручную — в нужном месте, нужный байтик поправить.
Выставляем флаг: EDITBIN.EXE /LARGEADDRESSAWARE program.exe
Убираем флаг: EDITBIN.EXE /LARGEADDRESSAWARE:NO program.exe
Только выставить флаг можно с помощью 4GB Patch:
Для просмотра и изменения можно воспользоваться CFF Explorer, также позволяет менять и другие параметры:
Посмотрим, что будет иметь 32-bit приложение (7zG.exe) с выставленным флагом /LARGEADDRESSAWARE и чего не будет, если флаг не выставлен.
32-bit Windows
32-bit Windows
/3GB /USERVA=3072
7zG.exe флаг /LARGEADDRESSAWARE выставлен
64-bit Windows
64-bit Windows
7zG.exe флаг /LARGEADDRESSAWARE выставлен
В итоге:
при использовании параметра IMAGE_FILE_LARGE_ADDRESS_AWARE 32-bit приложение получит дополнительно непрерывный регион памяти:
в 32bit Windows — до 1023МБ;
в 64bit Windows — 2047МБ,
причём данные блоки будут доступны 32-bit приложению всегда.
3. Решение проблемы «нехватки памяти».
1. Связаться с автором приложения, объяснить суть проблемы, возможно исправит, но могут быть варианты:
1.1. Автор учтёт особенности VAS и внесёт исправления — приложение не будет зависеть от непрерывных блоков;
1.2. Автор учтёт особенности VAS, но уйдёт от решения проблемы, путём ограничения функционала приложения;
1.3. Автор учтёт особенности VAS, но ничего сделано не будет.
2. Использовать Win64 или Win32 + /3GB, у приложения должен быть выставлен флаг IMAGE_FILE_LARGE_ADDRESS_AWARE.
3. «Расчистить» адресное пространство вручную:
3.1. Убрать приложения (выгрузить\удалить), которые «мешают»;
3.2. Изменить базовые адреса dll-ок вручную ( для опытных пользователей).
3.1. Изменение базового адреса dll \ exe:
1. Данным способом нужно пользоваться обдуманно, может приводить к нестабильной работе ПО.
2. Данное решение — «на данный момент», т.к. в дальнейшем dll-ки могут обновиться, могут подцепиться другие dll-ки и т.п.
(обновили ПО, поставили обновления на систему и т.п.)
Примечание: Разработчику (программисту) обычно виднее с какого адреса должна грузиться его dll-ка и т.п.
необходимые условия для изменения базового адреса:
1. У dll \ exe должна быть таблица переадресации (relocation table \ relocation section)
2. Базовый адрес должен быть кратен 64кБ (адрес записанный в HEX будет заканчиваться на четыре нуля, например — 0x12340000)
3. Базовй адрес может быть «любым» в пределах 0x00000000-0xFFFF0000
При одинаковых базовых адресах у dll-ок, или если адресное пространство занято, куда dll-ка хотела загрузиться, происходит операция переадресации, dll-ка загружается по другому свободному адресу. Старайтесь указывать адреса, которые свободны, чтобы переадресации не было.
Для изменения базового адреса можно воспользоваться утилитами ReBase.Exe, EDITBIN.EXE, и т.п.:
REBASE.EXE -b 0x10000000 z.dll
REBASE.EXE также может пакетно обрабатывать файлы, в результате dll-ки будут располагаться последовательно у первой будет указанный адрес, у остальных автоматом присвоятся новые большие адреса:
REBASE.EXE -b 0x10000000 *.dll
или
REBASE.EXE -b 0x10000000 @list_dll.txt
list_dll.txt — файл-список
EDITBIN.EXE, может обрабатывать только по одному файлу:
EDITBIN.EXE /REBASE:BASE=0x10000000 z.dll
ReBase.Exe, EDITBIN.EXE имеют «защиту от дурака», если нет relocation table или адрес не кратен 64kB, то базовый адрес не будет изменён.
Примечание: замечено relocation section может не быть, а базовый адрес будет изменён (xpsp2res.dll), или relocation section присутствует, а базовый адрес не меняется. почему сие так непонятно.
Последовательность действий при изменении Image Base:
1. сделать резервную копию изменяемых dll \ exe;
2. скопировать в отдельную папку dll \ exe, для изменения адреса;
3. изменить базовый адрес;
4. заменить dll \ exe на изменённые.
Проблемы которые могут быть:
В данном случае проблема одна (три разновидности).
С одной стороны user32.dll перемещаться может, с другой стороны система этого не любит:
Пример:
32-bit Windows
Для примера возьмём приложение 7-zip 32bit , процесс 7zG.exe (7-Zip GUI) — вызывается из контекстного меню — 7-zip — Добавить к архиву.
Сделаем крайность — размер модели PPMd 1800МБ — нам нужен будет непрерывный блок памяти примерно в 1800МБ.
Если пойдём влоб, то получил сообщение об ошибке:
будет достаточно если объединим три блока:
250048кБ (244МБ)
1230396кБ (1201МБ)
413984кБ (404МБ)
нам это должно дать непрерывный блок памяти примерно в 1850МБ
По VMMap нам нужно изменить адреса двух dll-ок:
7-zip.dll — dll-ка от приложения 7-zip
uxtheme.dll — системная dll-ка
но т.к. dll-ки могут быть перемещены, то возьмём Process Explorer, офф.сайт.
Process Explorer сможет нам показать какие dll-ки подцепились к процессу, их базовые адреса, с каких адресов загрузились, и путь до этих dll:
Имеем:
FileBXH.dll — dll-ка от стороннего приложения FileBox eXtender
7z.dll — dll-ка от приложения 7-zip
uxtheme.dll — системная dll-ка
FileBXH.dll и 7z.dll имеют одинаковый базовый адрес, соответственно FileBXH.dll была перемещена.
Изменим адреса начиная с 0x75000000 (мне так захотелось):
Примечание: Не забываем, что расположение dll подгоняется под адресное пространство конкретного процесса (7zG.exe), если dll-ки используются другими приложениями, могут возникнуть проблемы.
REBASE.EXE -b 0x75000000 @list_dll.txt
В итоге получим:
0x75000000 7z.dll
0x750E0000 FileBXH.dll
0x75100000 uxtheme.dll
Недостаток такого способа решения — dll-ки FileBXH.dll и uxtheme.dll используют практически все приложения с GUI.
3.2. Минимизация потенциальных проблем:
Примечание: Данные способы не относится к dll-кам, которые внедряются сторонним ПО.
1. Чтобы минимизировать потенциальные проблемы с изменёнными dll-ками их можно положить рядом с исполнимым файлом (*.exe).
Примечание: Способ работает в зависимости от приложения \ dll-ок.
2. Перенаправление DLL (DLL redirection)
DLL-ки будут загружаться сначала из папки приложения, если их там нет, то будут искаться в других папках.
Рекомендации, подробнее написано в DLL/COM Redirection on Windows
Если исполнимый файл Program.exe, то создать рядом файл (или папку) с именем Program.exe.local:
файл Program.exe.local — dll-ки располагаются рядом с Program.exe
папка Program.exe.local — dll-ки располагаются или рядом с Program.exe, или в папке Program.exe.local, или и рядом и в папке.
Примечание: Данный способ не будет работать если есть manifest (встроен в exe, или лежит рядом — Program.exe.manifest).
Положить рядом с исполнимым файлом Program.exe файл Program.exe.manifest,
например такого содержимого:
Пример:
В случае с 7zG.exe достаточно просто положить рядом uxtheme.dll:
DLL-ки, которые внедряются сторонним ПО
Осталось решить вопрос с FileBXH.dll
Оставим решение на «откуп системы», изменим базовый адрес на адрес, который всегда занят, чтобы было всегда перемещение (переадресация) (так делать не рекомендуется).
В конце пользовательского адресного пространства есть закрытый регион памяти в 64кБ.
Для общего случая можно взять адрес 0xFFFF0000:
REBASE.EXE -b 0xFFFF0000 FileBXH.dll
3.3. «Будьте бдительными»
Существует достаточно большое количество утилит\PE-редакторов и т.п., с помощью которых можно изменять Image Base.
Но не всегда данная манипуляция проходит «корректно».
Воспользуемся для изменения базового адреса CFF Explorer — Rebuilder:
Изменим Image Base для следующих dll:
0x75000000 7z.dll
0x750E0000 FileBXH.dll
0x75100000 uxtheme.dll (замена dll-ки будет в системном каталоге)
после перезагрузки Windows получим:
проблема из-за uxtheme.dll
Остались без рабочего стола — неприятно, но не смертельно, зато у 7-zip всё замечательно 🙂
