I would try to reboot the server; sometimes the windows service manager caches information that makes it hard to detect. Next, it could be that you don't have permission to view the service. You can use a tool like sc.exe to unregister the service. Then, it should work

For the Windows service, the only requirements for the service account are (assuming default file system package store configuration) read/write access to the directory where the underlying packages are stored (default is in ProgramData), read/write access to the service installation directory (default is in Program Files), and granted access to the ProGet database role named ProGetUser_Role. For the web application (Windows service or IIS application pool identity), the requirements are the same as the Windows service, plus read/write access to the website installation directory. Note again that the Desktop Hub installation privileges is orthogonal to the account that ProGet runs as, since it would obviously require more privilege to create/update/grant in the database and also create subfolders in Program Files & %ProgramData%. As an extra word of caution, if D: is a mapped drive, be sure to use the full UNC path in configuration settings within ProGet.

Hello, these errors are quite erare, but it can happen in dealing with randomly disconnecting web clients. The easiest thing to do is to set automatic recovery on the service. You can do this on the "Recovery" tab. You could also upgrade to iIS, which mas more transparent crash recovery.

Thanks for posting an update! Anecdotally, this used to happen to us "all the time" when rebooting a hypervisor server (i.e. server hosting multiple VMs) because the host/hypervisor server didn't have enough resources to give to each booting virtual machine, and SQL Server couldn't start due to low start-up resources (memory, etc). We've mostly corrected this by staggering start times and increasing VM hardware.

It would be the Windows Event/error Logs, specifically the Windows Service Manager. If ProGet isn't able to run/load, then it wouldn't be able to log anything.

This is not a known issue with ProGet or our tools. But I'll note, there is a little bit of a "warm-up" time needed for .NET-based applications; it should be pretty quick (5-10 seconds), but it sounds like your server might be a bit underpowered? Or maybe there is some other thing preventing .NET applications from "warming up" in a fast enough time?

Sounds like the service is crashing because of connectivity problems with SQL Server; this is expected behavior, as the service cannot operate without a database and will crash if it can't be reestablished after a few tries. This is why it's not logged in BuildMaster's error logs (as those are stored in the database). You could see it in the Windows Event Log however. Short of fixing connectivity problems, you can just set service to auto-recover.

Solution found, wrong app pool user. thks all

My best guess is that it's related to permissions- most likely the user account which is running the service cannot talk to the SQL database. There should be an error/exception in the Windows event log if this is the case.

If the app can't access the service, it seems like it shouldn't assume everything is OK, but rather indicate that it has no idea because it can't access the service. :)

I have found the solution ... Set the Property "UseIntegratedWebServer" to False in the Advanced Config when use IIS. The solves the problem

I tried that. Actually, the stop/start link started showing after I restarted the app pool and website. Please, keep me in touch for a solution. Thanks

I can't believe I missed that. I upgraded and that problem is gone but with new issues. Will open a separate question for that problem. Suggestion: How about adding a new tag npm? Thanks Niklas

Yes. We can switch to IIS. Login time out is not a problem. The problem is that our CI builds were taking much longer depending on ProGet needing to spin up. I'll let you know how it goes.

The best solution is to assign a domain account that does have the privileges to start/stop the service. There are some other solutions detailed here: http://serverfault.com/questions/187302/how-do-i-grant-start-stop-restart-permissions-on-a-service-to-an-arbitrary-user

In this case, the web server user simply doesn't have permission to query the service status. You can ignore this message or increase the web server user's privileges.

This is a known issue with .NET-based services on low-spec servers running Windows Server 2003. Basically, the CLR cannot load in time, triggering an error. In newer server operating systems, you can specify Delay Start, which solves the problem, but it's not possible on 2003. There is a workaround available from Microsoft, KB#193888.

The service does need to be running mainly to index packages. If you selected the IIS option during install, the web server in the service will not run. If you are switching from integrated web server to IIS, make sure to update the service's .exe arguments to exclude the /urls argument and then the web server component of the service will not run.

For completeness, v3.0.3 was just published which adds an index to Publish_Date and the dashboard query now returns virtually instantly tested against 100,000+ packages in the database.

Thanks for the work around. Saved us much headache!