Observed a deterministic memory access violation (0x...200) during VRAM chunk deallocation on TF2 x64 using DXVK-Master 545
Update on the error message:
The dialog box in the screenshot translates to:
"The instruction at 0x00007FFA9B3D66A7 referenced memory at 0x0000000000000200. The memory could not be read."
This confirms a null pointer access during the map transition when chunks are being freed.
Please make an apitrace.
Got it. I'm currently occupied with another task, but I will prepare the apitrace and upload it as soon as possible. Thanks for the quick response!
@K0bin Here is the apitrace (Native D3D9) for TF2 x64: https://drive.google.com/file/d/12Am6Z-v977wPHqGkyKwLfC6lxCee3dLU/view?usp=drive_link
Captured during a server transition (Slender Fortress -> Local Map). The trace file is around 5.6GB (uncompressed), which includes heavy resource loading/unloading sequences.
Thanks, that sounds like exactly what we need! :)
Good luck! After all, with every new version of DXVK Master 2.7.1-521~545, the first thing I did was try to reproduce this (0x...200) READ problem. Today I finally mustered the courage to report this issue, and I can reproduce it repeatedly; it's definitely the error that occurs about 8 out of 10 times.
Update on DXVK Master 2.7.1-547:
Just tested with the latest Master build (2.7.1-547). Unfortunately, the 0x00...200 READ crash still occurs during map transition (Slender Fortress -> Local Map) with the same frequency.
This confirms that the recent commits didn't address the underlying D3D9 resource unloading issue. Still waiting for the large-scale resource reclamation fix. Good luck, K0bin!
I don't know what exactly made you think that any of the recent commits were supposed to address this particular issue?
Unfortunately the apitrace replays just fine. That complicates things a lot.
Unfortunately the apitrace replays just fine. That complicates things a lot.
"Since the trace replays fine on your end, it likely indicates a runtime race condition or timing-related deadlock that is highly dependent on local hardware/scheduling.
To help you look deeper, I will provide the following from my next reproduction:
A full Memory Dump (.dmp): I'll manually generate this via Task Manager while the error window is still active to capture the exact state of the crash.
DXVK Debug Log: I'll enable DXVK_LOG_LEVEL=debug to capture the final Vulkan commands leading up to the 0x...200 error.
Hopefully, these 'live' artifacts will be more useful than the static trace. Will upload them as soon as I have them!"
@K0bin dxvk log first up.
The log shows the process stopped during D3D9DeviceEx::ResetSwapChain. The .DMP file retrieved from Windows is being compressed and will be uploaded to the cloud later.
tf_win64_d3d9.log
@K0bin
DMP file is ready. > Compressed from 6GB to ~760MB.
Link:https://drive.google.com/file/d/1kSrzbj0CD3Vfkada4bvabMvFjc9JyojQ/view?usp=sharing
The log shows the process stopped during D3D9DeviceEx::ResetSwapChain. The .DMP file retrieved from Windows is being compressed and will be uploaded to the cloud later.
That doesn't mean anything, we just don't log in that many functions.
@doitsujin
Still crashes with Master 2.7.1-556 using the same method (SF -> Single Player). The 0x200 error remains exactly the same.
Interestingly, the HUD shows Descriptor usage is only 18 KB now, so the new architecture is definitely working, but it hasn't resolved this specific crash during the map transition.
New Full Dump (v2.7.1-556):
https://drive.google.com/file/d/1ByujQF7mihM4aSsSvpKuwSe16uWKo6Se/view?usp=sharing
Attached is the HUD screenshot at the moment of the crash.
[Update] Tested on commit ca8538f (558)
I’ve performed a stress test on this build. The Memory READ error during TF2 map transitions (switching from a Slender server to a local map) is now resolved.
According to the HUD (screenshot attached), the resource tracking and garbage collection logic are working much more reliably. The Vidmem heap is now properly managed and no longer runs away until crashing.
While the increased use of barriers (observed around 17) makes the resource hand-off feel a bit more "synchronous" and native-D3D9-like, the stability is a huge win for long sessions and map rotations.
Thanks for the fix!
One additional observation before closing:
While the stability is now excellent, I noticed that the current fix relies on a relatively high number of Barriers (around 17 in my tests). This introduces a slight but noticeable "synchronous feel" during resource transitions, somewhat reminiscent of native D3D9, especially the latency during map changes.
For future iterations, do you think it's possible to further optimize the Barrier Scheduling or implement Barrier Merging? I’d love to see if we can maintain this stability while reducing the sync overhead to achieve that ultra-low latency (low VAR) we saw in the earlier experimental stages.
Looking forward to seeing how the DXSO decoupling and the SPIR-V optimizations evolve alongside these memory management improvements!
Verification & Future Diagnostic Suggestion
Just wanted to confirm that after testing with the latest master (2.7.1-561), the memory access violation in Slender Fortress (TF2) has been effectively resolved. The resource tracking fix during defragmentation seems to be the "silver bullet" for these elusive crashes.
I've observed that the frame-time variance (var) is now significantly lower and more stable (hitting 0.15ms at times), and the memory management spikes feel much more "rhythmic" rather than chaotic.
A small suggestion for future-proofing: Since the Tracking ID system proved so critical here, would it be possible to eventually expose these IDs in the DXVK Log? Having the log output specific Resource IDs during allocation or synchronization failures would make it much easier for users to provide precise info, and for developers to pinpoint exactly which resource type is causing a regression in complex mods like SF.
Thanks again for the hard work on this fix!
Launch options
DXVK_LOG_LEVEL=debugx1 2026-04
Software information
team fortress 2
System information
Issue
After entering the unofficial Team Fortress 2 community server, Slender Fortress server, exiting and immediately starting a single-player map will result in error code 0x0000000000000200 (READ).
Slender Fortress server IP : 74.91.113.50:27019
GAME START
IN SLENDER FORTRESS
OUT SLENDER FORTRESS START open map crash
tf_win64_d3d9.log