DLL Search Order Changed in Latest Windows

Development Comments

I found the following breaking change in the MSDN article "Development Impacts of Security Changes in Windows Server 2003" by Michael Howard:

DLL Search Order Has Changed

No longer is the current directory searched first when loading DLLs! This change was also made in Windows XP SP1. The default behavior now is to look in all the system locations first, then the current directory, and finally any user-defined paths. This will have an impact on your code if you install a DLL in the application's directory because Windows Server 2003 no longer loads the 'local' DLL if a DLL of the same name is in the system directory. A common example is if an application won't run with a specific version of a DLL, an older version is installed that does work in the application directory. This scenario will fail in Windows Server 2003.

The reason this change was made was to mitigate some kinds of trojaning attacks. An attacker may be able to sneak a bad DLL into your application directory or a directory that has files associated with your application. The DLL search order change removes this attack vector.

The SetDllDirectory function, also available in Windows XP SP1, modifies the search path used to locate DLLs for the application and affects all subsequent calls to the LoadLibrary and LoadLibraryEx functions by the application.

via Paul Wilson.

Windows caches file dates

Development Comments

There's has been an informative discussion in CodeProject's Lounge regarding cached file dates.

Here some quotes from MSDN:

File Times A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 (UTC). The system records file times whenever applications create, access, and write to files. Not all file systems can record creation and last access time and not all file systems record them in the same manner. For example, on NT FAT, create time has a resolution of 10 milliseconds, write time has a resolution of 2 seconds, and access time has a resolution of 1 day (really, the access date). On NTFS, access time has a resolution of 1 hour.

and in the documentation of CreateFile:

Windows NT/2000: If you rename or delete a file, then restore it shortly thereafter, Windows NT searches the cache for file information to restore. Cached information includes its short/long name pair and creation time.

Some more issues with .94

.Text Comments

I've updated my site to .Text .94, but unfortunately I have had some issues, though I followed Scott's instructions. Maybe I did something wrong during the setup, but here are my changes to the aggregated version of web.config to get my site working:

  1. Whenever I tried to go to the admin section of a blog, I got an error. .Text complained about missing templates of the admin pages. Therefore, I added following entries to the appSettings section:

    <add key="Admin.DefaultTemplate" value="~/Admin/Resources/PageTemplate.ascx" />
    <add key="Admin.DownlevelTemplate" value="~/Admin/Resources/PageTemplate.ascx" />
    <add key="Admin.DefaultContent" value="PageContent" />
  2. The authentification was set to Windows. I switched back to Forms authentification:

    <authentication mode="Forms">
      <forms name=".ASPXFORADMIN" loginUrl="login.aspx" protection="All"  timeout="90" />
  3. Steve ~~~~ mentions to change the httpHandlers. Hmm, there is no httpHandlers section in my web.config. I admit I was already wondering when Scott moved all the handling stuff to blog.config. Someone has to tell ASP.NET to use that. Therefore:

      <add verb="*" path="*" type="Dottext.Framework.UrlManager.UrlReWriteHandlerFactory,Dottext.Framework" />

With these modification my .Text installation works like a charm :-)


  1. ASP.NET 1.1 validates the input, so I cannot use HTML in my posts. I've added following line:

    <pages validateRequest="false" />

Ooops, my fault. I was using the out-dated web.config. Note to myself: RTFM.