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 (18)

  1. Zooba says:

    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…

  2. Nathan says:

    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.

  3. molotov says:

    I wonder if Zooba may be referring to:

    "How to reset security settings back to the defaults" @

  4. Jonathan says:

    "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?

  5. theorbtwo says:

    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.

  6. theorbtwo: Actually the UI turns any failures into "No Audio Device is Installed".  It’s simpler :).

  7. Ben Voigt says:

    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.

  8. Mike says:

    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…

  9. Mike: On the other hand, "Access is denied" is completely unactionable on the part of the user.  

  10. LGS says:


    You are right that "Access is Denied" is no more actionable than "No Audio Device".  However, it does have the (minor) virtue of being true, unlike the current message which only points people in the wrong direction.  What you really need is "Access Denied while reading registry key xyz." I do understand the thinking that printing something like that would be intimidating to most users, but that’s why I think Mike was suggesting a "More Details" button.  It’s even consistent with other MS technologies.

    After all, eventually, SOMEONE is going to have to track this down.  Whether that someone is a corporate support staff, an MVP in his living room, or an MS technician, somebody will need to figure out what’s actually going on, and that task is needlessly difficult when the only available error description is not only so minimalistic, but wrong.

    If you had been diagnosing this problem, how much time would you have spent re-installing drivers or pursuing other avenues before looking at the permissions in the registry?  Compare that with how quickly you were able to grok this problem with that simple, one line message from Process Manager along with a dump of the registry key permissions.

    No matter how hard you try to protect against it, stuff happens.  And when it does, people need to be able to figure out what went wrong.  And accurate, detailed error messages are essential to making that happen.

  11. Owen says:

    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.

  12. LGS says:

    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.

  13. ncgloy says:

    Think about this from the perspective of the average Windows user — not totally clueless, but not able to use ProcessMonitor to diagnose stuff.  Audio stops working.  "No Audio Device installed".  The only choice is to reinstall Vista.  God knows how much stuff (settings, tools, files) goes missing during that reinstall.  So the user experience is: if the slightest thing goes wrong, you can’t find out what caused it, and you have to re-install the OS.  What year is this ?  2009 ?

  14. nickydj says:

    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

  15. Igor Levicki says:


    >>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?

  16. 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.

  17. 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.

  18. n/a says:

    BTW, using PNG instead of JPG for screenshot is much better.