Killing Floor Client Crash Logs: Breaking Down Real Critical Errors

This page breaks down real Killing Floor 1 crash reports that players of a custom server sent in between 2019 and 2024, from both Steam and non-Steam builds. Every report fits one of five patterns. For each one you get what the log says, the likely cause and what to try.

How to read the crash window

A critical error in Killing Floor looks like this:

Build UT2004_Build_[2004-11-11_10.48]

OS: Windows NT 6.2 (Build: 9200)
CPU: GenuineIntel PentiumPro-class processor @ 1993 MHz with 4095MB RAM
Video: NVIDIA GeForce MX130 (8816)

CreateTexture failed(8007000E).

History: FD3D9Texture::Cache <- FD3D9RenderInterface::CacheTexture <- ...
         <- USkeletalMeshInstance::Render <- ... <- Level KF-BellTolls <- UpdateWorld <- MainLoop

• Build UT2004_Build_[2004-11-11_10.48] is the same on every KF1 install. The game runs on Tripwire's branch of the UT2004 engine and kept the build string.
• Windows NT 6.2 (Build: 9200) is what Windows 8, 10 and 11 report to old programs. It does not mean the player runs Windows 8.
• PentiumPro-class processor and 4095MB RAM come from 2004-era detection code. The game cannot report a modern CPU or more than about 4 GB of RAM, so ignore these lines.
• The error line (CreateTexture failed, General protection fault!, the Russian Виртуальная память исчерпана) names the failure type.
• History (Журнал in the Russian build) is a call stack read from left to right, innermost call first. The left end is where the game died. Further right you usually find the map name (Level ...) and sometimes the object being loaded or drawn (a texture, sound or actor). The tail FMallocWindows::Free <- ... FArray::Realloc repeats in every report and is just the allocator's own history, so ignore it.

1. CreateTexture failed(8007000E)

CreateTexture failed(8007000E).
History: FD3D9Texture::Cache <- FD3D9RenderInterface::CacheTexture
  <- FD3D9RenderInterface::HandleCombinedMaterial <- ... <- USkeletalMeshInstance::Render
  <- (FlameThrower KF-BellTolls-TN1.FlameThrower @ Function KFmod.KFWeapon.RenderOverlays)
  <- (SRHUDKillingFloor ... Engine.HUD.PostRenderActors) <- ... <- Level KF-BellTolls

What it is: 0x8007000E is E_OUTOFMEMORY. Direct3D failed to create a texture while drawing a skeletal mesh: here the first-person Flamethrower, in another report a zed on KF-Fortress. HandleCombinedMaterial means the texture belonged to a Combiner, Shader or other compound material, which is typical for weapon and character skins.

Likely cause: memory pressure. Either the 32-bit process is near its address-space limit or the video card is out of memory. The reports came from a laptop with a GeForce MX130 and 4 GB of RAM on custom maps.

What to try:

1. Apply the low-memory client profile: lower texture detail, turn off precache.
2. Enable Large Address Aware for KillingFloor.exe.
3. Restart the game every few maps: memory fragmentation builds up over a session.
4. Server owners: ship skins and weapon textures in compressed (DXT) formats and load custom weapon assets on demand.

2. Virtual memory exhausted

Виртуальная память исчерпана. Чтобы устранить неполадку, освободите место на основном жестком диске.
History: FMallocWindows::Malloc <- FMallocWindows::Realloc <- 00000000 643 FArray <- ...
  <- UStaticMeshInstance::Serialize <- LoadObject
  <- (StaticMeshInstance KF-Arcade-Horzine-Mall.StaticMeshInstance6158 ...) <- ULinkerLoad::Preload
  <- ... <- UGameEngine::LoadMap <- AttemptLoadPending

History: FMallocWindows::Malloc <- ... 4194304 FArray <- ... <- TLazyArray::Load
  <- FStaticTexture::GetTextureData <- KF_IJC_Halloween_Weapons.Cheetah.cheetah_d
  <- FD3D9Texture::Cache <- ... <- Level Arena Gurubashi

What it is: the engine's own allocator (FMallocWindows::Malloc) could not get memory. The message tells you to free disk space, but that has nothing to do with it. The process ran out of address space, not disk or physical RAM.

What the stack shows: the number before FArray is the size of the failed allocation. In the first case the game died while loading a map (LoadMap, ULinkerLoad::Preload) on a static-mesh instance of a heavy custom map. In the other two it was loading texture data on demand: cheetah_d from KF_IJC_Halloween_Weapons needed 4,194,304 bytes (an uncompressed 1024×1024 RGBA texture), and a custom Jason skin needed 1 MB. The game was so close to the limit that even 1 MB failed.

What to try:

1. Large Address Aware has the most effect here: on 64-bit Windows it raises the limit from 2 GB to 4 GB.
2. Restart the client between long sessions and before heavy maps.
3. Server owners: a crash inside LoadMap points at the map. Check its size, how many packages it pulls in, and whether it can be split or removed from the rotation. A crash in GetTextureData points at the named package. Recompress it or drop it from the trader.

3. D3DERR_OUTOFVIDEOMEMORY

