go 1.26 build panics on Windows 10

[lidel]

Found this while testing Windows package from

• chore(main): release 0.48.0 ipfs-desktop#3028 (comment)
  cc Release 0.40 #11008

The daemon starts normally, gets to "Daemon is ready", WebUI at https://127.0.0.1:5001/webui works for a short while, then daemon crashes, RPC stops responding.

• Tested .exe: dist-windows-latest
• Full daemon output (stdout+stderr): ipfs-daemon-0.40.0-windows-panic.log

Some notes below, but need to look at this more closely + reproduce on a different machine.

Crash signature

Exception 0xc0000005 0x8 0x1ce5935180 0x1ce5935180
PC=0x1ce5935180
runtime: g 23791 gp=0x56c75f563c0: unknown pc 0x1ce5935180

• 0xc0000005 = STATUS_ACCESS_VIOLATION
• 0x8 = EXCEPTION_EXECUTE_FAULT (DEP violation: CPU attempted to execute non-executable memory)
• The faulting PC (0x1ce5935180) is outside the binary's code range (legitimate addresses are in 0x7ff6e58xxxxx-0x7ff6e71xxxxx), indicating a corrupted return address on the stack

The crashing goroutine was created by go-yamux/v5.newSession and was doing normal TCP socket I/O through the Windows overlapped I/O path:

internal/poll.(*FD).execIO
  -> internal/syscall/windows.WSAGetOverlappedResult
    -> syscall.SyscallN

Suspecting Go regression on Windows

Go 1.25 introduced a major rework of Windows I/O completion port (IOCP) handling (go#19098). This rework has caused several regressions on Windows that are still being worked through in Go 1.25.x/1.26.x:

• go#76391 - NewFile hangs on blocked handles (critical release-blocker, multiple CLs fixing execIO internals)
• go#77142 - overlapped I/O interop issues

The crash happens in internal/poll.(*FD).execIO, which is the code path affected by these regressions. However, the specific bug causing this crash may not be one of the already-reported issues. It could be an unreported runtime bug, or potentially antivirus interference (go#40878 documented identical "unknown pc" crashes caused by AV software on Windows).

Suggested action

• Ask someone to try to reproduce on Windows 10 or 11
  • If reproducible, file an upstream Go issue with the full crash log so the runtime team can assess whether this is a known or new bug in the IOCP rework
  • Consider building Windows release binaries with Go 1.24.x (last version before the IOCP rework) until the Go 1.25/1.26 Windows I/O issues are resolved

Environment

• Kubo 0.40.0 (882b7d2a9)
• Go 1.26.0
• Windows 10, amd64

[lidel]

@aschmahmann are you able to reproduce by any chance?
(run ipfs daemon on Windows, open http://127.0.0.1:5001/webui, wait a few minutes)

[aschmahmann]

Was able to reproduce a crash fairly quickly when I initially tried.

This is my error message from the first time I ran it, it's a little different from yours though:

Details

...
Daemon is ready
unexpected fault address 0x10012ec6b0
fatal error: fault
[signal 0xc0000005 code=0x0 addr=0x10012ec6b0 pc=0x7ff69eca76a6]

goroutine 59876 gp=0x10330263e5a0 m=16 mp=0x1032fa580808 [running]:
runtime.throw({0x7ff6a04a23a9?, 0x4?})
	runtime/panic.go:1229 +0x4d fp=0x1032fd031c68 sp=0x1032fd031c38 pc=0x7ff69e57b58d
runtime.sigpanic()
	runtime/signal_windows.go:398 +0xd0 fp=0x1032fd031cb0 sp=0x1032fd031c68 pc=0x7ff69e55b710
github.com/libp2p/go-libp2p-kad-dht/pb.(*Message).GetCloserPeers(...)
	github.com/libp2p/go-libp2p-kad-dht@v0.38.0/pb/dht.pb.go:225
github.com/libp2p/go-libp2p-kad-dht/pb.(*ProtocolMessenger).GetClosestPeers(0x1032fa77d090, {0x7ff6a083cf90?, 0x1032fba782a0?}, {0x103301351ec0, 0x26}, {0x103301351ec0, 0x26})
	github.com/libp2p/go-libp2p-kad-dht@v0.38.0/pb/protocol_messenger.go:168 +0x586 fp=0x1032fd031e80 sp=0x1032fd031cb0 pc=0x7ff69eca76a6
github.com/libp2p/go-libp2p-kad-dht.(*IpfsDHT).lookupCheck(0x1032fa71ea88, {0x7ff6a083cf90?, 0x1032fba782a0?}, {0x103301351ec0, 0x26})
	github.com/libp2p/go-libp2p-kad-dht@v0.38.0/dht.go:383 +0x49 fp=0x1032fd031ef8 sp=0x1032fd031e80 pc=0x7ff69ecd90c9
github.com/libp2p/go-libp2p-kad-dht.(*IpfsDHT).peerFound.func1()
	github.com/libp2p/go-libp2p-kad-dht@v0.38.0/dht.go:692 +0x8f fp=0x1032fd031fe0 sp=0x1032fd031ef8 pc=0x7ff69ecdb2af
runtime.goexit({})
	runtime/asm_amd64.s:1771 +0x1 fp=0x1032fd031fe8 sp=0x1032fd031fe0 pc=0x7ff69e583821
created by github.com/libp2p/go-libp2p-kad-dht.(*IpfsDHT).peerFound in goroutine 295
	github.com/libp2p/go-libp2p-kad-dht@v0.38.0/dht.go:687 +0x179
...

Regarding Go versions:

1. I wouldn't blame Go 1.25, the last release had that too and we haven't seen issues here
2. We can't actually build this version of kubo with Go 1.25 because we updated to Go 1.26 here (feat: update to Go 1.26 #11189). Note: we'd have to go even further back to be able to build with Go 1.24.

---

It seems like reverting 9ca1dbb shouldn't interfere with much, so I've locally reverted that commit on top of the 0.40.0 commit and build with Go 1.26.0 and I'm seeing the error. I'm now building and running with Go 1.25.7, so far it looks good. I'll keep it running overnight and push a PR with the reversion to master which can get cherry-picked into the patch release.

[lidel]

Triage note:

• we will release v0.40.1 with revert to go 1.25 to unblock ipfs-desktop release
• this is not the first time go .0 ships with catastrophic regression:
  • v0.30.0 & Go 1.23 go1.23 timers cause issues with libp2p connmgr and more #10501
  • v0.23.0 & Go 1.20 net/textproto: can write binary header it can't read golang/go#60674
  • v0.5.0 & Go 1.14 fix: downgrade to go 1.13 #7054
• going forward we will always wait for .1
• keeping this issue open until we switch to go 1.26.x with Windows fix

[Brent-Sanchez]

https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/