Finetuning für Experten
Falls bekannt sein sollte, welche Programme unvollständige Pfadangaben für benötigte DLLs enthalten, kann man diese auch gezielt blockieren. Weiterhin kann man auf diese Weise auch Ausnahmen von der systemweit gesetzten Sperre definieren, um Anwendungen, die mit dem beschränkten Suchpfad Probleme haben, auszuklammern. Hierzu wird für jede Anwendung ein neuer Registrierungsschlüssel sowie der passende Wert hinterlegt. Der neue Schlüssel trägt schlicht und einfach den Dateinamen der betroffenen Anwendung und wird in folgendem Unterschlüssel angelegt:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

Fotostrecke mit weiteren und größeren Fotos...

Nun öffnet man den frisch erstellten Programmschlüssel und hinterlegt den DWORD-Wert "CWDIllegalInDllSearch" wie zuvor beschrieben. Abermals stehen die Werte "FFFFFFFF", "1" und "2" zur Auswahl und haben die selbe Bedeutung wie bei der allgemeinen Beschränkung, wirken sich diesmal aber nur auf die durch den Schlüsselnamen definierte Anwendung aus.

Fotostrecke mit weiteren und größeren Fotos...

Bekannte Probleme mit bestimmten Anwendungen
Einige Programme haben Probleme nach dem Ausschluss des aktuellen Arbeitsverzeichnisses aus dem DLL-Suchpfad. Hier eine Übersicht der uns bekannten Anwendungen sowie die dazugehörigen Lösungsvorschläge:

• Google Chrome: Googles Webbrowser Chrome kommt - abhängig vom System - aufgrund des veränderten DLL-Suchpfades durcheinander und vermisst die Bibliothek "avutil-50.dll". Sobald man für "chrome.exe" den Wert "0" definiert, funktioniert der Webbrowser wieder normal.
  
  
• Valve Steam: Auch Steam und Steamworks stolpern über das fehlende Arbeitsverzeichnis im DLL-Suchpfad. Man kann zwar bereits installierte Spiele ausführen, der Kauf neuer Titel scheitert jedoch ebenso wie das Erstellen von Verknüpfungen auf dem Desktop. Ausnahmen mit dem Wert "0" müssen für "steam.exe" und "SteamService.exe" definiert werden. (Danke an ThePreacher für diesen Hinweis!)

Abschließende Worte
Seit langer Zeit weist Microsoft alle Programmierer darauf hin, dass man bei der Verwendung von Dynamic Link Libraries vollständige Quellpfade verwenden sollte. Der schwarze Peter wird somit den Programmierern zugeschoben und das durchaus zu Recht. Dennoch muss die Frage erlaubt sein, warum ein Betriebssystem fehlende Bibliotheken überhaupt in Arbeitsverzeichnissen sucht. Dass das jeweilige Programmverzeichnis sowie die Ordner des Betriebssystems berücksichtigt werden, können wir nachvollziehen, doch nur weil ein Ordner eine zu öffnende Datei enthält, muss er noch lange nicht so sicher sein, dass man aus diesem auch Programme ausführen würde. In Zeiten, wo sich ein Arbeitsverzeichnis quasi überall befinden kann, steckt in Microsofts Ansatz ein konzeptioneller Fehler, der die Schlampigkeit vieler Entwickler erst zum Sicherheitsrisiko werden lässt. Weitere Informationen zu diesem Problem finden sich im Knowledge-Base-Artikel KB2264107 von Microsoft.