Debugging a problem: Audio stops working after an XP SP2 install

re: Debugging a problem: Audio stops working after an XP SP2 install

Norman Diamond — Thu, 19 Aug 2004 01:14:00 GMT

8/17/2004 8:11 PM Larry Osterman

> If you find a DLL that wasn't signed by
> Microsoft (or other 3rd party code) running
> in a shared svchost instance

But you said previously that this wasn't even possible. If a virus installs itself as a service then it must be in a non-shared instance and it is safe to kill the thing.

> And it's likely that you need to pave the
> machine

By the way I did pave one friend's machine because he got an MBR virus while Windows XP was running. Repeatedly I booted the Windows XP to the repair console, FIXMBR warned that the MBR was nonstandard but I proceeded and FIXMBR said it fixed the MBR, but it was lying. Finally had to delete all partitions including the miniature FAT32 C partition, recreate a new miniature FAT32 C partition, recreate a new NTFS D partition and continue reinstallation from there. I did some Googleing to find if it's really possible for a virus to infect an MBR while XP is running, and it seems there is one that can do it.

I haven't decided yet whether to pave another friend's machine. This one did have a ton of viruses in RUN keys in the registry and other places. I left it with no visible viruses, but guess he probably still has a few hundred less visible ones. I don't have another full day free to help him blowtorch his hard disk and start over though.

re: Debugging a problem: Audio stops working after an XP SP2 install

Larry Osterman — Wed, 18 Aug 2004 16:26:00 GMT

DrPizza, the savings is several hundred kilobytes per service - several hundred kilobytes of PHYSICAL memory, not virtual memory. That's NOT a "munute memory saving", it's significant.

And if you start splitting up shared services, then things WILL break. I can absolutely 100% guarantee it. Many of the services running in shared svchost processes have assumptions that other services are running in the same process, and will break if they're not present.

re: Debugging a problem: Audio stops working after an XP SP2 install

DrPizza — Wed, 18 Aug 2004 09:23:00 GMT

"Iain, the reason I didn't describe them is that nobody except someone debugging the windows audio service has a reason to split it out."

This is utter bollocks.

Various shared services can hang. There's no way to restart them without killing the entire process. This is a big problem, because it also kills the other shared processes which is not what you want.

If a shared service has a tendency to hang, it's convenient to split it out.

Frankly, I find the shared services a pain in the butt, and can't see any real justification for it. A minute memory saving perhaps?

re: Debugging a problem: Audio stops working after an XP SP2 install

Pavel Lebedinsky — Wed, 18 Aug 2004 04:03:00 GMT

> If you find a DLL that wasn't signed by
> Microsoft (or other 3rd party code) running
> in a shared svchost instance, you can be
> pretty certain that someone's infected your
> machine.

Some of the services running in shared svchosts (like TAPI for example) can load 3rd party DLLs (TAPI service providers). This is a supported scenario.

re: Debugging a problem: Audio stops working after an XP SP2 install

Larry Osterman — Wed, 18 Aug 2004 03:11:00 GMT

Norman, once again, this is a non sequiteur.

If you find a DLL that wasn't signed by Microsoft (or other 3rd party code) running in a shared svchost instance, you can be pretty certain that someone's infected your machine.

And it's likely that you need to pave the machine because you have no idea what has happened. Run an anti-virus scan immediately.

But saying that it's safe to kill the process is silly. Some of these processes (winlogon.exe for example) are critical to the functioning of the system and will immediately cause a bluescreen.

A more accurate statement is that if you find code running in svchost.exe that wasn't signed by Microsoft you need to start looking very, very carefully at the system to ensure that someone hasn't tampered with it. But killing random processes is a recipe for disaster.

Edit: Sorry, Norman - I have a problem spelling your name for some reason. I have no idea why I have this mental blank there, sorry.

re: Debugging a problem: Audio stops working after an XP SP2 install

Norman Diamond — Wed, 18 Aug 2004 00:23:00 GMT

8/17/2004 12:29 AM Larry Osterman

> Btw, as a tidbit of information, no 3rd
> party code is allowed to run in a shared
> svchost process

This is helpful, thank you. So if a virus installs itself as a service then it will be safe to kill that process, because no genuine services will be sharing the same process.

> Oh, and Norman, in this case, the user
> accidentally did it.

OK thank you. By the way I have no complaint about the change in partition policy that came about with Windows 2000. It used to be possible for Windows NT4 to be installed into the same partition as either 95 or 98. Nonetheless, both then and now it is safer to install into separate partitions. I just wish that Windows XP would remember that, for more than two reboots after I tell it to.

Why didn't XP SP2 install copy the right SP2 DLL when there was a DLL with a higher version number on the machine?

Larry Osterman's WebLog — Tue, 17 Aug 2004 20:40:00 GMT

re: Debugging a problem: Audio stops working after an XP SP2 install

Larry Osterman — Tue, 17 Aug 2004 07:29:00 GMT

Pavel, I didn't know that they were documented anywhere. Cool :) Ok, anyone wanting to know the registry changes I made can look at the KB article that Pavel pointed to and figure them out.

Iain, the reason I didn't describe them is that nobody except someone debugging the windows audio service has a reason to split it out. I do it all the time, so I need to know that, but for customers, it's not particularly relevant stuff. And the only reason I break audiosrv out is if I want to get the symbols off the net. If the symbols are on the local machine, I usually just leave it where it is.

And if you start randomly pulling services out of svchost groups (for "diagnostic purposes"), then the system WILL start breaking. Many of these services are designed to work in the same process, and will break in subtle ways if they're pulled out. And no, once again, I'm not going to tell you which ones will break. You start messing with the registry and you're on your own.

I don't want to hear that someone called PSS to get their machine fixed up and told PSS that Larry Osterman told them how to split services out from the svchost process in which they were designed to run. As Pavel said: Changing the default configuration is NOT supported.

Btw, as a tidbit of information, no 3rd party code is allowed to run in a shared svchost process - because the svchost processes are services that are required for system reliability, we don't allow any 3rd party code in them. Please note: a SHARED svchost process. There are svchost processes that only run one service (like the spooler service).

Oh, and Norman, in this case, the user accidentally did it. He ran a script to install a component he was working on that copied a longhorn version of a DLL to his machine (actually it copied a bunch of DLLs to his machine, audiosrv.dll was the only one that caused problems). For the work he was doing, he was able to mostly get away with it (back last year when he did it), running the same script nowadays would fail (since there's now a version check).

re: Debugging a problem: Audio stops working after an XP SP2 install

Iain — Tue, 17 Aug 2004 05:23:00 GMT

I'm curious. How can you say "nobody needs to know them" of the registry modifications when they made your life easier? Surely this would have been much more painful without them?

re: Debugging a problem: Audio stops working after an XP SP2 install

Pavel Lebedinsky — Tue, 17 Aug 2004 01:09:00 GMT

Actually, svchost registry settings are documented in http://support.microsoft.com/?id=314056

I think this is mostly for troubleshooting purposes - changing the default configuration is probably not supported.