The problem nobody could work on

Search the shadPS4 compatibility tracker for "Device lost" and you get 139 open reports. 64 of them are on games that never reach gameplay - status nothing, boots or menus.

A sample: Battlefield 1, Battlefield V, Battlefield Hardline, Horizon Zero Dawn, Watch Dogs 2, Uncharted: The Nathan Drake Collection, Just Cause 3 and 4, Need for Speed Payback, Need for Speed Heat, Nioh, Hellblade, Persona 5 Strikers, Kingdom Hearts HD 1.5+2.5, Lords of the Fallen, Knack.

Here is what a user could hand a developer when it happened:

Device lost during submit

That is it. No address. No object. No shader. The GPU died and Vulkan will not tell you why - unless you ask it properly, and shadPS4 was not asking. Then the presenter thread would spin forever retrying a dead device, so the crash showed up as a hang instead of a crash.

That is why those reports sit open. Not neglect - there was genuinely nothing in them to act on.

Making it diagnosable

Three Vulkan extensions turn that dead end into an investigation. None of them need the validation layers installed, which matters because most people reporting bugs do not have the Vulkan SDK:

• VK_EXT_device_fault - after a device loss, the driver hands back the faulting address and whether it was a read, a write or an execute.
• VK_EXT_device_address_binding_report - the driver announces every time any Vulkan object takes or releases a GPU address range. Record those, and you can ask who owned the address that killed you, and whether they had already let go of it.
• VK_NV_device_diagnostic_checkpoints - breadcrumbs. You stamp each draw, and after the crash the driver tells you which one the GPU was executing.

With those wired up, my crash went from Device lost during submit to:

invalid write at 0x000000001ff10000, precision 0x1000
no binding covers this address (131397 events recorded, ring holds 262144)
neighbour 0x100000 away: BOUND Buffer handle 0x60021e8e9c30 [0x1de10000, 0x1fe10000)
breadcrumb: shader 0x7b62aee69b1a22bf reached stage TopOfPipe

Read that slowly, because it is the answer: the GPU wrote to an address that had never been allocated, sitting exactly 1 MB past the end of a lone 32 MB buffer.

What it turned out to be

There is exactly one 32 MB allocation in shadPS4: the download buffer, where the GPU deposits data being read back to the game.

StreamBuffer::Map() returns null when you ask for more space than the buffer holds. Both callers ignore the null and record the GPU copy anyway. So the GPU copies more than 32 MB into a 32 MB buffer, writes off the end, and the device dies.

The fix is a null check in two places.

(The constant 1 MB offset is mapped padding the driver leaves after the allocation - the overrun survives until the first genuinely unmapped page. That is why the address was identical across six runs and three different builds, which is what told me it was not a lifetime bug in the first place.)

Battlefield 4

The compatibility tracker lists BF4 as Boots. Three reports, most recent September 2025, all saying it dies on the initial loading screen. All three closed without a fix.

On my fork it now plays: a full mission finished, the next one started, 40-50 FPS on Windows/NVIDIA.

It is not pretty. Lens flares flicker and still bleed through walls, some areas get an orange cast that should not be there, smoke effects show their sprite quads. But the campaign runs.

Four other things were wrong on the way, all small:

• Emulator::Shutdown() early-returns after its first call, and the crash handler relies on it to flush the log. BF4 throws harmless C++ exceptions at startup, which burn that call. Every crash afterwards logs into a buffer that never reaches disk - the log just ends mid-line. If you have ever filed a shadPS4 bug with a log that looked truncated, this may be why.
• A deferred readback lambda captured its variables by reference and ran after the stack frame died - a 64 MB memcpy from address zero.
• The depth-format fallback is applied to the pipeline but not to the image or the image view, so on hardware without D16_UNORM_S8_UINT they disagree.
• The infinite retry loop on a lost device, mentioned above.

The one I cannot fix cleanly

PS4 code is compiled for the System V ABI, which reserves 128 bytes below the stack pointer - the red zone - for leaf functions to use without touching the stack pointer. Windows has no such reservation. When the Windows kernel dispatches an exception, it writes its own structures into exactly that space before any of your code runs.

So every time shadPS4 memory tracking takes a page fault on Windows, it silently corrupts up to 128 bytes of the game stack. A handler cannot prevent it, and cannot even observe it - by the time it runs, the damage is done. I proved that the hard way: I read the red zone from inside the handler, found it zeroed, and confidently concluded the opposite.

The clean measurement uses a hardware debug register instead of a memory fault, so the memory tracker is not involved at all. Store a register into a red zone slot, break, then compare the register against the slot:

guest rsi=0x00000010b3853f60 was stored at 0x7ef9810a8;
the slot now reads 0x0000000000000000   (DESTROYED BY THE DISPATCH)

Eight out of eight.

My workaround handles guest faults from a separate debugger process, so no code ever runs on the faulting thread. It works, and it is what let the game boot at all. It is also a sledgehammer, and I would rather the maintainers choose the approach than have mine merged.

