Share via


Breaking the monolithic Filter dll.

An issue came up recently where the architecture of one of our filters had to be changed. The change involved making the filter dll dependent on a few other dlls dropped during the installation process.

 As with all revolutionary changes, the Search Daemon revolted when we tried to index contents using this new incarnation of the filter.After few hours of breaking my head with windbg, it came to light that while the filter dll was made dependent on some other dll's (in the same folder) , we still used the old COM : LoadLibrary call to load the filter.Now since the installation folder of the filter dll was not included in the system path, when the filter dll made calls to the other dll's, the system crashed as it had no idea how to locate these dependent dlls.

If you find yourself running into the same situation, the workaround is simple: Just add the directory of installation (where the filter and dependent dlls reside) to your system path.Ideally, your installer should do this to prevent revolting actions by the software. 

The other alternative is to use WINAPI <SetDllDirectory> function call which adds a SearchPath used to locate DLLs for the application. For details, please refer to:

http://msdn2.microsoft.com/en-us/library/ms686203.aspx

Comments

  • Anonymous
    November 20, 2006
    Please make it clear that you should be doing this PATH setting only inside the process. We do NOT need yet another program adding itself to our PATH environment variable for the once-in-a-million time it might be needed.

  • Anonymous
    November 20, 2006
    I agree that the second alternative is preferred to adding a new entry in the PATH variable.

  • Anonymous
    November 30, 2006
    The comment has been removed

  • Anonymous
    February 08, 2007
    Ever since I started dealing with filters, I've seen numerous questions regarding "What does the proper

  • Anonymous
    June 13, 2009
    話題の小向美奈子ストリップを隠し撮り!入念なボディチェックをすり抜けて超小型カメラで撮影した神動画がアップ中!期間限定配信の衝撃的映像を見逃すな