RoK and earlier clients: understanding and reducing “out of memory” errors

This guide explains errors such as:

Application ran out of memory when requesting 1048592 bytes

The number may be much smaller, such as around 30,000 bytes. The game may show a message, stop loading, or close.

This does not necessarily mean your computer needs more RAM. This old client can run out of space it can use even when Windows has plenty of memory available. Lowering certain graphics settings can reduce the demand without changing the game executable.

The settings below have been checked in this specific DoF client. Their effect on stability still needs testing in gameplay; they are suggested workarounds, not a guaranteed cure. Other client versions need separate checks. EQ2 Client Diagnostics can record several supported versions, but that does not make these DoF settings or limits apply to all of them.

Start here

1. Read What the error means below if you want to understand the cause.
2. Follow Before changing anything, then A: reduce character texture demand.
3. If that is not enough, try B: use a lower graphics preset.
4. Follow Record a test and send a report if it still happens.

The Undo the changes section explains how to restore your original settings. The first two workarounds only change settings; they do not patch EverQuest2.exe.

What the error means

There are several different kinds of “memory.” The important ones here are:

Think of the game's address space as a shelf. Loading a zone places books on it. Removing some books can leave many small gaps, but a large book still needs one gap wide enough to fit. Having more shelves elsewhere in the house does not make this shelf longer.

Why plenty of RAM may not help

The DoF executable examined here is a 32-bit program limited to 2 GiB of address space, including on 64-bit Windows. That range must hold the game's code, data, loaded libraries, and memory that has been reserved for later use. Installing more RAM does not enlarge that range. Microsoft documents these Windows limits.

In this guide, KiB, MiB and GiB are memory-size units: 1,024 KiB = 1 MiB, and 1,024 MiB = 1 GiB. They are close to the KB, MB and GB labels you usually see.

Why a tiny request can fail

The number in the error is the request that failed, not the game's total memory use. It can include a small amount of bookkeeping added by the game.

DoF normally reuses space inside its existing memory pools. When those pools cannot satisfy a request, it may need to ask Windows for a larger block, normally at least 4 MiB. Even a small request can therefore fail when the game cannot obtain a suitable block. Not every allocation needs a new block.

What we found in a real DoF failure

A September 25 recording captured the game running out of memory while entering Qeynos Harbor with Extreme Quality settings:

These readings strongly point to the game's usable address space being nearly full and split into small gaps. The separate DoF pool limit had not been reached. The readings were collected around the failure, rather than freezing every allocation at once, so they are strong evidence rather than a recording of the exact Windows allocation failure.

This happened after a fresh launch. Restarting alone did not prevent it. It also reproduced after Discord was disabled. Those details describe this case; another player's crash may have a different cause.

Before changing anything

The examples use C:\EQ2DoF. Use your own DoF game folder if it is elsewhere. This is the folder containing the EverQuest2.exe you actually launch, not the diagnostics tool's folder.

1. Close the game completely.
2. Create a backup folder outside the game folder, with a recognizable name such as DoF-settings-before-memory-test.
3. Copy eq2_recent.ini and eq2_default.ini into it if they exist. Copy eq2.ini too if it exists. Remember whether eq2.ini existed before the test.
4. Note your current graphics preset, such as Extreme Quality or Balanced. Keep the backup until you are satisfied with the result.

Try the in-game controls below first. If the game closes before you can reach them, use the Alternative: change startup settings in eq2.ini section instead.

A: reduce character texture demand

Use the in-game setting: Options → Display → texture settings → Character LOD Texture Resolution → High instead of Maximum. This makes some character appearance textures less sharp, reducing the memory needed to prepare them. “LOD” means level of detail.

1. Open the game's Options, select Display, and find the texture settings. The original DoF UI groups them under Texture Resolution; a custom UI may use a different group label, such as Textures.
2. Find Character LOD Texture Resolution. It is a separate control from Texture Resolution and Character Texture Resolution.
3. If it is Maximum, change it to High. If it is already High and still fails, try Medium. Do not raise a lower setting to High expecting to save memory.
4. Apply/save the setting, then close the game completely and restart. The option's help text says it affects textures as they change; restarting gives the test a fresh start without previously loaded resources.
5. Check that the chosen value stayed selected, then repeat the same zone entry. Avoid changing the overall graphics preset during the test: selecting a preset reapplies its settings.

If the value changes back after restarting, an existing eq2.ini override may be forcing it. Back up that file and check for r_texture_lodding_shrink, or ask support to check it. The startup alternative below explains the setting.

Here is what the setting changes for the particular temporary images seen in the failure:

