Diagnostic bundle

The format of a diagnostic bundle: the zip that a bug report, a crash report or system.diagnostics.collect makes. This page lists its folders, its sources, its limits and its manifest.

Where a bundle is

The folder tree

manifest.json                 what the bundle holds, what it lacks, what was cut
report.json                   trigger, cause, the user's text, app, created time
build/identity.json           version, commit, build id, variant, toolchain, edition
system/os.json                OS name, version, architecture, locale, memory
system/graphics.json          backend, adapters, the chosen adapter
system/screens.json           each screen: size, DPI, refresh rate
logs/run.log                  the log file of the reported run
logs/previous-run.log         the log file of the run before it, in a crash report
crash/marker.txt              the crash marker
crash/exit-code.txt           Windows: the exit code that the crash sentinel recorded
crash/sentinel.dmp            Windows: the crash sentinel's minidump
crash/wer.dmp                 Windows: a Windows Error Reporting dump of the same run
crash/coredumpctl.txt         Linux: coredumpctl info for the crashed process
history/runs.json             how the last 20 runs ended
settings/settings.json        every setting that is not secret, with its value and level
screenshot/window.png         the main window
opal/                         text files that an OPAL task attached

A file that does not apply is absent, and the manifest names it in missing with the reason. For example, a user report of a healthy run has no crash/ folder.

The sources

Each file belongs to one source. The composer shows a check box for each source that you can remove.

The trigger names who made the bundle: crash at the next start after a crash, user from Send bug report…, opal from an OPAL task, and startup from the startup logs of a debug build.

Limits

When a bundle is over the total, the files are cut in this order until it fits:

1. logs/previous-run.log
2. crash/wer.dmp, when crash/sentinel.dmp exists
3. history/
4. The start of logs/run.log. The end stays, because the end of a log holds the failure
5. crash/wer.dmp
6. crash/sentinel.dmp

report.json, manifest.json, build/ and system/ are never cut. Each cut is recorded in the manifest with its reason.

The manifest

manifest.json, version 1:

Member formats

Every JSON member is UTF-8 without a byte order mark. A time is RFC 3339 UTC with Z and whole seconds, for example 2026-10-09T18:30:00Z. A value the app could not find is null. Keys are never translated.

report.json

build/identity.json

system/os.json

system/graphics.json and system/screens.json

graphics.json holds the keys of system.graphics.report, with typed values, and adapters: an array of objects with name, deviceType and chosen.

screens.json is an array, one object per screen: name, widthPx, heightPx, devicePixelRatio, logicalDpi, refreshHz and primary.

These two are read on the user interface thread. A bundle made without it names them in missing.

history/runs.json

An array, newest first, one object per run: start, pid, app, version, buildId, verdict (clean, crash or unclean-exit) and logFile (the file name only).

settings/settings.json

An array, one object per setting that is not secret: key, value (a boolean, number or string, as the setting's kind; a choice is its string) and level (the level that supplied the value). A secret setting is named in missing with the reason "secret".

Log files

The lines of the app's log format. The collector copies the bytes before the first NUL, because the log file is padded with zeros, and bytes in the manifest is the size after that cut.

crash/exit-code.txt

Two key=value lines: code=0x followed by 8 hexadecimal digits, and name= followed by the Windows status name, or unknown.

Privacy

See also

• Diagnostic reports
• Send a bug report
• OPAL system tasks