Windows 10 Build 1809


(Mark) #1

I upgraded my Windows 10 machine from build 1803 to 1809. After the upgrade the Caddy service was missing. I tried to reinstall it and got an error message it could not install due to the event log registry entry already being present. I deleted the offending key and it installed fine. The service starts, but I am unable to connect to any sites. I uninstalled and reinstalled it with the same results. I then uninstalled it, downloaded version 0.11.4 and reinstalled it with the same results. It starts and stays running, but I am unable to connect. I have tried disabling the firewall and running the service as both local system as well as administrator with no luck.

I can run it from a command prompt and then am able to connect to the sites without issue. It only seems to not work when running as a service. I do not see anything in the Windows System or Application logs. I also do not see anything in the logs for my sites when I try to access them and it fails. When I try to connect from Edge or Chrome, I get site not found. I have tried both the internal and external URLs with the same results. I am thinking the service is not properly reinstalled, but not sure how to get it reinstalled properly at this point.

Running out of things to try.


(Matthew Fay) #2

Hi @osuhickeys, welcome to the Caddy community.

I haven’t had to troubleshoot Windows services much myself, but you could try to remove it again and reinstall the service via something like NSSM, perhaps.


(Mark) #3

Great suggestion. I tried wrapping Caddy in both NSSM and FireDaemon and get the same results with both. That would lead me to believe it is not an issue with installing it as a service and something in the registry after the Windows upgrade being corrupt. A new service install with different tools would create completely new entries in the registry in new locations I believe effectively ruling that out.

When I install if with FireDaemon and user arguments for Caddyfile and log, the log file never gets created. The log file does get created if I launch it from a command line. I am thinking when it is launching as a service maybe it is not picking up the Caddyfile or the process is just dying before it even gets to that point.

I do have some other services installed with FireDaemon where I am passing in parameters and they seem to be working fine.

I will try to upgrade another machine this weekend and run it from a second machine to see if the issue occurs on multiple machines. I will also run it on the machine priori to make sure it works on that machine on 1803 before I upgrade it to 1809.


(Sugarcube) #4

i’m still on windows 1803 so crossing my fingers now :smile:

As a suggestion for troubleshooting, i don’t know about nssm and firedeamon, but services often run in windows/system folder (or system32, i’m not sure), so log file might be created there. or you could provide a full path name for a log file. (that would explain you can’t connect, by default caddy runs and starts serving current folder on port 2015 -> this is also something you could try see if you can open http://localhost:2015)

caddy also supports running as a service out of the box, see https://caddyserver.com/docs/hook.service
(I’ve never done that yet, but i use the underlying library for other applications and it is very reliable)


(Mark) #5

Appreciate the additional ideas…

I tried specifying the full path for the log file with no luck.

I get “404 not found” on http://localhost:2015.

I was using the hook.service on build 1803 successfully. It is what is not working on1809. NSSM and FireDaemon were attempts to make it a service to see if they might work in lieu of hook.service.

Really scratching my head on this one. I think the test from another machine will really be revealing. It will tell me whether it is an issue with my machine or an incompatibility/issue with build 1809 and Caddy.


(Mark) #6

I eventually got this working using the service hook on Windows 10 Build 1809. I had to add -conf -agree and -log to the service to get it to launch. Odd this worked on Build 1803 without them, but I am able to reproduce on a machine using Build 1803 where it works without them.