x/sys/windows: GetLastError always returns nil

[bupjae]

What version of Go are you using (go version)?

$ go version
go version go1.14.7 windows/amd64

Does this issue reproduce with the latest release?

Not tried, but I'm pretty sure it will.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Bupjae\AppData\Local\go-build
set GOENV=C:\Users\Bupjae\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Bupjae\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Bupjae\AppData\Local\Temp\go-build843644218=/tmp/go-build -gno-record-gcc-switches

What did you do?

package main

import (
	"fmt"
	"golang.org/x/sys/windows"
)

func main() {
	var handle windows.Handle
	wrongName := windows.StringToUTF16Ptr("ADFADFASDFSDAFASFD")
	err := windows.GetModuleHandleEx(0, wrongName, &handle)
	if handle == 0 {
		fmt.Println(err)
		fmt.Println(windows.GetLastError())
	}
}

What did you expect to see?

Prints out error message describing 'module not found' twice.

What did you see instead?

The specified module could not be found.
<nil>

According to https://golang.org/src/runtime/sys_windows_amd64.s , before calling actual DLL routine (line 58), last error information is erased (line 22-23). This makes syscall.GetLastError (and windows.GetLastError) completely meaningless,

[ianlancetaylor]

The idea is that the error will be returned by the call, so you should never to call GetLastError yourself. And your code shows that: the err value is the error you want.

So, if there is anything to do here, it's simply to document that there is no point to calling GetLastError. I don't know why we even define it.

[ianlancetaylor]

CC @alexbrainman

[alexbrainman]

What Ian said - do not call GetLastError directly from your code - Go runtime calls GetLastError for you behind the scenes.

It is pointless to call GetLastError from your Go code, because GetLastError changes every time you make new Windows API call. But Go runtime calls different Windows API at all times (for example to get memory or create threads). The fact that you don't see any Windows API calls in your code does not mean your program does not call Windows APIs.

Go runtime also changes threads all the time. GetLastError is thread specific. So, if you call GetLastError from your code, you might be getting GetLastError value from another unrelated thread.

According to https://golang.org/src/runtime/sys_windows_amd64.s , before calling actual DLL routine (line 58), last error information is erased (line 22-23).

On lines 70-73 this function gathers GetLastError value right after Windows API is finished. Just use that value.

Alex

[bupjae]

Sorry for bumping up more than 1-year-old thread.

I understand that calling GetLastError is not the right way to get error.

Then, I think it should be documented properly, such as "GetLastError will return always nil. Use return value of each API call instead", as suggested in previous comment. Maybe marking GetLastError as deprecated is also possible.

[bcmills]

As an alternative, I wonder if we could change the Go runtime to provide a stronger invariant that makes GetLastError actually work. For example, this invariant might be feasible: “If the calling goroutine is locked to an OS thread, a call to GetLastError immediately following a system call (with no other function calls or variable declarations in between) returns the error set by that system call.”

And perhaps GetLastError should panic (or return an error unconditionally) if the calling goroutine is not locked to an OS thread?

That invariant might require more care in preserving and restoring error values in the runtime's signal handlers, although if signal-handler changes are needed for this invariant, they are probably also needed in order to avoid corrupting GetLastError return values in programs that use cgo.

(CC @golang/windows)