During one step that is present in all our configuration (svn-clean, which deletes non-versioned files from the workspace), we get the following error on windows systems:

04:38:48,086 [clean-svn@lab18:8811] WARN - C:\qb2\workspace\trunk\all\integrationtests\osgi.integrationtest.test\report\TEST-com.dynatrace.diagnostics.integrationtest.memdump.rootPath.MemoryDumpRootPathTest$ComplexGraphRootPathInProcessCollectorTest.xml - The process cannot access the file because it is being used by another process.

svn-clean is a perl script, that triggers a "del" if svn status indicates a non-versioned file.

After adding some diagnostics functionality to this script to find out which process holds the handle to this files, we discovered that it is the QuickBuild Agent process. (to do this, we run sysinternals handle.exe in the case a file cannot be deleted. This shows the handles and the process id which holds the files open)
Since the svn-clean step is right at the beginning of each configuration, I suppose the files must be left open from a previously running configuration.

In many cases we have several builds that fail right behind each other because of this, and each of these builds show the same handle-ids and process ids of the files that are being held open by another process.
It has also been verified, that there are no 2 builds running in parallel on the same workspace, or other custom processes do so.

In our outer-most master step we configured simple logging to record start and stop times of builds. Using this log it could be shown, that the last build that was running without svn-clean problems finished successfully at 2010-10-04 13:27:10, without any problems or exceptions found in the respective logfile. The next build that was running on that same workspace failed in svn-clean at 2010-10-05 00:48:37.
Until 2010-10-06 00:25:06, all builds that ran against this workspace failed in svn-clean.
The next build, starting at 2010-10-06 00:25:08 was running successfully again, without any user interaction or whatsoever (after all, it was in the dead of night).
There are also no log entries that indicate any action regarding the files in question (or anything else).

Without doing further introspection, i would suppose this is a resource leak during junit-report generation.