Device Info Collection for Better Bug Reports in Games

This guide covers device info collection for better bug reports in detail. A player reports that the game crashes on startup. Without device information, the developer has nothing to work with. Is it a GPU driver issue? An unsupported OS version? Insufficient RAM? With device information collected automatically, the developer can immediately see that the player is running an integrated Intel GPU with outdated drivers, narrow the investigation to a known shader compatibility issue, and ship a fix within hours. The difference between these two scenarios is a few lines of code that collect system data when the bug report form opens.

What Data to Collect

Not all device information is equally useful for debugging. Collecting too much creates noise; collecting too little leaves gaps. After analyzing thousands of bug reports across studios using Bugnet, we have identified the data points that most frequently help developers resolve issues.

Essential data (collect for every report):

// Essential device info for every bug report
{
  "os":             "Windows 11 23H2",
  "cpu":            "AMD Ryzen 7 5800X (16 logical cores)",
  "gpu":            "NVIDIA GeForce RTX 3070",
  "gpu_driver":     "546.33",
  "ram_total_mb":   16384,
  "ram_available_mb": 8192,
  "display":        "2560x1440 @ 144Hz",
  "graphics_api":   "Vulkan 1.3",
  "game_version":   "0.9.4-beta.2 (build 1847)",
  "quality_preset": "High"
}

GPU and driver version are the most frequently useful fields. Rendering bugs are overwhelmingly driver-specific. A bug that manifests on NVIDIA driver 537.58 but not on 546.33 tells the developer immediately that the issue is a known driver bug with a simple fix: advise the player to update. Without the driver version, the developer might spend days investigating their own shader code.

RAM availability matters more than total RAM. A player with 16 GB of RAM but only 2 GB available due to other running applications will experience out-of-memory crashes that are not reproducible on a development machine with clean memory. Capturing available RAM at the time of the report identifies memory pressure issues that total RAM alone would not reveal.

Graphics API is critical for games that support multiple rendering backends. A bug that occurs only on Vulkan but not on DirectX 12 points the developer to the Vulkan-specific code path. Without this information, the developer has to test every backend to identify which one is affected.

Platform-Specific Collection

Each game engine provides different APIs for querying system information. Here is how to collect the essential data in the three most common engines.

Godot 4:

func collect_device_info() -> Dictionary:
    return {
        "os": OS.get_name() + " " + OS.get_distribution_name(),
        "cpu": OS.get_processor_name(),
        "cpu_cores": OS.get_processor_count(),
        "gpu": RenderingServer.get_video_adapter_name(),
        "gpu_vendor": RenderingServer.get_video_adapter_vendor(),
        "gpu_api": RenderingServer.get_video_adapter_api_version(),
        "display": str(DisplayServer.screen_get_size()),
        "locale": OS.get_locale(),
        "game_version": ProjectSettings.get_setting(
            "application/config/version")
    }

Unity:

public static Dictionary<string, string> CollectDeviceInfo()
{
    return new Dictionary<string, string>
    {
        ["os"] = SystemInfo.operatingSystem,
        ["cpu"] = SystemInfo.processorType,
        ["cpu_cores"] = SystemInfo.processorCount.ToString(),
        ["gpu"] = SystemInfo.graphicsDeviceName,
        ["gpu_driver"] = SystemInfo.graphicsDeviceVersion,
        ["gpu_memory_mb"] = SystemInfo.graphicsMemorySize.ToString(),
        ["ram_mb"] = SystemInfo.systemMemorySize.ToString(),
        ["display"] = $"{Screen.width}x{Screen.height} @ {Screen.currentResolution.refreshRate}Hz",
        ["graphics_api"] = SystemInfo.graphicsDeviceType.ToString(),
        ["game_version"] = Application.version
    };
}

Both approaches take less than a millisecond to execute and produce zero allocations on subsequent calls if you cache the result. There is no performance reason to skip device info collection.

Mobile-Specific Considerations

Mobile games need additional data points that desktop games do not. The device model is essential because mobile GPUs vary dramatically even within the same manufacturer. An Adreno 640 in a Samsung Galaxy S10 behaves differently from an Adreno 730 in a Galaxy S22, and both differ from Apple’s A-series GPUs. On desktop, GPU model and driver version are sufficient; on mobile, the specific device model is the primary debugging axis.

Battery level and thermal state affect performance in ways that are invisible on desktop. A phone at 5 percent battery and high temperature will throttle the CPU and GPU aggressively, causing frame rate drops and timeouts that do not occur under normal conditions. If your bug report includes this data, a developer can quickly identify whether a performance report is a real issue or a thermal throttling artifact.

Available storage matters on mobile because many games cache assets to local storage. A device with less than 500 MB of free storage may fail to download updates, fail to save game state, or exhibit loading errors that appear as bugs. Capturing free storage eliminates this common source of confusion.

Privacy Considerations

Device information collection is generally low-risk from a privacy perspective because it describes the hardware and software environment, not the user. However, there are best practices to follow. Do not collect unique device identifiers (IMEI, serial number, MAC address) unless absolutely necessary for debugging a specific issue. Always show the user what data will be sent before they submit the report. Store device data alongside the bug report only, not in a separate analytics database. If your game operates in the EU, ensure your privacy policy covers device data collection and that it is covered under the necessary consent mechanisms.

Transparency builds trust. When players can see that you are collecting “GPU: NVIDIA RTX 3070, Driver: 546.33” and nothing personally identifiable, they are more likely to submit reports and to appreciate that the information helps you fix their issues faster.

“After adding automatic device info collection, 30 percent of our incoming crash reports were immediately identifiable as outdated GPU driver issues. We added a driver check to our launcher and those reports dropped to near zero.”

Using Device Data for Pattern Detection

Beyond individual bug reports, aggregated device data reveals patterns that single reports cannot. If 80 percent of crash reports come from players running Intel integrated graphics, you know that GPU family needs special attention. If frame rate complaints cluster around a specific NVIDIA driver version, you can add that version to a known-issues list and notify affected players.

This kind of pattern detection requires that device data is structured and queryable. Store it as individual fields in your bug tracking database, not as a single text blob. This lets you filter, sort, and aggregate by any dimension: GPU vendor, driver version, OS, RAM range, or any combination. The investment in structured storage pays for itself the first time you can query “show me all crash reports from players with AMD GPUs on Linux” and get an instant answer.

Related Issues

For guidance on tracking performance problems across hardware configurations, see how to track game performance issues across devices. To set up crash reporting that captures device data alongside stack traces, read how to set up crash reporting for indie games. For collecting crash logs across multiple platforms, check cross-platform crash log collection for games.

Add device info collection to your bug reporter today. It is fewer than 20 lines of code in any engine, and it will make every single bug report your players submit more useful.