In RE Engine modding, data is everything. When something breaks, “it crashed” doesn’t tell a developer anything useful. What they actually need is the black box of your session: the log file and, if the game went down completely, the crash dump. This guide covers exactly where those files live and how to put together a bug report that doesn’t get lost in the queue.
What the diagnostic files actually contain
REFramework generates two files that matter for troubleshooting, and knowing what each one captures helps explain why developers ask for them specifically instead of a screenshot or a two-line description.
re2_framework_log.txt is the session’s activity log. It records the game version, which REFramework build you’re running (stable or nightly), basic hardware info, every Lua script and plugin that loaded, and the sequence of internal events leading up to whatever went wrong. One quirk worth knowing: this file is named re2_framework_log.txt regardless of which RE Engine game you’re actually playing, so don’t assume you’re looking at the wrong file just because you’re troubleshooting Resident Evil 4 or Monster Hunter Wilds and see “re2” in the filename.
reframework_crash.dmp only gets created if the game crashed all the way to desktop. It’s a memory dump captured at the exact moment the exception occurred, which lets a developer see precisely which function was executing when things fell apart. Between the two files, a developer gets a nearly complete picture of what happened, which is a lot more useful than trying to describe a crash after the fact from memory.
Finding the files on Windows
For a Steam or standalone PC install, both files sit in the game’s root folder, in the same directory as the executable.
- Open Steam
- Right-click the game in your library
- Select Manage, then Browse local files
- Look for
re2_framework_log.txtandreframework_crash.dmpin the folder that opens
If you don’t see file extensions on either name, Windows Explorer is probably hiding them by default. Turn that on through View, then File name extensions, and both files should become visible.
Finding the files on Steam Deck and Linux
Proton runs Windows games inside a virtual Windows environment called a prefix, and REFramework’s files end up inside that prefix rather than anywhere you’d normally look on a Linux filesystem. The path follows this pattern:
~/.local/share/Steam/steamapps/compatdata/[AppID]/pfx/drive_c/
Replace [AppID] with the Steam App ID for your specific game. A few common ones:
| Game | Steam App ID |
|---|---|
| Resident Evil 2 | 883710 |
| Resident Evil 4 | 2050650 |
| Monster Hunter Wilds | 2246340 |
App IDs for newer titles are worth double checking on SteamDB before you go looking, since a wrong ID just leads to an empty or nonexistent folder. Once you’re in the right compatdata folder, the log and dump files sit in the game’s root directory the same way they would on a native Windows install.
Writing a bug report that gets taken seriously
Once you have both files, how you present them matters almost as much as having them in the first place. Bug reports that get resolved quickly tend to share a few habits, and reports that stall usually share the opposite ones.
Worth doing every time:
- Upload the entire log file, not just the last few lines. Developers need the full boot sequence, hardware info, and script load order, and a snippet with none of that context is often useless
- Attach the
.dmpfile whenever one exists. It’s frequently more valuable than the log itself, since it points directly at the function that failed - State your exact REFramework version or build number, rather than just “the latest one,” since “latest” changes by the day on nightly builds. If you’re not sure how to check this, the documentation covers where the version number shows up in the menu
- Write specific reproduction steps. “Load save, open inventory, press Tab, instant crash” gives a developer something to test immediately, while “it just crashes sometimes” does not
Worth avoiding:
- Don’t post log snippets or screenshots of the console instead of the actual file
- Don’t open a duplicate issue if one already exists for the same problem. Commenting on the existing thread with your own log keeps everything in one place
- Don’t skip basic details like your OS version or exact game build, since the same crash can have different causes on different platforms
Reports also belong on the project’s GitHub issues page rather than as comments on a Nexus Mods page or forum thread, since that’s where the actual maintainers are looking and where a fix can be tracked over time.
Conclusion
A complete bug report is the difference between a fix landing in the next update and an issue sitting untouched for months. The log file and crash dump together give a developer the exact sequence of events and the exact point of failure, which is far more useful than any description written after the fact. Finding both files takes under a minute once you know where to look, whether that’s the game’s install folder on Windows or the Proton prefix on Steam Deck, and attaching them alongside clear reproduction steps is what actually gets an issue looked at rather than skipped over.