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?
Windows tries check if your interface supports custom marshaling, the only way he can do that is using QueryInterface(...) to those well known interfaces (well, semi well known).
The COM layer expects that some interfaces will return E_NOINTERFACE and knows how to deal with it.
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, 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, again explained by Raymond.
Have you tried aggregating the free threaded marshaller (CoCreateFreeThreadedMarshaller in your component (? That may be enough to get your component working with windows search.
Does this shed any light for you? COM proxy stub dll and why do you need it. The IID you mention is one of the IIDs mentioned in the article.
来源：https://stackoverflow.com/questions/1714926/why-would-windows-search-query-my-ifilter-for-a-bunch-of-weird-interfaces