On Windows, upgrading from Go 1.24.6 to 1.25.0 caused our builds to produce executables that refuse to run. The loader immediately shows the generic dialog:

This app can't run on your PC. To find a version for your PC, check with the software publisher.

Environment: go version go1.25.0 windows/amd64

What happens: Go 1.25.0 internal linker emits an EXE that the Windows loader rejects.

PE header inspection shows the binary is malformed:

  • SizeOfHeaders = 1352 while FileAlignment = 512. Per the PE/COFF spec, SizeOfHeaders must be rounded up to a multiple of FileAlignment (expected 1536).
  • The first three sections have PointerToRawData values not aligned to 512 (raw_ptr % 512 = 328).
  • These three sections also have names like /4, /20, /36 and VirtualAddress = 0xC0000000, which are long-name placeholders from COFF object files. These should not appear in a final PE image.
  • As a result, the Windows loader refuses to start the EXE before user code runs.

The same project built with Go 1.24.6 produced a valid EXE with correct header padding and section alignment.

What should happen:

The internal linker should always write a valid PE that the Windows loader accepts, as it did in Go 1.24.x.

Workarounds that succeed:

Stripping debug info at link time produces a working EXE: go build -ldflags="-H=windowsgui -w -s" .

(-H=windowsgui selects the GUI subsystem; -w -s omits DWARF debug data and symbol tables, which avoids the buggy layout.)

Forcing external linking with MSVC also produces a working EXE: go build -ldflags="-linkmode external -H=windowsgui" .

Staying on Go 1.24.6 also works.

Notes:

Go 1.25 defaults to generating DWARF v5 debug information. The issue seems to occur only when debug/symbol sections are included; stripping them avoids the misalignment. That suggests the problem is in how the internal Windows linker lays out headers/sections when debug info is present.

Comment From: thanm

@syllith just to clarify, the application you are building uses CGO, correct? With CGO the default is external linking, not internal linking. It would be helpful if you could post the complete "go build" command line for the faulting build. Thanks.

Comment From: syllith

@thanm Yes, I'm using CGO. My apologies, I meant to say that only internal works, external does not. I had some confusion when creating so many builds when testing.

go build -ldflags="-linkmode internal -H=windowsgui" . Works

go build -ldflags="-H=windowsgui -w -s" . Works

go build -ldflags="-linkmode external -H=windowsgui" . Does not work

go build. Does not work

Just for context, this is a Fyne app, which also utilizes CGO. On top of that, I'm using CGO for print jobs.

Comment From: thanm

@thanm Yes, I'm using CGO. My apologies, I meant to say that only internal works, external does not. I had some confusion when creating so many builds when testing.

Thanks for that clarification. It would probably help if you could edit or add to your comment at https://github.com/golang/go/issues/75077#issuecomment-3215294462 as well, so as to avoid confusing other folks who are reading this issue.