In this case, the COM component happens to be a video codec. Let’s say, divx.dll.

Normally, COM components are loaded “in-proc” (in process). That would mean that Explorer.exe would load this DLL in order to pull those frames out of the video.

The problem is, if that DLL crashes, then Explorer crashes right along with it. So instead, Explorer is basically protecting itself by telling COM to load the DLL in a surrogate process. In this case, the surrogate is probably DLLHost.exe.

There are other surrogates, too, for more specialized purposes. Svchost.exe hosts a DLL that runs as a service. Prevhost.exe hosts previews for Explorer’s preview pane. SearchFilterHost.exe hosts IFilters for indexing files and other data.

Those last two are specialized surrogates, because they only work with a specific kind of COM component, and because they are run as “low integrity” processes, just like Protected Mode IE. That means they can’t even read or write the filesystem. That way, if there’s a security problem with a certain type of file they’re previewing or indexing (or a problem certain store, like Outlook or Windows Mail) – it won’t get triggered or be able to do any harm. An example of this was the .WMF vulnerability last year. Whereas Google Desktop Search and Copernic would trigger the WMF vulnerability during indexing, WDS did not (technically it did, but the exploit couldn’t actually do anything because it was isolated or sandboxed in this way).