Filed as FB24422691. Posting here as well because the crash leaves no usable stack in the application's own crash handler, and searching for "0x1BFFFFFFE4" or "FindClosestMatchingMode" returns nothing anywhere, so this may save someone else the debugging. SYMPTOM A Direct3D 11 Windows application (Unity 2021.3) running fullscreen under Game Porting Toolkit dies when you Cmd+Tab out of it and back in. Exclusive and borderless fullscreen both crash; windowed never does. It is intermittent: on my machine it takes 5 to 9 switches. Always the same signature: EXCEPTION_ACCESS_VIOLATION (0xC0000005), reading address 0x1BFFFFFFE4, faulting RIP at D3DMetal+0xFA8F. Identical in all 16 crash reports I collected, which is what makes it a deterministic underflow rather than heap corruption. CAUSE D3DMetal's DXGIOutput::FindClosestMatchingMode calls GetDisplayModeList and then reads the last element of the list without checking the count or the buffer pointer: call DXGIOutput::GetDisplayModeList(...) ; count returned in [rsp+0x3c] mov eax, [rsp+0x3c] ; eax = count dec eax ; 0xFFFFFFFF when count == 0 lea rcx, [rax + 8rax] ; rcx = 28 * eax (28 = sizeof DXGI_MODE_DESC) lea rcx, [rcx + 2rcx] add rcx, rax mov rax, [r14 + rcx] ; reads modes[-1] 28 * 0xFFFFFFFF = 0x1BFFFFFFE4, and r14 (the mode buffer) is NULL on that path, so the read lands exactly on the address seen in the crash reports. WHY THE LIST IS EMPTY winemac.drv rebuilds the display device list on every application activation. With WINEDEBUG=+display, four Cmd+Tab activations produce exactly four full rebuilds (macdrv_UpdateDisplayDevices: GPU count, adapter, monitor). An application that queries the closest matching mode mid-rebuild gets zero modes back. Fullscreen makes that query on focus changes; windowed does not, which is exactly why windowed never crashes. The empty-list condition is not unique to this race: GetDisplayModeList has also been reported returning 0 modes for DXGI_FORMAT_R16G16B16A16_FLOAT on D3DMetal 2.1 (github.com/vec715/enfusion-dxgi-fix). DXVK and DXMT both return DXGI_ERROR_NOT_FOUND for an empty list instead of dereferencing it. MEASUREMENTS Alternating applications automatically and verifying every focus change: borderless fullscreen: crash after 5, 6, 6 and 8 switches (4 of 4 runs) exclusive fullscreen: crash after 9 switches windowed: 105+ switches, no crash As a control I patched a local copy of D3DMetal so the read is skipped when count == 0 or the buffer is NULL, keeping the requested mode. Same machine, same setup: 140 switches in fullscreen with no crash, and the unpatched binary crashed again after 8 switches immediately afterwards. VERSIONS The unchecked read is present in both D3DMetal builds I have: 2.0 (built for macOS 13.3) at 0x1453A, and 3.0 (built for macOS 15.4) at 0xFA82. Environment: macOS 26.5.2 (25F84), Apple M5, D3DMetal 3.0 inside Game Porting Toolkit, Wine 7.7, 64-bit prefix, fullscreen at 2560x1664 with winemac.drv Retina mode on. WORKAROUND UNTIL IT IS FIXED Run the application windowed, or interpose a dxgi proxy DLL that returns DXGI_ERROR_NOT_FOUND from FindClosestMatchingMode when the mode count is 0. Suggested fix: return DXGI_ERROR_NOT_FOUND from FindClosestMatchingMode / FindClosestMatchingMode1 when the count is 0 or the buffer is NULL, instead of indexing modes[count-1].