1

Occasionally I have this message in the regular screen output of one of my runs via a CMD script:

"The process cannot access the file because it is being used by another process."

I know I can use programs to actively monitor on processes locking files, but this script runs in a background. Also: the locks do exist, but all for a very short time ( < 1 second ).

When I look at the log file that is created by such a run, I can see the error message (as displayed above). I also have the timing, but because of limited output by the script, there is no more info.

So my question is : how do you retroactively find out which file was locked, based on this information ?

It would have been so nice if the error message in question would display the name of the file it finds being locked.

3
  • With built-in Windows tools I fear you can't. But you could try with FileMon...
    – aschipfl
    May 7, 2019 at 15:27
  • I'm afraid as well. It should be in the Event Manager .. Filemon is no longer available for download, MS says the functionality is included in ProcMon. I'll check out the logging functionality of ProcMon.
    – tee
    May 8, 2019 at 8:29
  • Ah, yes, they combined several logging tools into one, seems I forgot about that, sorry...
    – aschipfl
    May 8, 2019 at 8:33

1 Answer 1

-1

I recently had this error happen at the cmd prompt in Windows 10 v1903. The error is displayed in the console for a specific file name which is ZeroBytes.lst. I'm piping text output to this filename on a Ram disk created by ImDisk. Piping this output to any other drive and/or folder(same ramdisk) displays no error. Additionally, the process displays this error immediately but continues to run and completes with errorlevel = 0 when it should set errorlevel GTR 0. In short, the process itself only displays the error but sets no error. It happens when I pipe the output using > R:\WDr\ZeroBytes.lst. Any other filename works without error in R:\WDr and ZeroBytes.lst works without error on any other folder in the R: drive.

I have implemented the work-a-round as follows " >R:\WDr\ZeroBytes.lst 2>&1"

It seemed you were looking for details so hopefully this helps.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .