Epic Fail: SonicFocus Component in audiodg

Friday 6 November 2009 - Filed under Uncategorized

I’ve had periodic issues with my work machine keeling over, ever since I got it. Since I can’t reinstall the operating system (the usual fix for this kind of garbage), I’ve just let it slide for the most part… until now.

I happened to be running Process Explorer the other day to get a decent look at whether a memory leak was still happening in one of my components, and noticed that one particular system process had an absurd handle count (around 1.6M), increasing by ~20/s. This is `audiodg.exe`, which the internet tells me is the “audio device graph isolation process”.

Some more digging around reveals that this process is something I didn’t ask for, can’t possibly want, and exists purely to do two things:

1. Isolate the “sensitive” parts of the audio device graph functionality in a process that can be given special protection, unlike the svchost in which Windows Audio / Audiosrv runs.

   Of course, there’s no possible reason that I (as an end user, or as a developer) could want this functionality. Screw system components that exist to protect my data from being tampered with by… me. (Btw, I have no DRM-protected music on this system).

2. Host buggy third-party plugins provided by my audio chip manufacturer, in such a way that the process can fall over without taking a collection of other services with it. Oh wait, I thought that was what the “own process” vs “shared process” flags in the SCM were for? But I digress…

   The audio chip in this case is the usual piece of SoundMax/SonicFocus garbage, whose developers’ notion of quality software *still* includes providing a broken substitute for the builtin volume control, spamming up the notification area, chewing through memory for no reason, spinning on a CPU core, and generally being a bad software citizen.

   Needless to say, I don’t give a rat’s ass about the ability to do this either. Especially in conjunction with the “protection” features that prevent me from interfering with these buggy plugins when they break. Good job.

So, there’s no reason that I want device graph isolation. But apparently I can’t do anything about it, because that’s just the way Windows does it now.

Anyway, let’s have a look at what all these handles are. Enter procmon, which happily shows this being opened approx 20 times / second and then apparently forgotten about:

7996    9:27:48.0323030 a.m.    AUDIODG.EXE    1212    RegOpenKey    HKLM\Software\SonicFocus\{0.0.0.00000000}.{02420E38-7F43-45C3-8C7A-26C5946A5FCB}    SUCCESS    Desired Access: Maximum Allowed

A quick registry tree rename later, we’re back to a stable handle count and 20 requests per second that fail:

8070    9:41:48.0830628 a.m.    AUDIODG.EXE    1212    RegOpenKey    HKLM\Software\SonicFocus\{0.0.0.00000000}.{02420E38-7F43-45C3-8C7A-26C5946A5FCB}    NAME NOT FOUND    Desired Access: Maximum Allowed

Owned. As for why they feel the need to read all these keys 20 times per second… beats me, but my system is stable now.

The takeaway: SonicFocus’s sound render plugin is crap and broken, allocating handles out the wazoo and dropping them on the floor. Windows compounds the issue by running it in a process that’s protected from the user. However, you can still fix it by intentionally breaking a registry tree.

2009-11-06  »  admin