Repository navigation
Crash-report requests should warn that a Windows minidump carries the process environment block #174
Description
Splitting this out of #150 at your suggestion.
The problem
"wmux crashed, here's a dump" is a request maintainers make casually, and users comply casually. On Windows, a WER minidump includes the process environment block. User-scope environment variables are inherited by every process on the machine, so a dump from a developer's machine carries every secret that machine keeps in its environment — in cleartext, in a file the user is about to hand to a stranger and, more often than not, attach to a public issue.
This is not hypothetical. When I went looking through the eight dumps in #150 before uploading them, every one carried live credentials. The worst held eleven, including a production API key/secret/passphrase set and a bot token. I found that only because I stopped to check; my honest read is that if I'd been in a hurry I would have dragged the files into the attachment box and shipped the lot.
Why this is worth a warning from wmux specifically
wmux is a terminal multiplexer. Its users are, by construction, developers who keep credentials in the environment so the shells wmux spawns can see them. That's not a misconfiguration — it's the normal setup for the exact population most likely to file a crash report here. The overlap between "people who will hit a crash" and "people whose environment is full of live keys" is close to total.
Hand-scrubbing is not a safe workaround
Worth stating so it doesn't get suggested as the fix: rewriting byte ranges inside a minidump's MemoryList to blank out secrets risks producing a file that opens cleanly and analyses wrong. A subtly corrupted dump is worse than no dump, because it wastes the maintainer's time on a fake stack. If a dump can't be shared safely, the answer is not to sanitise it.
Suggested remedies — any one of these would help
- Ask for the Event Log line first. For a repeatable crash,
Faulting module name,Exception code,Fault offsetand theAdditional parameterare often enough to fingerprint it and tell same-signature from new. They carry no secrets. In bug(pty): uncaught Napi::Error from conpty.node aborts the main process — 12 crashes, one signature (0.10 → 0.41) #150 that line alone turned out to be sufficient to answer the question the dump was originally wanted for. - Warn at the point of asking. Wherever the crash-report ask lives — issue template, docs, the message the app shows after a crash — one sentence: a Windows minidump contains your environment variables; check before uploading, and say so if you'd rather not.
- If a dump is genuinely needed, say what's in it. Then the user can decide, or reproduce under a clean profile with a stripped environment and send that instead.
Activity
feat(crash): make the safe crash report the easy one (#174)
amirlehmam commentedon Aug 16, 2026
Shipped in 1.2.0 — and thank you for writing it, after I said twice I would and twice didn't.
You were right that the concrete case is what makes it more than a policy note. "Eleven live credentials including a trading key set, in a file I was casually asking you to send" is the version people act on.
Where I went past the ask
Your remedy 2 was "warn at the point of asking". I did that, but a warning alone leaves the dump as the path of least resistance, and I don't think that changes anyone's behaviour under time pressure — including, by your own account, yours.
So remedy 1 is the one I built.
wmux crash-report:$ wmux crash-reportIt needs no running wmux, which is the point — you run it after wmux died. It prints the Event Log fingerprint and the tail of
%APPDATA%\wmux\logs\main.log, and nothing else.Two things only a live run exposed, and both would have made it useless in exactly the situation it exists for:
It was parsing the localised message. I wrote it against the English labels in your report. On the machine I tested on the Event Log says
Nom du module défaillant, so every field came back(not found)while the command looked like it had worked. It now reads the events' positionalProperties— the raw insertion strings — which are language-independent. That also means the executable and module paths are never read at all rather than stripped after the fact, which matters here: those carry the home directory, and the Windows username in it is usually a real name.Substring-matching
wmux.exeattributed someone else's crash. A sibling project of mine at...\newmux\smux.exewas being reported as a wmux crash, with a fault offset identical to the one #150 is about. A crash report that confidently hands the maintainer another program's crash is worse than no report. It matches the app-name property exactly now.The
Additional parameter— the field that says0xc0000409was a deliberate__fastfail(7)— lives only in the Windows Error Reporting 1001 record, not in Application Error 1000, so the two providers are joined on their shared report id rather than by timestamp proximity.Your warning, in the places you asked for it
docs/crash-reports.md— what a minidump contains, why this project's users are the worst possible population for it, and why hand-scrubbing is worse than sending nothing (your argument, kept).wmux crash-report, and tells you how to read the four fields by hand if the CLI isn't available.DumpType = 2. Someone who turned that on did it because a maintainer asked, which makes them precisely the person about to hand the file over.The part of your follow-up that I think is the sharpest, and nearly wasn't in here
From your #150 comment:
That is the one I would have got wrong. It is documented prominently, with your case attached — you had already migrated all eleven credentials out of your environment, and found all eleven in a dump taken hours later. The person in this thread who knew most about the problem still had to scan the file to catch it. "I've rotated my secrets, so the dump is safe" is false until every affected process has been restarted, and reasoning about it is not good enough.
What I did not do
I did not add an in-app crash dialog. wmux dies by
abort()in #150 — there is no process left to show anything. A dialog on next launch would be honest but would arrive minutes to days after the moment it matters, and the surfaces above cover the point of asking. If you think that's the wrong call, say so.On #150
Filed upstream: microsoft/node-pty#951. Your
'An exception is pending'finding turned out to be provable rather than indicative, and it unified this with an open macOS issue there. Details in that thread.fix(updater): log a code for a failed sweep, never the message