CreateVertexBuffer failed(D3DERR_OUTOFVIDEOMEMORY).
History: FD3D9VertexStream::Cache <- FD3D9RenderInterface::SetVertexStreams
  <- USkeletalMeshInstance::Render <- ... <- Level Police Station

IDirect3DVertexBuffer9::Lock failed(D3DERR_OUTOFVIDEOMEMORY).
History: FD3D9VertexStream::Cache <- FD3D9RenderInterface::SetVertexStreams
  <- ATerrainInfo::Render <- RenderLevel <- KF-AntarcticOutpost.myLevel <- ...

What it is: Direct3D 9 could not create or lock a vertex buffer for a skeletal mesh or for terrain (ATerrainInfo::Render). One report came from a laptop RTX 3050 Ti, so this is not only a weak-GPU problem. Direct3D 9 keeps copies of managed resources in the game's own memory, so a 32-bit process near its limit can get "out of video memory" even with plenty of free VRAM.

What to try:

1. Lower texture detail, world detail and resolution: terrain-heavy outdoor maps suffer most.
2. Large Address Aware and a client restart, as above.
3. On laptops with two GPUs, make sure the game runs on the discrete card (NVIDIA Control Panel or Windows Graphics settings).
4. Server owners: if one map produces most of these reports, test it on a weak PC or replace it.

4. General protection fault in FWaveModInfo::ReadWaveInfo

General protection fault!
History: FWaveModInfo::ReadWaveInfo <- callingGetPerioid <- 1 <- FSoundData::Load
  <- TLazyArray<< <- USound::Serialize <- LoadObject
  <- (Sound KF_BaseScrake_Xmas.Chainsaw.Scrake_Chainsaw_Swipe1 ...) <- ULinkerLoad::Preload
  <- ... <- UPackageMap::PairToObject <- ... <- UActorChannel::ReceivedBunch
  <- ... <- UTcpNetDriver::TickDispatch <- ... (NetMode=3) <- Level Police Station

What it is: the client crashed while parsing a WAV sound (ReadWaveInfo). The sound was loaded because the server replicated an actor that uses it (UActorChannel::ReceivedBunch, PairToObject). Every report of this kind names a sound from the Christmas zed packages: KF_BaseScrake_Xmas (chainsaw idle, swipe, impale) and KF_BaseStalker_Xmas. It happened on several maps, in both Steam and non-Steam builds.

Likely causes, from most to least probable:

• the client's copy of the .uax package is damaged or a different version (common in non-Steam builds assembled from several sources);
• memory pressure made the load fail half-way, and the parser read garbage.

What to try:

1. Steam: verify the game files. Non-Steam: replace Sounds/KF_BaseScrake_Xmas.uax and KF_BaseStalker_Xmas.uax with copies from a clean install of the same version.
2. Clear the Cache folder so the client downloads fresh copies of server packages.
3. Server owners: if seasonal zeds are forced outside their event, consider turning them off. Players with older or broken builds will crash the first time such a zed spawns.

5. General protection fault while rendering or ticking

General protection fault!
History: FD3D9RenderInterface::SetMaterial <- USkeletalMeshInstance::Render <- FDynamicActor::Render
  <- RenderLevel <- KF-MeowNight-CUZUS.myLevel <- ... <- Level Meow Night

General protection fault!
History: ULevel::BuildRenderData <- UGameEngine::Draw <- ... <- Level Police Station

General protection fault!
History: UInteractionMaster::MasterProcessTick <- ULevel::Tick <- (NetMode=3) <- TickLevel
  <- UGameEngine::Tick <- Level HelmsDeep

A GPF is an access to invalid memory. The first function in the stack tells you which subsystem tripped:

First function	What it points at	What to try
FD3D9RenderInterface::SetMaterial under USkeletalMeshInstance::Render	A character, zed or weapon mesh with a broken or half-loaded material: a custom skin whose texture failed to load, or a Combiner with a missing input	Find which custom skins or zeds the map uses. Reproduce with them disabled. Check the .utx versions. Memory pressure (see 1-2) can also leave a material half-loaded
ULevel::BuildRenderData right after a map load	The client failed to build render data for the level, often under memory pressure right after a heavy map change	Restart the client and reconnect. If it repeats on the same map, treat it as a map problem
UInteractionMaster::MasterProcessTick	An Interaction (custom HUD, menu or key handler from a mutator) ticks after the object it uses has been destroyed, typically around a map change	Mutator authors: remove the interaction in NotifyLevelChange() with Master.RemoveInteraction(self) and check every actor reference for none before use

Quick triage

1. Look at the error line: CreateTexture/OUTOFVIDEOMEMORY/Виртуальная память исчерпана are memory problems. A GPF needs the stack.
2. Look at the left end of History: rendering (FD3D9...), loading (LoadObject, LoadMap), networking (ReceivedBunch) or script (ProcessEvent, MasterProcessTick).
3. Find the named object in parentheses: the package before the first dot is the file to check (KF_BaseScrake_Xmas → Sounds/KF_BaseScrake_Xmas.uax).
4. Note the map. If most reports share one map, the map is the suspect, not the PC.
5. Collect several reports before changing anything. One crash is noise, five with the same stack are a pattern.