views:

226

answers:

4

I have a VB6 program running on Windows 7. It is copying a large number of files and sometimes FileCopy fails with an access violation (between every 60 and 500 files).

I cannot reproduce it using a single file, only during such mass-copying operations this problem happens.

It makes no difference, if source/target are on hard disks, network shares or CD-ROMs.

What could trigger this problem?

EDIT: My question might be a little bit convoluted, so here's some more data:

Run 1:

  1. Start copying 5.000 files
  2. Access violation on file #983
  3. Access violation on file #1437
  4. Access violation on file #1499
  5. Access violation on file #2132
  6. Access violation on file #3456
  7. Access violation on file #4320
  8. Done

Run 2:

  1. Start copying 5.000 files
  2. Access violation on file #60
  3. Access violation on file #3745
  4. Done

Observations

  • The affected files are always different
  • The number of affected files tends to decrease if the same file batch is copied multiple times in succession.
  • Running as Administrator makes no difference
  • The application has read/write access to all necessary file system objects
  • This problem happens on Windows 7 workstations only!
+3  A: 

Not enough information (as you probably know). Do you log the activity? If not, it's a good place to start. Knowing whether certain files are the problem, and if the issue is repeatable, can help narrow it down.

In your case I would also trap (and log) all errors and retry N times after waiting N seconds. You could be trying to copy in-use files locked by another process, and a retry may allow time for that lock to go away.

Really, more data is the key, and logging is the way to get it.

Jim Mack
Logging was the first thing I did, before asking this question. That's why I know that it doesn't come from a specific file and that it's only repeatable if run in batch. (Clarified my question, though)
DR
+1  A: 

Is there a a hidden/system file in the directory that is potentially blocking it?

Does running the VB6 App with right-click "Run As Administrator" make a difference?

Is the point where it dies at the max # of files in the directory? e.g. Are you sure the upper limit on whatever loop structure you are using in VB6 is correct (Count vs count -1)?

jasonk
I checked all those, but I found nothing. Updated my question, too.
DR
+2  A: 

Is there any chance your antivirus program or some indexer is getting in the way?

Try creating a procmon trace while reproducing the error and see what is actually failing. With the trace you can see if there is another program causing the issue or if your app is trying to write somewhere it should't (incorrect permissions) or can't (a temp/scratch directory without enough space).

Check out the presentations linked to on the procmon page or Mark Russinovich's blog for some cool examples of using this tool to solve various Windows/application mysteries.

nick
+3  A: 

Best guess: Is it possible that another user/application is using the specified file at the time the process is running? (anti-virus scanner, Win7 search indexing tool, windows defender, etc) You might try booting the machine in safe-mood to eliminate any of the background services/apps and try running the process to see.

Is there any consistency in the file types or size of the files causing the issue?

Is the machine low on resources? RAM/Disk Space

You said it occurs on Win7 – is it multiple Win7 machines or just one. (help to rule out system resources vs. software/OS)

Any hints from the event viewer (control panel > admin tools) – doubtful

Does the process take a long time to complete? If you can take the performance hit you might look at destroying and recreating the FSO object after every copy or every X files to make sure there isn’t some odd memory leak issue with Win7/VB6.

Not necessarily a recommended solution but if all else fails you could handle that error and save the files that trigger it in a dictionary/collection and reloop through the process with any those files when done. No guarantee it wouldn’t happen again.

jasonk
It seems that disabling the antivirus solved that problem. Also I added a retry feature in case this happens on one of our customers' workstations.
DR