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
  話題の小向美奈子ストリップを隠し撮り！入念なボディチェックをすり抜けて超小型カメラで撮影した神動画がアップ中！期間限定配信の衝撃的映像を見逃すな