These savings apply to those images, not to the whole game's memory use. Other textures and resources still need space, and this setting does not change the game's memory limits.

Alternative: change startup settings in eq2.ini

Use this if you cannot reach the in-game options before the error, or need an explicit startup setting. It changes the same character LOD texture control; it is not an extra memory fix to stack on top of the in-game change.

Use eq2.ini for these overrides. DoF applies its graphics preset after reading eq2_recent.ini, then reads eq2.ini again. A change made only in eq2_recent.ini can be overwritten by the preset.

With the game closed:

• If eq2.ini already exists, open it in Notepad. Preserve its unrelated lines. Update an existing occurrence of a setting instead of adding conflicting copies.
• If it does not exist, open Notepad and save a new file in your game folder. In Save As, choose All files, use the filename eq2.ini, and choose ANSI encoding if offered. The example lines use only ordinary English letters, digits and spaces.
• Check the full filename. It must be eq2.ini, not eq2.ini.txt. Turn on File name extensions in File Explorer's View menu if necessary.
• Copy only the line inside the example box. Do not add the box borders, an equals sign, or a [section] heading.

For High, the first reduction from Maximum, add or update:

r_texture_lodding_shrink 1

Save and fully restart. If needed, a separate test can use r_texture_lodding_shrink 2 for Medium. Higher numbers mean smaller textures; do not replace an existing value of 2 or higher with 1 to save memory.

If no value is written in the file, the graphics preset may already supply one: Balanced uses 1, High Performance 2, Very High Performance 3, and Extreme Performance 4. Do not override those with a smaller number expecting a reduction. If you are unsure about custom settings, ask support to check them.

If you cannot save the file, ask support for help with the installed game folder before continuing.

B: use a lower graphics preset

Use this if the focused texture change is insufficient, or if you want a more conservative starting point and accept a larger reduction in visual quality.

Already using Extreme Performance? Keep that preset and send a report. The value 5 below is a higher-detail preset than Extreme Performance (6). If Very High Performance already fails, repeating the same preset alone is unlikely to help.

In the game's graphics options, choose General Performance → Very High Performance, save/apply it, and fully restart before testing. Check the selected settings after restarting.

If you used an eq2.ini override in A, remove that test line while the game is closed so it does not undo part of the new preset at startup. Preserve unrelated settings.

If you cannot reach the options, use this startup alternative:

1. Close the game fully.

2. In eq2.ini, remove the r_texture_lodding_shrink test override from step A. Preserve unrelated settings.

3. Add or update this line:

   r_performance 5
   

4. Save, restart the game and repeat the same recorded test.

In this DoF build, value 5 means Very High Performance. It lowers texture and character detail and disables shadows, reflections and ground flora. It also sets r_texture_lodding_shrink to 3, which reduces those images further than the focused tests. Leaving an override of 1 or 2 after the preset line would increase that texture demand again.

If you already have other graphics overrides in eq2.ini, they may change what this preset does. Keep a copy and ask support to check them if results are unclear.

If this becomes stable, save a copy of the working configuration. To tune quality upward, remove the test r_performance 5 override while the game is closed, then restart and adjust one graphics category at a time in the game. Repeat the same route after each change. A persistent preset override can reapply the low preset at startup, so keep track of which file settings remain active.

C: optional low-memory policy test

This is an additional trial with unmeasured gameplay benefit. Test it separately after you know the result of A or B, so you can tell whether it helps.

With the game closed, add or update this line in eq2.ini, then restart:

cl_memory_override 768

Despite its name, this does not increase the game's memory allowance. It selects startup behavior intended for a lower-memory machine. In this build, that enables unloading of some model-detail data and turns off an “always visible” default. It may reduce retained resources, with possible extra loading or changes in visible detail.

The value 768 is used to choose that behavior. It is not a new total memory cap. Do not keep increasing the number hoping to unlock more memory. Remove the line and restart to stop selecting this policy; use the full rollback below to restore all original settings.

Undo the changes

1. Close the game completely.
2. Restore your backed-up eq2.ini. If it did not exist before and you created it only for these tests, remove that new file. If you have since added unrelated settings, preserve those and remove only the test lines.
3. Restore the backed-up eq2_recent.ini for a complete return to the original settings. The game may save effective settings there when it exits, so removing the override alone may not restore everything.
4. Leave eq2_default.ini as it was; none of these tests requires editing it. If you changed it independently, use its backup as appropriate.
5. Launch the game again and check the selected graphics settings.

Common questions

Does this also affect KoS, RoK, or AoM?

KoS and RoK share the same limited address space. AoM has more room, but can still run out. We checked the actual supported executable files, rather than assuming a newer expansion fixed the issue.

