Fixing a customer problem: “No Audio Device is Installed” when launching sndvol on Windows Vista

Yesterday someone forwarded me an email from one of our DirectShow MVPs – he was having problems playing audio on his Windows Vista machine.

 

Fortunately David (the MVP) had done most of the diagnostic work – the symptoms he saw were that he was receiving a “No Audio Device is Installed” error launching sndvol (and other assorted problems). 

David tried the usual things (confirming that the driver for his audio solution was correctly installed (this probably fixes 99% of the problems)).  He also tried reinstalling the driver to no avail.

He next ran the Sysinternals Process Monitor tool to see what was going on.  He very quickly found the following line in the output from process monitor:

"RegOpenKey", "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render\{e4ee1234-fc70-4925-94e9-4117395f7995}", "ACCESS DENIED", "Desired Access: Write"

With that information, he looked for the ACL on that registry key:

He then looked at the configuration for the Windows Audio service:

Woah – the Windows Audio service doesn’t have access rights to that registry key – the Windows Audio service is running as LocalService and the LocalService account doesn’t have any access to the registry key.

At this point he decided to contact Microsoft with his problem.

I looked at his info and quickly realized that the problem was that somehow the ACL on the registry key had been corrupted: something had removed the entries for the audio services.  On a normal Windows Vista installation this registry key’s ACL should look something like:

Something that ran on David’s machines went in and reset the permissions for this registry key to the ACL that is on the root node of the HKEY_LOCAL_MACHINE\Software registry hive.  I have no idea what did this, but messing with the ACLs on the registry is a known cause of various compatibility problems.  That’s why Microsoft KB 885409 has such strong warnings about why it’s important to not apply blind modifications to files or registry keys in Windows.  It’s unfortunate, but the warnings in the KB articles that say that modifying registry keys or permissions can cause your machine to malfunction are absolutely right – it’s not hard to make modifications to registry keys that can really screw up a machine, if you make the right ones.  From the KB article:

For example, modifications to registry ACLs affect large parts of the registry hives and may cause systems to no longer function as expected. Modifying the ACLs on single registry keys poses less of a problem to many systems. However, we recommend that you carefully consider and test these changes before you implement them. Again, we can only guarantee that you can return to the recommended out-of-the-box settings if you reformat and reinstall the operating system.

The good news is that it should be relatively simple to fix David’s problem – As far as I know, he has two options.  The first is to reinstall Windows Vista – that should reset the ACLs on the property key to their default values (because it will recreate the property keys), which should resolve the problem.

The second solution is to add an ACL to the registry keys under the MMDevices registry key to allow the LocalService account to have permissions to modify this registry key.

Comments

• Anonymous
  January 06, 2009
  Isn't there a 'default' security template (applied via a snap-in to MMC) that would fix this? I seem to recall using this to solve another ACL problem at one point...

• Anonymous
  January 06, 2009
  Let's hope that the second option works, because "reinstall your OS" is a pretty heavy hammer to have to bring out no matter what your problem is.

• Anonymous
  January 06, 2009
  I wonder if Zooba may be referring to: "How to reset security settings back to the defaults" @ http://support.microsoft.com/kb/313222

• Anonymous
  January 06, 2009
  "reinstall your OS" probably means installing over the existing one, not reformat. It is probably easier than manually fixing registry permissions - it's certainly easier to guide someone to do it over the phone. And who knows how many more random registry corruptions the mystery corrupter did?

• Anonymous
  January 06, 2009
  What I wonder is why “No Audio Device is Installed” can be caused by "access denied". The problem is almost certainly not passing the error code between layers -- that is, if (failure) {return ENODEV}, instead of if (failure) {return errno} or equivalent.  What amazes me is how often I still see this kind of mistake.

• Anonymous
  January 07, 2009
  theorbtwo: Actually the UI turns any failures into "No Audio Device is Installed".  It's simpler :).

• Anonymous
  January 07, 2009
  It's probably reasonable for the tray icon to show "No Audio Device is Available", but if you visit the Multimedia Control Panel there ought to be a more detailed explanation there. If protecting users from themselves requires dumbing down error messages, provide full errors in some sensible part of the UI that would typically be used by admins/advanced users.

• Anonymous
  January 07, 2009
  It's very annoying troubleshooting a software issue when the error message:

