## TL;DR
Masscan holds results in memory and writes the output file when the scan finishes, so a crash, a kill, or a full disk leaves a 0-byte file. Always write a live text log alongside the binary output, then re-run in smaller rate-limited chunks so a failure costs minutes instead of the whole scan.

```text
(output file is 0 bytes after masscan exits abnormally)
```

## Use this when
- `-oB scan.bin` or `-oX scan.xml` exists but is empty after an interrupted authorized scan.
- You need the partial results back or a safe way to re-run.

## Not for this skill when
- Masscan completed and reported zero open ports. An empty result set is a finding, not this bug.
- The file has content but will not parse. That is corruption, a different fix.

## Steps
1. Confirm the file is truly empty and the scan died early: `ls -la scan.bin`, and check whether any masscan process is still alive. Verify: 0 bytes and no running process means the flush never happened.
2. Check the boring causes first: `df -h` on the output filesystem and write permission on the directory. Verify: the disk is not full and the file is writable before re-running.
3. Re-run with dual outputs: `-oB scan.bin -oL scan.log`. Verify: the text log grows during the scan, so even another crash leaves you the live results.
4. Split the range and lower the rate: scan the subnet in halves at a moderate rate instead of one giant fast run. Verify: each chunk finishes and writes its own complete file.
5. Merge chunk logs by concatenating the text logs and de-duplicating the host and port lines. Verify: the merged set matches the sum of the chunk counts.

## Variant phrasings
### masscan binary output empty file
The -oB-specific phrasing.
### masscan killed output not saved
The interrupted-scan phrasing.
### masscan xml output 0 bytes
The -oX-specific phrasing.

Compatibility: masscan 1.3.x. The binary, XML, and list outputs all flush at exit; only the list log streams usefully during the run.

## Why it happens
For speed, masscan buffers everything and serializes once at clean exit. An out-of-memory kill, a closed laptop lid, or a full disk skips that final write entirely. The scan did the work; the evidence just never landed on disk.

## Edge cases / pitfalls
- The text log is lossier than the binary output, with fewer fields per record. Keep both when the binary format matters for your pipeline.
- Re-running the same huge range at the same rate invites the same crash. Change something, rate, chunks, or box memory, or expect a repeat.
- An empty output file plus a completed-looking log line can fool an agent into reporting "no open ports". Check the exit status before trusting the file.
- Note the failure in the engagement log: a re-run that silently replaces a crashed run hides the instability from the report reviewer.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xycAOFOhpnsuWWuoqHEVpg