The configuration registry key could not be read

[snakeduse]

Hello, I have installed Erlang release as Windows Service and after reboot Windows 10 or Windows Server 2019 I see in Windows Event viewer outputs the following error: "The service03f4d9d14dbe2a74 service terminated with the following error: The configuration registry key could not be read.".

In this topik advise to set delayed-auto in service config. On my tests, delayed-auto helped solve the problem. Could you improve on the extended_bin_windows template?

[tsloughter]

I'm not sure what "configuration registry key could not be read" means here. And I don't have access to Windows, so can't really work on the script. It would be great if you'd be able to send PRs with improvements? :)

[snakeduse]

Ok. Thanks for the answer.

[tsloughter]

Feel free to leave this open. There are multiple ppl who contribute windows related improvements and they may see it if it is open and be able to give some help.

[snakeduse]

Reopen issue.

[weiss]

In this topik advise to set delayed-auto in service config. On my tests, delayed-auto helped solve the problem.

I'm running into the same issue and yes, delayed startup makes things work. But that sounds like a workaround to me, so I guess the first step should be understanding the actual problem.

I'm not sure what "configuration registry key could not be read" means here.

Seems erlsrv writes a few things into the registry and for some reason fails to read them when called early during boot, at least on Windows 10, 11 and Windows Server 2019 (earlier Windows versions don't seem to be affected). I don't think this issue is Relx-specific, as projects that use their own scripts ran into it as well (e.g., Distiller, ejabberd, emqx). Might make sense to submit an issue against OTP?

[tsloughter]

Looks like emqx was able to fix their script, so that could be incorporated into the relx script: https://github.com/emqx/emqx-rel/pull/378/files

[tsloughter]

I guess -on restart -d new is what is new there?

[weiss]

Looks like emqx was able to fix their script

I guess that turned out not to fix the issue as they ended up using delayed start as well.

[tsloughter]

Ah, damn, thanks.

[tsloughter]

Should we make the default "delayed start" in the start script then?

[weiss]

Yes, I guess that workaround might be desirable as long as we don't know the actual problem (like, a missing service dependency?).

[weiss]

The erlsrv manual recommends against using the -i option if release handling is to be performed, but without it, it's a little tricky to modify the startup type using the sc config command (as you need to know the internal service name). FWIW, in my own project I now use this little piece of ugly cmd code to do that:

set rel_name="foo"
set rel_vsn="0.1.0"
setlocal enabledelayedexpansion
for /f "tokens=3" %%i in ('sc getkeyname %rel_name%_%rel_vsn%') do (
    set svc_name=%%i
)
sc config %svc_name% start= delayed-auto
endlocal

[weiss]

I don't think this issue is Relx-specific

It isn't indeed, I've now reproduced the problem with a minimal Reltool example and reported it on the OTP tracker.