Case Of The Outlook Search "No Results"

On a machine with Outlook 2010 to maintain Exchange 2003 support + Office Communicator 2007 R2 Client + Word/Excel/PowerPoint from Office 2013 (All non App-V installs) running on Windows 8 x64, Outlook search was totally broken:


This is not a recommended combination of software by the way…so it shouldn’t be a surprise there are issues :)

However when launched in Outlook /Safe:3 mode (Safe:3 disables add-ons but doesn’t reset toolbar or reading pane as compare to Outlook /Safe)

You can do this in Windows 7 or Windows 8 by just typing the parameters in the start menu and hitting enter:


Search worked fine:


OK so you might think immediately add-ins are the cause…right?

Well that  is what you would normally expect when safe mode worked, but in this case I had already disabled all add-ins!


I suspected something funny though was going on so I used ProcMon and filtered on

  • Process Name is Outlook.exe – Include
  • Operation is Load Image

This will log each DLL the Process Loads. I took one log running Outlook normally, and when in /safe:3 mode.

I then exported results as CSV and Beyond Compare’d them – the key difference being loading of C:\Windows\SysWow64\mssprxy.dll in the Outlook where search was broken:


Checking DLL properties MSSPrxy.DLL looked like a good candidate to blame as it was called Microsoft Search Proxy

How did it get loaded? Well I filtered ProcMon on

  • Process Name is Outlook.exe – Include
  • Details Contains MSSPrxy.dll – Include
  • Operation is RegQueryValue – Include

This led me to the key HKCR\Wow6432Node\CLSID\{A5EBA07A-DAE8-4d15-B12F-728EFD8A9866}



To prove this was the issue I used reg edit to temporarily rename this key. Note you should use extreme caution doing this as you can damage your system. I also had to use RegEdit to Take Ownership and grant me permission to modify the key, as normally it can only be modified by trusted installer. Normally this is a clue to not touch, so if you’re not sure – just leave it.

I renamed key with an underscore


Restarting Outlook, sure enough search was working. Of course by renaming this key I have probably broken something else, so this is a workaround.

In IDA Pro I viewed the strings in the DLL (or I could have used ) and noticed this DLL implemented several COM interfaces


I launched outlook with WinDbg, from the Windows SDK. When launching an application via WinDbg it will immediately “break” you then hit g [enter] to go and continue running application.

I noticed in the Outlook instance when broken, as soon as I typed in a search query, that was when the following DLLs would load:

ModLoad: 63310000 63379000   C:\Windows\SysWOW64\StructuredQuery.dll
ModLoad: 744e0000 744e9000   C:\Windows\SysWOW64\Secur32.dll
ModLoad: 542f0000 543db000   C:\Windows\SysWOW64\NaturalLanguage6.dll
ModLoad: 53b30000 53fe5000   C:\Windows\SysWOW64\NLSData0009.dll
ModLoad: 50860000 50ae3000   C:\Windows\SysWOW64\NLSLexicons0009.dll
ModLoad: 77d50000 77ff6000   C:\Windows\SysWOW64\tquery.dll
ModLoad: 67bb0000 67bc3000   C:\Windows\SysWOW64\query.dll

However in Safe Mode the following DLLs never load

  • StructuredQuery.dll
  • tquery.dll
  • query.dll

We would also see in our BeyondCompare of the ProcMon Load Image


When In WinDbg, and after completing a broken search to load these DLLs, I then broke into the debugger, and looked for available functions in query DLL using


x query!*

0:023> .reload
Reloading current modules
0:023> x query!*
61adf140          query!_imp__InterlockedIncrement = <no type information>
61ad874c          query!CDefWordBreaker::Init (<no parameter info>)
61ad38e8          query!CNullIFilter::QueryInterface (<no parameter info>)
61adf17c          query!_imp__RegSetValueExW = <no type information>


No I wasn’t sure what function might be used, so I could have set a breakpoint when any memory was accessed on any of these functions:

