mirror of
https://github.com/Dingo-Shenanigans/ReSkate.git
synced 2026-10-22 06:08:07 +02:00
AyeZeeBB
3249f747dc
Most crashes are caught by the game's own fatal handlers, which write a dump of thread stacks only; the launcher could only copy it after the game had exited. A crash on a freed or overwritten object then showed the faulting registers but not the object or the list it came from. - game_fatal_dump: the game's MiniDumpWriteDump import points at ReSkate. Before the game writes its dump, the crash reporter takes its own of the still-running game for the faulting thread; the game's dump follows as before. Reports say capture.source "game-fatal-handler". - The reporter's dumps include the memory the stacks point at (MiniDumpWithIndirectlyReferencedMemory), a few MB more a report. - The shared report says who asked for the dump (protocol version 4). - Tests: a game-handler crash is captured with a heap block only its stack points at; ReSkate's own capture keeps it too.
13 lines
546 B
C++
13 lines
546 B
C++
#pragma once
|
|
|
|
#include <cstdint>
|
|
#include <string>
|
|
|
|
namespace dingosdk {
|
|
// When one of the game's fatal handlers is about to write its minidump, the crash reporter first
|
|
// takes its own of the still-running game (crash_report::capture_game_fatal), with the memory the
|
|
// stacks point at. Points the game's MiniDumpWriteDump import at ReSkate; the game's dump is
|
|
// still written after. Install after crash reporting has started, before the game runs.
|
|
bool start_game_fatal_dump(std::uintptr_t base, std::string& error);
|
|
} // namespace dingosdk
|