HivePaaS
Docker Swarm 기반 오픈소스 자체 호스팅 PaaS, SSL·백업·자동 확장 지원
Windows·Linux·macOS 크래시 덤프를 업로드하여 분석합니다
Upload a Windows or Linux crash dump or a macOS crash report; DumpTriage analyses it and sends back a root-cause report. Free during the pilot, with five design-partner places that add human review.
개발 도구C# · PythonGitHub @performanceinsights-ai온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기Crash dump capture scripts and agents for Windows and Linux, for DumpTriage (AI crash dump analysis)
저장소 README에서 가져옴
README 전체를 불러오는 중입니다.
README 전문 보기 ↗Scripts and agents for capturing crash dumps on Windows and Linux (and crash reports on macOS) and sending them to DumpTriage, which analyses crash dumps with AI and returns a root-cause report: Windows BSOD memory dumps, minidumps (.dmp) and Linux core dumps.
The capture scripts work on their own. You don't need DumpTriage to use them: they only make sure a crash leaves a dump you can open in WinDbg, gdb or crash.
| Script | What it does |
|---|---|
windows/Set-WerLocalDumps.ps1 | Windows Error Reporting LocalDumps: full user-mode dumps of crashing processes to a folder you choose |
windows/Set-WerLiveKernelReports.ps1 | Live kernel reports: kernel dumps Windows takes while it keeps running (for example after a driver timeout), and how often it may take them |
linux/configure-dumps.sh | Raw ELF process cores, unlimited core size, retention, and optionally kdump for kernel crashes |
windows/Start-PerfTrace.ps1 | Performance traces: one WPR capture with PerfInsights.wprp while you reproduce the problem, zipped with its manifest, and -Upload to send it (no agent needed) |
linux/configure-tracing.sh | Performance traces: installs perf, checks tracefs and frame pointers, and --capture SECONDS takes one manual capture with the upload command (no agent needed) |
Send dumps or reports without installing an agent.
| Script | What it does |
|---|---|
macos/dumptriage-collect.sh | Lists the last week's macOS crash reports, kernel panics and spin/hang reports, lets you pick, and asks before sending. --spindump samples a hanging app now; --profile, --sample and --xctrace send a timed performance capture (system-wide spindump, sample, Instruments' Time Profiler folded on the Mac) as a performance trace |
rmm/ninjaone/Invoke-DumpTriageCollect.ps1 | A NinjaOne Script Library script: sends each device's new minidumps on a schedule and writes the report link into a custom field (setup) |
Background agents that watch for new dumps, decide by policy whether to submit them (always, ask first, notify only, or rules), and upload them to the DumpTriage API.
windows/dumptriage-agent/: Windows service and tray app (C#, .NET 8)linux/dumptriage-agent/: a single Python 3 file using only the standard library. It runs as a systemd service, a systemd user service, or from cronAn agent needs an API key from DumpTriage; the API docs describe the endpoints it uses.
Every release carries each script
on its own, the Windows agent built (dumptriage-agent-windows-x64.zip: agent, tray app and installer), the Linux
agent with configure-dumps.sh and configure-tracing.sh (dumptriage-agent-linux.tar.gz), and SHA256SUMS. The newest of each is always at
https://github.com/performanceinsights-ai/dumptriage-tools/releases/latest/download/<file>, and listed on
performanceinsights.ai/downloads. A v* tag publishes a release
(.github/workflows/release.yml).
Each asset carries a build-provenance attestation from that workflow (#65). SHA256SUMS sits in the same release, so
it only catches a broken download; the attestation shows the file was built by this repository's release workflow:
gh attestation verify dumptriage-agent-windows-x64.zip -R performanceinsights-ai/dumptriage-tools
Automated performance-trace capture (website#1999) is defined once here so the three platforms cannot drift:
schemas/tracing-config.schema.json: the tracing config section (off by default,
backend, triggers[], limits, submission policy defaulting to AskFirst). Same keys in the Windows agent, the Linux
agent and ~/.config/dumptriage/tracing.json on macOS.schemas/trace-manifest.schema.json: the manifest.json uploaded with every trace.
It carries the host token, never the hostname.tests/fixtures/tracing/triggers.json: metric series in, fire / no_fire /
cooldown / capped out. Its semantics list defines the rules; the Python suite holds a reference evaluator, and every
platform's trigger loop is tested against every case.Both schemas are release assets, and the website copies them for its own validation.
python3 -m unittest discover -s linux/dumptriage-agent/tests
dotnet test windows/dumptriage-agent/tests/DumpTriage.Common.Tests
dotnet test windows/dumptriage-agent/tests/DumpTriageAgent.Tests
pwsh -NoProfile -File windows/dumptriage-agent/installer/tests/Test-Install.ps1
bash macos/tests/test_collect.sh
bash linux/tests/test_configure_tracing.sh
bash linux/tests/test_install_perfetto.sh
pwsh -NoProfile -File rmm/ninjaone/tests/Run-Tests.ps1
.github/workflows/macos-trace-capture.yml (run by hand from the Actions tab, and on a PR that changes it or
macos/tests/burn.c) captures real spindump, sample and
xctrace output on GitHub's macOS 14, 15 and 26 runners and keeps it as a build artifact for 30 days, for testing the
service's macOS trace parsers on current macOS output (#41).
Report vulnerabilities to [email protected] (subject "Security"), not in a public issue.