Question: I've implemented an IFilter as a native VC++ ATL in-proc COM server. Windows Search wouldn't use it - it creates an instance of my IFilter and then executes a bunch of QueryInterface() calls, specifically:

* IMarshal
* IStdMarshalInfo
* something with {4C1E39E1-E3E3-4296-AA86-EC938D896E92} interface id

and a couple of others. Since my IFilter only implements IFilter, IPersist and IPersistFile most of the calls return E\_NOINTERFACE, so Windows Search just releases my object and does nothing.

Why is it querying for those interfaces and how do I work the problem around?

Answer: 
One of the reasons you see "unusual" behavior from time to time is Application Compatibility (appcompat). If there are other, broken filters that (unreasonably) expect to have these interfaces queried, and those are written by big companies, then Microsoft may keep querying just to keep these filters happy. Proper implementations should not be affected by this appcompat, because they would just follow COM rules and return E\_NOINTERFACE.

[Another reason](http://blogs.msdn.com/oldnewthing/archive/2004/02/20/77120.aspx), courtesy of Raymond Chen. "This is a sure sign that you didn't register your CLSID properly"

*edit* : And [another reason to query for interfaces that don't actually exist](http://blogs.msdn.com/oldnewthing/archive/2004/02/11/71307.aspx), again explained by Raymond.
Does this shed any light for you? [COM proxy stub dll and why do you need it](http://blogs.msdn.com/eldar/archive/2006/02/28/540981.aspx). The IID you mention is one of the IIDs mentioned in the article.