Why doesn't SC QUERY show all services? Are some services hidden?

I'm trying to find out why a service is in STOP_PENDING state, but the service seems to be hidden.

It doesn't show up in a general sc query, nor in services.msc or in Powershell's Get-Service.

Here's what happened:

I used findstr to search for a string in a set of files, and it found it in a binary file that contained lots of ASCII BELL characters. So my console was issuing an endless string of beeps. So I opened another console to stop the beeping:

net stop beep

No problem, beeping stopped. But when I issue a net start beep, I always get the error:

The service is starting or stopping. Please try again later.

I can see the service's state if I do:

sc query beep

but a general sc query doesn't show the service.

QUESTIONS:

Why isn't the beep service listed? Why doesn't it show up in sc query, services.msc or Get-Services? Are there such things as hidden services?

Also, how can I get this service to restart? This service always reacts this way. If I stop it, it gets stuck in STOP_PENDING state and stays there until I reboot.

1 Answer

sc can control both regular services and drivers (which in low-level terminology are both "services" but drivers have a service type of KERNEL_DRIVER). beep is a driver. By default, sc lists only non-driver services though. (Also, it only lists entries in state "active" by default.)

This is apparent from the output of sc /?:

USAGE: sc <server> [command] [service name] <option1> <option2>...
[...]
QUERY and QUERYEX OPTIONS : If the query command is followed by a service name, the status for that service is returned. Further options do not apply in this case. If the query command is followed by nothing or one of the options listed below, the services are enumerated. type= Type of services to enumerate (driver, service, all) (default = service) state= State of services to enumerate (inactive, all) (default = active)
[...]
SYNTAX EXAMPLES
sc query - Enumerates status for active services & drivers
sc query messenger - Displays status for the messenger service
sc queryex messenger - Displays extended status for the messenger service
sc query type= driver - Enumerates only active drivers
sc query type= service - Enumerates only Win32 services
sc query state= all - Enumerates all services & drivers
[...]

As you can see here, it says the type= argument allows to select either service, driver or all, with a default of service.¹ (Similarly, the state= argument has a default of active.)

So, to list all active services/drivers, you can use sc query type= all. To list also inactive ones, you can use sc query type= all state= all.

As to how to restart the beep driver: As far as I know, there is no way. beep is not really designed to be stopped. It is half-working though (and it is set as STOPPABLE), so it at least does stop the beeping and it doesn't crash the system when you stop it (like some other drivers will unfortunately do), but it neither cleans up its state correctly and it gets stuck in STOP_PENDING for all times because it never tells the service manager that it is now STOPPED. The only way (that I know of) to get the beep back is rebooting the computer.

By the way, if you are looking for a more powerful GUI for service management (including driver-type services), take a look at Process Hacker. It has a tab "Services" which not only allows you to list and control all the services but also to edit them in ways that services.msc won't let you do (for example changing their path). But bear in mind, with great power comes great responsibility. You can wreck your system with it too.

_Footnotes:

_{1. And here we have to understand that sc attempts to speak "usertalk" and calls services of type KERNEL_DRIVER "driver" instead of "service", even though they are (from a low-level perspective) technically both services. This is similar to how both creating and opening a file is done using CreateFile because it creates a file handle, yet every UI in the world will not consider opening an existing file as "creation" of anything. These sort of distinctions of perspective unfortunately often make terminology very confusing because the same term can mean either something entirely different or like here partly the same thing but partly not, all depending on whether you look at it from the perspective of the kernel, the user-mode API, or the Windows Shell (to name a few).}