Windows Service Timeout

[ericrange]

Hello, is it possible to move all dll files within a function?
Currently there is a huge bug in golang concerning windows services.
If a golang app is loaded for the first time (after restart) and windows try to load the go app, go do not tell windows that it is ready, instead it loads all dll files and blocks the main thread meanwhile.

This leads (especially on slow hdd disks) to a windows service timeout and the service will not start.

Here is the issue:
golang/go#23479

This bug could be prevented if all dll files will load within a function and not in the global scope.

#NOT HERE!!
var mod = syscall.NewLazyDLL("user32.dll")

func main() {
        #This will work
	var mod = syscall.NewLazyDLL("user32.dll")
	var proc = mod.NewProc("MessageBoxW")
	var MB_YESNOCANCEL = 0x00000003

	ret, _, _ := proc.Call(0,
		uintptr(unsafe.Pointer(syscall.StringToUTF16Ptr("This test is Done."))),
		uintptr(unsafe.Pointer(syscall.StringToUTF16Ptr("Done Title"))),
		uintptr(MB_YESNOCANCEL))
	fmt.Printf("Return: %d\n", ret)

}

This problem is really serious for me :(

[shirou]

I think moving declaration to inside each functions makes each function call slower. And so many changes are required. So we can not accept your suggestion for this library. Do you have any other idea ?

[ericrange]

what about the "init" function in each module? so all its just called once

[shirou]

So you mean like this?

var (
	modiphlpapi *windows.LazyDLL
)

func init() {
	modiphlpapi = windows.NewLazyDLL("iphlpapi.dll")
}

If this works, this is acceptable I think.

And one more question. You have mentioned about Dll, but how about LazyProc?

[ericrange]

to be honest, i dont know :D
it took hours to find out that this repo is the reason for this.
I use https://github.com/kardianos/service, and if i remove gopsutil, it all works 100%.
And because of the bug report in go, i thought the dll import could be the reason :O

[shirou]

Ok, so could you make a PR after you confirm it works on your usage?

[ericrange]

i will try

[Lomanic]

I'm surprised this issue would occur in gopsutil because it uses windows.NewLazyDLL (should be NewLazySystemDLL by the way, to prevent including a DLL with the same name next to the binary for example, will submit patch this weekend) that "will delay the load of the DLL until the first call to its Handle method or to one of its LazyProc's Addr method", and these calls only appear in gopsutil inside functions (when calling LazyProc.Call), hence in the main execution.

Unless we have some remaining non-LazyDLL/Proc calls remaining in some init()?

[ericrange]

omg it f***ing works :O
thank you so much!!! :)

the windows service do not run in any timeouts anymore!!! :)

[Lomanic]

That's… crazy, and a total (happy) side-effect, awesome that it fixed your issue!

[ericrange]

windows....

[Lomanic]

Closing as it looks fixed, don't hesitate to reopen this issue if it happens again.

[machooo-x]

I encountered this problem, putting all DLL related initialization actions into init method solves my problem