Service unable to start after upgrade

As I found a workaround I thought I just pust this has a question.

After upgrading from 4.7.14 to 5.1.7 build 2 the ProGet Windows service did not start.

The event log reviels the following errors:

Application: ProGet.Service.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Net.HttpListenerException

Server stack trace:
at System.Net.HttpListener.AddAllPrefixes()
at System.Net.HttpListener.Start()
at Inedo.Web.Server.HttpListenerHost.Start(WebServerConfiguration settings)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Messaging.IMessage)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(System.Runtime.Remoting.Proxies.MessageData ByRef, Int32)
at Inedo.Web.Server.HttpListenerHost.Start(Inedo.Web.Server.WebServerConfiguration)
at Inedo.Web.Server.IntegratedServer.ProcessRequests()
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Threading.ThreadHelper.ThreadStart()

An unhandled exception occurred and the process was terminated.

Application ID: ProGet.Service.exe

Process ID: 1240

Exception: System.Net.HttpListenerException

Message: Access is denied

StackTrace:
Server stack trace:
at System.Net.HttpListener.AddAllPrefixes()
at System.Net.HttpListener.Start()
at Inedo.Web.Server.HttpListenerHost.Start(WebServerConfiguration settings)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Inedo.Web.Server.HttpListenerHost.Start(WebServerConfiguration settings)
at Inedo.Web.Server.IntegratedServer.ProcessRequests()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

This smells like the URL has not been properly pre-registeret by the installer during the upgrade (URLACL).
I was able to workaround this by changing the ProGet service account from NetworkService to LocalSystem.

Have you heard of this issue before?
Does the installer normally register the URL for the service account?

Product: ProGet
Version: 5.1.7

We got the exact same problem, trying to upgrade ProGet to 5.1.8

The installer isn't supposed to do anything with URL registrations on an upgrade - they are supposed to persist unmodified. I haven't seen this happen before. We'll do some tests with a 4.7.14->5.1.7/8 upgrade to see if we can reproduce this.

Sorry, I forgot to ask - was this the new Inedo Hub installer or the traditional/offline installer for ProGet 5.1?

It was Done using the Inedo Hub installer

I used the offline installer.

BTW, even though the server is on the internet, the hub installer couldn't get through the corporate firrwall/proxy...

I'm not sure but it could be that the existing install (v4.7.14) had the service configured to use LocalSystem account, and after upgrading the installer switched to NetworkService account.

Some extra info:

ProGet version we trying to upgrade from: 5.0.12

ProGet.Service.exe is running as NetworkService.

I've now reproduced this. In my testing the root cause was that the listen URL for the web server was not migrated to the new configuration file used in v5.1+. So essentially it was trying to listen on the wrong URL/port, and it may or may not even have access to do so (causing the crash if it does not).

To verify that this is the cause (and fix), open the ProGet config file as described here, and verify that the Urls attribute of the <WebServer> element is correct.

Does this help?

Our ProGet config has the following <WebServer> config:

Not exactly what I expected. We use the self-hosting feature of ProGet and is setup to listen on port 80, which it still does if we switch the service account to LocalSystem.

I'm a bit confused.

Should the <WebServer> config correspond to the url and port where I would like to contact the ProGet web app on?
Now that I changed the service account to a high-privilege type, why is the ProGet web app still accessible on port 80 when the ProGet config says port 8624?

We managed to upgrade, by

Install new version
Fix Urls in proget config file
start service

Hi Peter-

The integrated web server uses Windows' http.sys, which will only list on a host name and port if the listening user is registered to that URL with the system, unless the listening user is a local admin. Local admins can listen on any host name and port with no registrations.

ProGet's been around a while now, and over the years we've changed where the "listen URLs" for the web server get stored (this is apart from the actual URL registration, which is stored by the OS). A long time ago they were stored as a startup argument to the ProGet windows service (if you look in services.msc, you will likely see that ProGet.Service.exe has some argument like /Urls=myserver:80/) For compatibility, urls specified in this way are appended to the list used by more recent versions, so your installation was ultimately trying to listen to your original port 80 url, and the erroneous one generated as the default in that config file. Since there was never a reservation created for the second one, the process crashed.

It's a long-winded answer, but probably the best way to get your installation to continue to work going forward would be to delete and re-register the service so it doesn't pass that URL in anymore, and update the config file to have the URL copied from that argument.

We'll be updating the installer to properly migrate this as well.

Hope this is somewhat informative for everyone monitoring this thread. Let me know if I can provide any more information to help!

Thanks Greg,

That cleared it all up for me.