bm /a query!*

But instead opted for a breakpoint on DllGetClassObject

bp query!DllGetClassObject

However I didn’t find anything obvious down this path…

Than I tried an older version of the DLL (7.0.9200.16385) from a Windows 7 machine with only Office 2010 installed, replacing the file v7.0.9200.16578 in C:\windows\syswow64 with the Windows 7 one. (This is a bad idea, and I do not recommend it, this is just for experimentation, or to get a system working in an unsupported hacked state, potentially breaking other stuff)


I did a dump of both DLLs, sorted the results alphabetically, and only kept results starting with I

What I found:

The new DLL no longer had:

  • IGatherInlineStatus
  • IGatherNotify3
  • IGatherNotify4
  • IGatherNotifyInlineInternal

Whereas the new one added:

  • ISearchCrawlScopeManagerInternal
  • ISearchManager2
  • ISearchManagerVolume
  • IUnknown_AddRef_Proxy
  • IUnknown_QueryInterface_Proxy
  • IUnknown_Release_Proxy

In IDA, notice old has IGatherInlineStatus and IGatherNotifyInline

Old New
image image

I then looked up IGatherInlineStatus on MSDN, which was referenced in the Windows 7 SDK SearchAPI.h:

#ifndef __IGatherInlineStatus_INTERFACE_DEFINED__
#define __IGatherInlineStatus_INTERFACE_DEFINED__

/* interface IGatherInlineStatus */
/* [helpstring][unique][uuid][object] */

EXTERN_C const IID IID_IGatherInlineStatus;

#if defined(__cplusplus) && !defined(CINTERFACE)
    IGatherInlineStatus : public IUnknown
        virtual HRESULT STDMETHODCALLTYPE SendInlineStatusChange(
            /* [in] */ DWORD dwClientID,
            /* [in] */ SEARCH_INDEXING_PHASE sipStatus,
            /* [in] */ DWORD dwNumEntries,
            /* [size_is][in] */ __RPC__in_ecount_full(dwNumEntries) SEARCH_ITEM_INDEXING_STATUS rgItemStatusEntries[  ]) = 0;
#else     /* C style interface */

    typedef struct IGatherInlineStatusVtbl
        HRESULT ( STDMETHODCALLTYPE *QueryInterface )(
            __RPC__in IGatherInlineStatus * This,
            /* [in] */ __RPC__in REFIID riid,
            /* [annotation][iid_is][out] */
            __RPC__deref_out  void **ppvObject);
            __RPC__in IGatherInlineStatus * This);
            __RPC__in IGatherInlineStatus * This);
        HRESULT ( STDMETHODCALLTYPE *SendInlineStatusChange )(
            __RPC__in IGatherInlineStatus * This,
            /* [in] */ DWORD dwClientID,
            /* [in] */ SEARCH_INDEXING_PHASE sipStatus,
            /* [in] */ DWORD dwNumEntries,
            /* [size_is][in] */ __RPC__in_ecount_full(dwNumEntries) SEARCH_ITEM_INDEXING_STATUS rgItemStatusEntries[  ]);
    } IGatherInlineStatusVtbl;

    interface IGatherInlineStatus
        CONST_VTBL struct IGatherInlineStatusVtbl *lpVtbl;


But then on the MSDN reference for Windows 8 Desktop Development:


In a future article we may look at this further in depth to confirm if this is what “broke” Outlook Search…

About chentiangemalc

specializes in end-user computing technologies. disclaimer 1) use at your own risk. test any solution in your environment. if you do not understand the impact/consequences of what you're doing please stop, and ask advice from somebody who does. 2) views are my own at the time of posting and do not necessarily represent my current view or the view of my employer and family members/relatives. 3) over the years Microsoft/Citrix/VMWare have given me a few free shirts, pens, paper notebooks/etc. despite these gifts i will try to remain unbiased.
This entry was posted in Debugging, Office, ProcMon and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s