Someone sent the following screen shot to one of our internal troubleshooting aliases. They wanted to know what the "Name Not Available" slider meant.
The audio system on Vista keeps track of the apps that are playing sounds (it has to, to be able to display the information on what apps are playing sounds :)). It keeps this information around for a period of time after the application has made the sound to enable the scenario where your computer makes a weird sound and you want to find out which application made the noise.
The system only keeps track of the PID for each application, it's the responsibility of the volume mixer to convert the PID to a reasonable name (the audio service can't track this information because of session 0 isolation).
This works great, but there's one possible problem: If an application exits between the time when the application made a noise and the system times out the fact that it played the noise, then the volume mixer has no way of knowing what the name of the application that made the noise was. In that case, it uses the "Name Not Available" text to give the user some information.
Jonathan: Try it and see :). The full path to the EXE is included in the persisted value, so you'd have to actually replace the exe on the disk to confuse the system.
Triangle: So? We took a look at the PID re-use issue and decided that it didn't make the bar for fixing the issue in Vista. The issue is real, so we deferred the fix for a future version of Windows (when we'll have more time to work on a more complete fix). It happens - every software project ever created has had bugs that weren't fixed before it released.
Miral: I think I need to write another blog post explaining in more detail.
> And what will happen if that PID is reused?
This is a very interesting question in a much larger scope than the volume mixer.
Suppose I'm a sysadmin looking at a list of processes and I want to kill one. I type kill ... processid and the process with that ID is killed.
But what if, between looking at the list and running the "kill", all the following happened?
1) the process I was looking at exited
2) another process started
3) the new process happened to use the processid
I've killed the wrong process.
There's a reasonable expectation that the thing that hands out process IDs should make an effort to avoid this... say, by giving recently used process IDs a well-deserved vacation.
Maurits: Absolutely. And the thing that hands out process IDs does make an effort to avoid this (sort-of). But there is a limit to what it can do and stuff does happen.
err.. an engineer-type decision that doesn't work well and possibly confuses the user frequently in the hope of some possible edge case when it might be useful. Absolutely revolting to have these sort of things still going in software 2007. Remove this ENTIRE debugging feature and keep-the-os-simple is the correct solution. Not more cruft with trying to find the correct name of the name, for that one guy in billion that knows to look in the sound mixer for figure which app made a beep. Please read The Inmates are Running the Assylum.
The slider is a troubleshooting feature (in fact, the entire audio mixer is a troubleshooting feature).
If we were to remove it, we'd get complaints "There's this app that keeps on making noises on my machine and I can't get it to stop".
I would like to have a control panel which would allow me to view and adjust already existing persistent parameters for individual executables which did not play any sound in the current session.
For example for program which plays a notification sound when some event happens (e.g. Alarm Clock, TV notifier) I can not adjust the volume before that event happens (at least I did not found a way to do it) nor check how loud it will be.
OK, so there's an application that's making a sound and I want to know why it's happening.
That there's no "sound history" to go on means I'm left muting random applications until I find it the cause. But if there's an entry in the list with no name available (or worse, the wrong name when a PID get reused) how is this going to help me track down the rogue app? I see a best case scenario being "Ah ha! There's the bugger! Now I wait patiently for it to relaunch so I can see it's name." (That assumes it updates realtime). And worst case being a complete miscarriage of justice as I uninstall the unlucky program that took the PID.
I'm not saying it's a totally bad idea, but maybe it should have been an advanced option defaulted to not display the extra information. And maybe an option to display even more information related to processes playing sounds (EXE name, PID, history, etc.).
I imagine with basic to intermediate users this would actually cause more calls for support than it would fix.
I think this feature makes sense. Let's say some app makes a sounds as it exits, so a user goes to the mixer to see what app could have made the sound. If they only see the currently running apps, they are liable to assume that one of those made the sound. If they see an unnamed app, they are able to see that some app other than those currently running could have been the culprit.
It's called a timeout queue. I have recently had to implement such a feature for my own component. If some information is unreliable, then simply keep a reliable copy of it around for 'a while' say 10 sec after it terminates. Clean it up afterwards. Should the app relaunch again, you'd have to link up with this 'reliable copy' of course to prevent lots of duplicates being generated...
is PID reuse really a concern? The PID is a DWORD, so there are 4 billion unique IDs before they need to be reused.
Even if you create one process per second, every power supply I know needs to be replaced before a PID is reused.
Or is the handle internally reused? Then why not give it a new PID?
Maybe I'm missing something here, haven't cared much about CreateProcess and PIDs yet.
Andre: A PID is essentially a handle, and as such it can be reused just like handles can be reused.
On checked builds of Windows, there's actually code in the handle manager to enhance the likelihood that a handle gets re-used (I don't know if the same is true for PIDs).
Also why don't you just use the process creation time (GetProcessTimes) to figure out if a PID has been reused?
Thanks for your reply Larry. I understand that it makes sense to reuse processes internally but the handle manager could assign a new unique handle to it and also like on FreeBSD the PID could just be a counter.
What's the rationale behind handle/PID reuse?
It's more efficient. Ultimately a handle maps to an object.
If the handle is just a counter, then you need to do a linear scan through your list of open objects until you find the object that matches the handle. If your handle is more complicated you can use a more sophisticated data structure to represent your handle. The downside of using a more sophisticated structure is that your handles can get re-used.
I'm not aware of any Win32 functions that take a PID, they all want the handle. So why is the PID reused too?
I would also be great if you could comment why you are not using the process creation time to figure out if a handle/PID has been reused.