runtime: fatal error: winmm.dll not found on windows-amd64-2016 during bootstrapping

[bcmills]

From a TryBot on https://go.dev/cl/450713:

windows-amd64-2016 at 4af48c17a244c5fe21c9758ed84da0fb50b10510

…

Building Go cmd/dist using C:\workdir\go1.4. (go1.17.13 windows/amd64)
Building Go toolchain1 using C:\workdir\go1.4.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
go build io/fs: # io/fs
fatal error: winmm.dll not found
runtime: panic before malloc heap initialized

runtime stack:
runtime.throw({0x130a7da, 0x13})
	C:/workdir/go/src/runtime/panic.go:1198 +0x7b fp=0xbf6fffb58 sp=0xbf6fffb28 pc=0xa901bb
runtime.loadOptionalSyscalls()
	C:/workdir/go/src/runtime/os_windows.go:284 +0x85e fp=0xbf6fffcc0 sp=0xbf6fffb58 pc=0xa8985e
runtime.osinit()
	C:/workdir/go/src/runtime/os_windows.go:550 +0x65 fp=0xbf6fffd20 sp=0xbf6fffcc0 pc=0xa8a045
runtime.rt0_go()
	C:/workdir/go/src/runtime/asm_amd64.s:211 +0x138 fp=0xbf6fffd28 sp=0xbf6fffd20 pc=0xac4eb8
go build internal/poll: # internal/poll
<unknown line number>: internal compiler error: panic: runtime error: invalid memory address or nil pointer dereference

(CC @golang/runtime, @golang/windows)

[alexbrainman]

Just FYI. timeBeginPeriod and timeEndPeriod functions are used from winmm.dll. We cannot continue without them.

Alex

[qmuntal]

Just FYI. timeBeginPeriod and timeEndPeriod functions are used from winmm.dll. We cannot continue without them.

Alex

To be puritan, these functions are only used if Windows does not support high resolution timers, which were introduced in Windows 10, version 1803. We could relax this failure mode so it only triggers on older Windows versions.

Having said this, I have no clue why winmm.dll could not be loaded.

[bcmills]

Yeah, I'm not so concerned about whether failing to load the DLL should be a fatal error — it shouldn't have failed to load in the first place, in which case it doesn't matter whether that failure happens to be fatal. 😅

[mknyszek]

Is this a pattern of failures or has it just been one so far? I guess it's also possible this is a build infra issue... I don't know.

[bcmills]

I only know of the one so far, although I think it's been a while since the last watchflakes run...

[alexbrainman]

To be puritan, these functions are only used if Windows does not support high resolution timers, ...

Please ignore my message. I was talking to myself. :-)

Having said this, I have no clue why winmm.dll could not be loaded.

Maybe it is possible to add call to print() which calls getlasterror() before this line

go/src/runtime/os_windows.go

Line 285 in cf93b25

throw("winmm.dll not found")

and that might give us some clues.

Perhaps it is good idea to do the same at every windowsLoadSystemLib call site.

Alex

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

[gopherbot]

Change https://go.dev/cl/556935 mentions this issue: runtime: avoid loading winmm.dll on newer Windows versions