We've been having a series of issues at customer sites that appear to be due to the Windows Kernel deferring the cleanup of open files causing subsequent file contention problems. This is in most if not all versions of Windows, from XP thru WS2008R2. The scenario is something like this (example in a batch file) :processloop program.exe >out.txt 2>out2.txt goto :processloop Normally this works fine, but when the system is heavily loaded, we get intermittent permissions errors on the output files. And since we're seeing this is in a data warehouse load situation where we're parallelizing these processes, the system is often under heavy load. One solution I've deployed as a fix is to serialize the filenames of the temp output files, so that there will be no collision, and when that is done, we may see a few files get left around afterwards because our cleanup deletes failed, but otherwise the job gets done. One system this just occured on is a customer site with the following OS: Windows Server 2008 Standard 64 bit SP 2 on hardware with 8 cores, running 8 threads in our processing. The Performance option is set to "background processing." The problem happens occasionally at customer sites, where we've often just lowered the threading count as an interim fix. I don't know if changing the Performance setting to "Programs" instead would help, as so far I haven't had the chance to try it, and we don't always have the luxury of fooling around on the customer systems-- plus our program is a nightly ETL load for a warehouse, so it often runs for several hours, and may encounter the contention problem only a few times in that period. At the moment, it's not trivial to reproduce and toy around with. I would like to see if it is possible to verify that my assessment of what is going on is correct, that when a program exits, Windows may defer the closing of files that were open (sometimes we've seen this with files opened internally by the program as well, rather than via redirect on a console command line), such that the next time the temp file access is attempted, it's still busy. I've concluded that since the only reason the file would still be busy is that the close has not yet occured, which is the job of the Kernel, since it occurs even when we're not using redirection but file open within the executable. I also don't know if doing an explicit close of the file is always being done by such executables, since most of them are third party-- such as BCP.exe from SQL Server, or similar programs from other database vendors. Second, I'd like to know if there's anything specific that can be done about it, such as any way to configure windows to insure these things get cleaned up before it allows the opening process to continue on where it may encounter such contention when it tries to re-open the file in the next pass. Adding delays seems like a poor solution, we've tried these and sometimes they help, but sometimes they just reduce the frequency, plus we're trying to get these programs to run as fast as possible in order to get the overall job done, so inserting arbitrary delays is not a popular solution for that reason as well... I also don't quite know where to better ask this question, any help on any of these issues would be appreciated. Thanks, -- Keith Doyle kdd21

Might ask them over here. http://social.msdn.microsoft.com/Forums/en-US/category/windowsdesktopdev Regards, Dave Patrick .... Microsoft Certified Professional Microsoft MVP [Windows] Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.