These address-space limits follow the executable's Large Address Aware setting on 64-bit Windows. Microsoft documents the distinction.

RoK raises the upper limit for its own memory pool from DoF/KoS's 1024 MiB to 2048 MiB. That pool still shares the address range with everything else in the game. A larger pool allowance therefore does not guarantee enough free space for the next allocation.

AoM's larger address range is a useful improvement, not proof that memory exhaustion was completely fixed. Do not patch the supported AoM executable just to enable LAA: it already has that setting.

AoM also improves how it manages that space. Its main memory pool grows in smaller steps—256 KiB instead of the older clients' 4 MiB—and it can return completely unused blocks to Windows. These changes can help with wasted space and fragmentation. A large request still needs a large enough block, and the game can still exhaust its available space.

Its internal limit also follows a different policy, taking the available address range into account instead of keeping DoF's fixed 1024 MiB upper bound. AoM contains automatic low-memory measures as well. These are verified improvements in the program, not proof that every zone and graphics setting will fit.

The underlying character LOD texture-size calculation matches DoF in the inspected KoS and RoK clients, so reducing that texture demand has a sound basis there too. The exact KoS/RoK menu labels and configuration-loading order were not checked in this comparison; use their own controls or ask support before copying DoF file instructions.

The live failure described in this guide was reproduced in DoF. We have not reproduced an equivalent failure in these KoS, RoK or AoM clients; KoS's full installation was unavailable for gameplay testing. Use a separate diagnostic recording for each affected client. The detailed settings, file-loading order and rollback instructions in this guide remain verified for DoF; check another client's controls before copying them over.

Task Manager shows less than 2 GB. Why can it still fail?

Task Manager's displayed memory number does not include every address reservation and mapping. The game's address range can be nearly full even when the displayed memory use is lower. Total free space also does not tell you the size of the largest usable gap.

Is the 512–1024 MiB internal limit configurable?

No INI override was found for that limit in this DoF build. The game calculates it at startup from reported physical memory and keeps it between 512 and 1024 MiB. It limits one internal memory pool, not the entire game. The recorded failure used only 644 of 1024 MiB in that pool, so raising that limit would not address the observed shortage of address space.

cl_memory_override changes the separate behavior described in test C; it does not raise this limit.

Will restarting help?

It clears the previous game session's memory use and can help with problems that build up over time. It cannot solve every case: the investigated crash happened during zone entry after a fresh launch. Restart after settings changes so you test their effect from the beginning.

Will more RAM, a larger pagefile, or closing other programs fix it?

Those can help if Windows itself is short of memory, but they do not enlarge this game's address range. The investigated case had plenty of RAM and Windows memory capacity available. A pagefile provides backing for memory; it does not make this program's address range larger. Microsoft explains the pagefile's role.

Disabling an overlay can remove its activity inside the game and is useful to record as a test. It is not a general cure; this OOM was reproduced with Discord disabled. Closing unrelated applications does not give their address space to the game.

Can the client use more than 2 GiB?

Potentially, through Large Address Aware (LAA). On 64-bit Windows, that executable setting can allow a 32-bit program up to 4 GiB of address space. It changes the game executable and does not remove DoF's separate internal pool limit. Older code can have problems with the newly available addresses. Microsoft describes the compatibility concerns.

Treat this as a support-team test, not a ready configuration fix. The steps are to preserve the original executable, prepare a separate modified copy, have support add diagnostics support for that exact copy, then test repeated zoning and normal gameplay. The recorder will reject a changed executable until its supported profile is updated; do not bypass that check. Restore the original copy to roll back.

Windows /3GB or increaseuserva boot changes concern 32-bit Windows and do not solve this case on a 64-bit system. Microsoft's memory-limit reference.

Can a tool bypass the limit without changing the EXE file?

A developer could change the game's behavior while it is running, leaving the file on disk unchanged. That still changes the running program and needs testing. No such workaround is ready here, and changing the pool's allocation rules would not by itself remove the 2 GiB address limit.

Windows does not let the game simply continue past its usable address range. If it cannot provide the requested memory, ignoring the error cannot provide the missing space either.

Does this prove a memory leak, bad server packet, or graphics-card problem?

No. An OOM message alone does not identify the cause. The examined failure happened while preparing character appearance textures; that does not tell us which resources consumed all the other space.

Support may need to investigate incompatible appearances, the amount of character/model data in a zone, or resources that remain loaded too long. “Unknown client cmd” and collision-radius errors also need their own evidence. Include those messages in a report if you see them, without assuming they are all the same fault. These memory measurements are not a measurement of graphics-card memory.