Windows - this app can't run on this PC

[LukeMauldin]

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

C:\WINDOWS\system32>go version
go version go1.15.6 windows/amd64

Does this issue reproduce with the latest release?

Yes

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

go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\mauldinl\AppData\Local\go-build
set GOENV=C:\Users\mauldinl\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\mauldinl\go\pkg\mod
set GONOPROXY=XXX
set GONOSUMDB=XXX
set GOOS=windows
set GOPATH=C:\Users\mauldinl\go
set GOPRIVATE=XXX
set GOPROXY=XXX
set GOROOT=C:\AppSpace\go_1_15_6
set GOSUMDB=off
set GOTMPDIR=
set GOTOOLDIR=C:\AppSpace\go_1_15_6\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=XXX\go.mod
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\mauldinl\AppData\Local\Temp\go-build253532950=/tmp/go-build -gno-record-gcc-switches

C:\Users\mauldinl>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/AppSpace/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-8.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw810/x86_64-810-win32-sjlj-rt_v6-rev0/mingw64 --enable-shared --enable-static --enable-targets=all --enable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch-32=i686 --with-arch-64=nocona --with-tune-32=generic --with-tune-64=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw810/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw810/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw810/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw810/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-win32-sjlj-rev0, Built by MinGW-W64 project' --with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/c/mingw810/x86_64-810-win32-sjlj-rt_v6-rev0/mingw64/opt/include -I/c/mingw810/prerequisites/x86_64-zlib-static/include -I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/c/mingw810/x86_64-810-win32-sjlj-rt_v6-rev0/mingw64/opt/include -I/c/mingw810/prerequisites/x86_64-zlib-static/include -I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=' -I/c/mingw810/x86_64-810-win32-sjlj-rt_v6-rev0/mingw64/opt/include -I/c/mingw810/prerequisites/x86_64-zlib-static/include -I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/mingw810/x86_64-810-win32-sjlj-rt_v6-rev0/mingw64/opt/lib -L/c/mingw810/prerequisites/x86_64-zlib-static/lib -L/c/mingw810/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: win32
gcc version 8.1.0 (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project)

What did you do?

Compiling a Go program that uses vendor Windows supplied libraries via CGO will not run. Gives a prompt "this app can't run on this PC". This same application works correctly on Linux. Ensured that the vendor Windows libraries are on the PATH and resolve correctly using dependency walker - https://www.dependencywalker.com/
Other Go applications that do not use CGO launch correctly. Verified that both the build system and running system are x64 systems.

Build command:
go build -v -o ./bin/XXX.exe -trimpath -ldflags="-X main.appVersion=v2.7.0"
Windows version: 2004 (Build 19041.630)

What did you expect to see?

The application to launch.

What did you see instead?

An error message from Windows stating "This app can't run on your PC". Looked in event logs but cannot find additional information. Tried running app via Administrator command prompt and same behavior.

[ianlancetaylor]

The first thing to check is your anti-virus program.

https://golang.org/doc/faq#virus

[LukeMauldin]

Thank you, but I disabled my antivirus program and still have the same issue. And note this only impacts Go programs using CGO on windows, other Go programs work correctly.

[LukeMauldin]

Also tried with mingw 8.1.0-posix-sjli rev0 x64 and same error message.

[mattn]

Could you please check the compilers and the program works with simple C code?

[networkimprov]

Try go build -buildmode=exe ...

[LukeMauldin]

Using the -buildmode=exe resolved the problem. I am curious though, why is that specifically required on windows only and not required when building a Linux executable? Also, why is that buildmode required only for a windows CGO program?

[alexbrainman]

@LukeMauldin you see effect of buildmode change from

https://golang.org/doc/go1.15#windows

I am curious though, why is that specifically required on windows only and not required when building a Linux executable?

You said that you use CGO to build your program. But you did not say what C code / library you used. You did not say what C compiler you used. You did not say what C compiler flags you used to build your program. Without this information it is impossible to answer your question. I won't be able to answer your question even if you provide this information, but I can say that your C setup works on Linux, but not on Windows. Building C programs is more complicated then Go.

Also, why is that buildmode required only for a windows CGO program?

See my previous answer. If you are not using CGO, then Go compiler has everything it needs to build your program regardless of buildmode setting.

I hope it helps.

Alex

[networkimprov]

@ianlancetaylor could you add something to the docs about trying -buildmode=exe on Windows+cgo in case of problems?

[ianlancetaylor]

@networkimprov I think that's too vague. I would like to understand what the problem actually is first.

[networkimprov]

Since Go adopted ASLR (-buildmode=pie) on Windows in 1.15, we've found that mode is incompatible with some DLLs (IIRC) and cgo scenarios like the above.

Alex and I have resolved a number of bug reports here with "try -buildmode=exe".

I don't see anything in the cmd/go or cmd/cgo docs about this.

[ianlancetaylor]

My first take on this is that we need to change back to defaulting to -buildmode=exe.

[networkimprov]

buildmode=pie was adopted for security reasons, see #35192

Maybe there's more to do to make it work all the time?

cc @zx2c4

@gopherbot add OS-Windows

[alexbrainman]

@ianlancetaylor could you add something to the docs about trying -buildmode=exe on Windows+cgo in case of problems?

@networkimprov what do you propose to say?

Alex and I have resolved a number of bug reports here with "try -buildmode=exe".

I don't see anything in the cmd/go or cmd/cgo docs about this.

I don't see what we can say in docs. We don't even know what this issue problem is. How could we recommend solution without knowing what the problem is?

My first take on this is that we need to change back to defaulting to -buildmode=exe.

@ianlancetaylor I disagree. We all agreed that Go should generate ASLR by default. It does work for all pure Go programs, and most CGO programs. And we provided easy solution for people who cannot make their CGO programs build with ASLR.

Alex

[networkimprov]

What to say: If you have problems building or running a Windows cgo app, try -buildmode=exe to disable ASLR.

[alexbrainman]

What to say: If you have problems building or running a Windows cgo app, try -buildmode=exe to disable ASLR.

We all agreed that Go programs should use ASLR by default. What you suggesting is that users disable ASLR even without understanding the implication of their action. I prefer they understand their problem before they start looking for solution.

Alex

[LukeMauldin]

As someone who has encountered this bug, I strongly think that something about it should be placed in the docs because it is a total show stopper until you know the buildmode work around.
Another bit of information: in my scenario, the CGO libraries I am linking against are old. They were originally built in 2013 on Windows 7 using Visual Studio 2008. Unfortunately I cannot rebuild them since they were provided by the vendor and we have to use them as is. My suspicion is that build chain of the libraries is a contributing factor to the issues with ASLR.

[networkimprov]

Apparently DLLs not linked appropriately may not work in ASLR programs, tho I would have thought you'd see an error which indicated that.

See https://security.stackexchange.com/questions/42283/why-are-some-dlls-not-randomized-what-makes-it-hard-to-deploy-full-aslr-for-all

EDIT: it could be due to 64-bit exe vs 32-bit dll, and/or a mingw bug.

[seankhliao]

closing given the lack of recent reports.