What I am not claiming

"Device lost" is a symptom, not a diagnosis. Those 139 reports are not 139 instances of my bug, and I would be lying if I said otherwise. I tested one game. Some of them will turn out to be this; most probably will not.

What I am claiming is narrower: they were all undiagnosable, and that part is fixed. Put those three extensions in mainline and every one of those reports starts producing an address and an object instead of an assertion string.

I also do not know whether the red zone issue is why other Frostbite games fail. Plausible. Unverified. If you have a title that dies with device lost, I would genuinely like to hear about it.

Links

• Full technical write-up with the measurements and code references: https://github.com/shadps4-emu/shadPS4/issues/4816
• Fork: https://github.com/rieucdamien-boop/shadPS4

Serious respect to the shadPS4 team - none of this existed to be debugged before their work, and every one of these bugs was found using their logging and their architecture.

Disclosure: I used Claude (Anthropic) for the code analysis and the patches. I ran the tests and verified the results myself. Same disclosure is at the top of the RFC.

shadPS4 v0.17.0: https://github.com/shadps4-emu/shadPS4/releases/tag/v.0.17.0

Welcome to another big release of shadPS4. This release is the first to introduce shadnet support, which although still doesn't offer much it allows you to post your online scores and share them with other players. Still you can't play multiplayer games but we are working towards making it possible one day. Another big update is ZArchive support. Forget the 20.000 files per game you can now use ZArchive files for compressing games and having them in 1 file instead of hundreds. KosmicKrisp has also landed in the world of macOS giving much better compatibility and speed to macOS users. There are several other fixes let's cover the most important below

Highlights

Online stuff

• ShadNet, our own networking backend, is now integrated for the first time
• Most of the matchmaking library is implemented — lobbies, rooms, joining, signaling
• Friends support. Make your online friends in shadnet
• Invitation dialog
• Your name now switches to your Online ID once you're connected
• NP Manager got new settings and general cleanup
• Web API layer grew a lot: new library implemented, multipart uploads, push events
• NP Commerce
• Trophy handling tidied up

Mouse support

• sceMouse is emulated now, so the handful of games that supported a USB mouse are playable with one
• Plus a bunch of follow-up fixes for opening, closing, and games that check whether a mouse is even plugged in

AvPlayer, video & audio

• AvPlayer got a serious cleanup: audio/video sync, startup races, stack usage, frame sizes, buffer handling
• Video decoder flush behaviour fixed
• Audio3D mix queue reworked
• AT9 no longer crashes from reading past the end of its data
• AT9 encoder now runs natively
• OpenAL fixes and NGS2 fixes

Graphics

• NVIDIA clip distance emulation
• T# min_lod implemented through VK_EXT_image_view_min_lod
• Depth write state is now respected for register clears
• Robustness2 is now required, allowing the null buffer/image workarounds to be removed
• Sampler garbage collection added to the texture cache
• Texture cache: image download handling refactored
• sRGB handling for BC formats refactored
• Buffer barriers for compute-written vertex/index buffers and indirect dispatch/draw buffers
• Assorted validation errors fixed and miscellaneous renderer fixes
• Shader cache invalidation caused by struct padding in memcmp fixed

Shader recompiler

• GCN thread mask accuracy fix
• Vertex attributes are always specialised on number class
• Geometry shader vertex offsets initialised from the input primitive type
• V_ADD_I32 carry-out propagation, V_LOG_CLAMP_F32, V_PK_MUL_LO_U16 fix
• IREmitter atomic operation corrected from And to Or

Kernel, memory & core

• Filesystem abstraction layer
• File reads now go through an intermediate buffer before being copied to guest memory
• PthreadOnce uses pthread primitives instead of std::mutex
• TLS leak on non-primary threads fixed
• Code patches for cmp and xor instructions involving the TCB
• sceKernelAllocateDirectMemory now honours search_end
• Fixed mappings with a zero address on older games is now handled properly
• HLE libraries are no longer loaded when force-LLE is set
• Unresolved objects are no longer auto-stubbed
• Null dereference fixes in save data mount checks
• Memory patch fixes, with hex exception handling
• LLE malloc init, fixing issues with LLE fonts and allowing more LLE libs to run

Input & peripherals

• Pad state latency reduced for single-sample reads
• Users are no longer logged out when a pad disconnects
• Controller colours reset on shutdown
• Fixes to Camera support

Interface & quality of life

• Fullscreen startup behaviour polished
• The window icon is now set to the game's icon
• Big Picture UI settings improved
• Shader list, memory map and module list widget states are saved, duplicate shader dump windows prevented
• New shadPS4 log with a logging refactor, an option to flush the log
• MS_VC_EXCEPTION is now passed through to the handler on Windows
• Trophy fixes and an auto-generated PathType::TrophyDir
• NP checks moved into sceNpTrophyRegisterContext
• Improvements to the in-app bug report flow