• is not related to or reflecting the actual problem (as in this case)
• does not contain all information (e.g. "error: unable to open file", without specifying the file path ...) You would at least expect the actual error code/technical description to be logged in the Windows Event Log, or perhaps in a piece of error message UI that is hidden by default ("click to show error details"). Sadly this is often not the case, and you have to use special tools that can consume quite a lot of time. There are more fun things than analyzing endless registry requests ... Several times I've noticed that certain applications will try to read/write a registry key/value and, upon failure (e.g. ACL issue), will try again, in an infinite loop, consuming all CPU time...

• Anonymous
  January 07, 2009
  Mike: On the other hand, "Access is denied" is completely unactionable on the part of the user.  

• Anonymous
  January 07, 2009
  The comment has been removed

• Anonymous
  January 08, 2009
  Forget you haters, Larry's right.  In fact, I think all UI error messages should be replaced with "Something happened."  This message should be displayed on success or failure.  It's much easier.

• Anonymous
  January 08, 2009
  Interesting idea, Owen.   But if we're going to pursue that route, printing "Something happened" seems needlessly complex.  After all, it needs to be translated into dozens of different languages.  What do you say to just a smiley face? To be serious, the core problem here is that Windows is still based on the idea that a 32 bit integer is all that is needed to report an error.  This may have made sense back in DOS, when you were practically taking directly to the hardware.  But in the modern age, you talk to a sub-system that talks to a sub-system, that calls some other system that talks to a service, etc.  Each release seems to add another level of indirection, always for the best of reasons. As a result, by the time any error gets back to the caller, you have no idea who was doing what when things went wrong.  You are lucky to even get the actual error number from the original failing call, as more likely than not it got turned into a BOOL, or rolled up into a general E_FAILED. This issue highlights this exact problem.  As Larry will no doubt soon point out, there is no way for the caller to find out what registry key was at fault, and there is currently no mechanism for the callee to report that kind of detail. There is no simple fix here.  Even if the audio system were re-written to work with error structs rather than ints, that’s still just a small corner of a large OS.  But the next time you see an error, stop for a moment and think: Somewhere down near the bottom of the call stack, someone knew EXACTLY what went wrong, and rather than provide you with that information, they gave you “FALSE” instead.  That's great for ease of programming, but lousy for ease of maintenance. I’m not trying to bash MS here.  Vista is an enormously complex system, and is no doubt growing more complex as we speak.  And adding the type of error reporting I’m advocating isn’t going to make the code any smaller.  However, as systems become more complex, the need for adequate diagnostics also increases. The day has arrived when smiley faces are no longer sufficient.  Sorry about that Owen.

• Anonymous
  January 08, 2009
  The comment has been removed

• Anonymous
  January 14, 2009
  i am your average user, ive had no sound for months.. been going down the driver path for ages to no avail, then gave up trying and now im back on the case. going to give my laptop to a more than average user and let him know about this registry issue cos all i want is a little sound, not much to ask is it?? interesting read guys, i hope i get some luck

• Anonymous
  January 17, 2009
  Heh... >>Actually the UI turns any failures into "No Audio Device is Installed".  It's simpler :).<< But why the source of an error doesn't log it into system event log? Isn't it important enough? Also, is the write permission to that key really neccessary?

• Anonymous
  January 18, 2009
  Igor, the errors aren't logged because as a general rule of thumb, you don't log the vast majority of failures to the event log UNLESS you can provide relevant diagnostic information (which you can't in this case).  Every write to the event log takes hundreds of milliseconds and consumes disk space (and event log space) so it's important not to spam the eventlog with what are potentially bogus values.   And yes write permission to the key IS really necessary.

• Anonymous
  January 21, 2009
  In order for the error message/logging to be useful, the system would have to be able to self-report any possible thing that it believed might be wrong with it.  There are infinite ways to hork your machine, so getting that error message/logging useful and actionable would probably be extremely difficult.  And in this case, if something messed up the ACL on one registry key that sndvol depends on, it probably messed up lots of other ACLs too.  Unless you have a restore point to roll back to, reinstalling will probably solve a lot of other problems you're going to run into sooner or later anyway.

• Anonymous
  February 19, 2009
  BTW, using PNG instead of JPG for screenshot is much better.