NationalSecurityAgency/ghidra · warning · InvalidDataException

MinGW pseudo-relocation list not found

Error message

MinGW pseudo-relocation list not found

What it means

Thrown as InvalidDataException by findUnlabeledPseudoRelocList when findUnlabledType1PseudoRelocList returns false — the analyzer could not locate the type-1 pseudo-relocation list by scanning .rdata and labels were not already present. It means the binary either is not MinGW-compiled or its pseudo-reloc list is not in the expected form.

Source

Thrown at Ghidra/Features/Base/src/main/java/ghidra/app/plugin/core/analysis/MingwRelocationAnalyzer.java:173

	private void findUnlabeledPseudoRelocList64Bit(TaskMonitor monitor)
			throws InvalidDataException, CancelledException {

		findUnlabeledPseudoRelocList(monitor);

	}

	private void findUnlabeledPseudoRelocList32Bit(TaskMonitor monitor)
			throws InvalidDataException, CancelledException {

		findUnlabeledPseudoRelocList(monitor);
	}

	private void findUnlabeledPseudoRelocList(TaskMonitor monitor)
			throws InvalidDataException, CancelledException {

		//TODO: find a way to recognize type0 ones
		if (!findUnlabledType1PseudoRelocList(monitor)) {
			throw new InvalidDataException("MinGW pseudo-relocation list not found");
		}
		createPrimaryLabel(pdwListStartAddr, PSEUDO_RELOC_LIST_START_NAME);
		createPrimaryLabel(pdwListEndAddr, PSEUDO_RELOC_LIST_END_NAME);
		listLabelsFound = true;
	}

	private boolean findUnlabledType1PseudoRelocList(TaskMonitor monitor)
			throws CancelledException {

		MemoryBlock block = program.getMemory().getBlock(".rdata");
		if (block == null) {
			Msg.error(this, "Cannot find a .rdata block");
			return false;
		}

		// first look backwards from end of .rdata to find the last occurance of "GCC:" in the
		// .rdata block
		byte[] gccBytes = "GCC:".getBytes();

View on GitHub (pinned to d5f144c24d)

Solutions

  1. Confirm the binary was produced by MinGW (check compiler metadata); disable the analyzer otherwise.
  2. If labels are expected, add __RUNTIME_PSEUDO_RELOC_LIST_START__/__END__ labels manually so the labeled path succeeds.
  3. Re-import the PE ensuring the .rdata section is present and loaded.
  4. Catch InvalidDataException and continue analysis without pseudo-reloc relocations.

Example fix

// before — analyzer throws during auto-analysis on a non-MinGW binary
new MinGWPseudoRelocList(program, monitor);

// after — guard with analyzer applicability and tolerate failure
if (!MingwRelocationAnalyzer.isMinGwBinary(program)) {
    return; // not applicable
}
try {
    new MinGWPseudoRelocList(program, monitor);
} catch (InvalidDataException e) {
    log.appendMsg("No MinGW pseudo-reloc list: " + e.getMessage());
}
Defensive patterns

Strategy: try-catch

Validate before calling

// confirm MinGW provenance and .rdata presence before constructing
if (!MingwRelocationAnalyzer.isMinGwBinary(program)
    || program.getMemory().getBlock(".rdata") == null) {
    return; // analyzer not applicable
}

Type guard

boolean applicable = MingwRelocationAnalyzer.isMinGwBinary(program) && program.getMemory().getBlock(".rdata") != null;

Try / catch

try {
    new MinGWPseudoRelocList(program, monitor);
} catch (InvalidDataException e) {
    log.appendMsg("No MinGW pseudo-reloc list: " + e.getMessage());
}

Prevention

When it happens

Trigger: The type-1 pseudo-reloc discovery scan (findUnlabledType1PseudoRelocList) fails: .rdata block absent, the expected header pattern not found, or the monitor cancelled the scan before completion. findLabeledPseudoRelocList also returned false (no labels), so the unlabeled path is the last resort and it failed.

Common situations: Running the MinGW analyzer on a non-MinGW PE or an ELF; an older/newer MinGW runtime that uses type-0 relocations (the TODO notes type-0 is unrecognized); a stripped binary whose .rdata heuristic no longer matches; very small binaries with no .rdata.

Related errors


AI-assisted analysis of NationalSecurityAgency/ghidra@d5f144c24d (2026-08-14). Data as JSON: /api/errors/387e7e30f100586f. Report an issue: GitHub.