Multiple XCOPY iterations in CMD window - Memory Leak?

[Guest]

I need to copy large imagery databases (~200 GB) consisting of millions of
imagery tiles disbursed through several sub-folders.
Windows XP via “copy and paste†or “copy to folder†seldom completes the
process, slowing down after a number of hours.
I recognize that the CMD window is not really DOS, but a DOS emulator
running in Win XP.
COPY and XCOPY in a CMD window also slow down after awhile and stop with
either an insufficient resources or extended error 999. I have written a
batch file that breaks the copy task into parts and starts separate CMD
windows (sequentially, not multiple at once) using the start /separate
command in an effort to open a fresh memory space for pieces of the overall
task. That did not work either.
Monitoring page and non-paged pool size in perfmon I see that both these
values increase and then level off, then a couple of hours later I receive
the above mentioned errors.
My research indicates that there may be memory leaks in the COPY and XCOPY
commands in the Win XP CMD window.
It there a way to refresh or empty the various memory pools so that the COPY
and XCOPY commands can continue? Or if I put a delay in the process every
now and then will COPY and XCOPY get a chance to catch up?
XXCOPY or ROBOCOPY are not options, as I need to establish this procedure on
field user computers that will not have these programs, and may not even have
system admin privileges, so it will be difficult for them to install new
software or make changes to the registry.
Thanks.
Bob

 

[Pegasus]

I need to copy large imagery databases (~200 GB) consisting of millions of
imagery tiles disbursed through several sub-folders.
Windows XP via "copy and paste" or "copy to folder" seldom completes the
process, slowing down after a number of hours.
I recognize that the CMD window is not really DOS, but a DOS emulator
running in Win XP.
COPY and XCOPY in a CMD window also slow down after awhile and stop with
either an insufficient resources or extended error 999. I have written a
batch file that breaks the copy task into parts and starts separate CMD
windows (sequentially, not multiple at once) using the start /separate
command in an effort to open a fresh memory space for pieces of the
overall
task. That did not work either.
Monitoring page and non-paged pool size in perfmon I see that both these
values increase and then level off, then a couple of hours later I receive
the above mentioned errors.
My research indicates that there may be memory leaks in the COPY and XCOPY
commands in the Win XP CMD window.
It there a way to refresh or empty the various memory pools so that the
COPY
and XCOPY commands can continue? Or if I put a delay in the process every
now and then will COPY and XCOPY get a chance to catch up?
XXCOPY or ROBOCOPY are not options, as I need to establish this procedure
on
field user computers that will not have these programs, and may not even
have
system admin privileges, so it will be difficult for them to install new
software or make changes to the registry.
Thanks.
Bob

As you observe, there is no "DOS" under WinXP. It's usually
referred to as the Command Prompt.

xcopy.exe does appear to have a problem when copying large
amounts of data. As you already know, xxcopy and robocopy
do not appear to suffer from these problems. Neither of these
needs installing - just copy them to the Windows or to the
System32 directory. To make it happen you could place the
two commands into the folder \\YourServer\Netlogon\Tools
and insert this line into your startup script:
xcopy /d \\YourServer\Netlogon\Tools %SystemRoot% > nul

 

[Guest]

Thank you for your response.
Does anyone know how to regain Page Table Entries without rebooting.
I am having similar difficulities with both XXCOPY and ROBOCOPY.
I emailed the XXCOPY folks and they indicated that they do add registry
entries (they gave me a removal command because my Pro version thought it was
expired even though I had just installed it; it was referenceing the previous
XXCOPY version in the registry.)
Whereas robocopy is truly an independent executable.
All of the copy procedures (copy, xcopy, xxcopy and robocopy) apparently use
the same main XP api to perform the basic copy procedure, CopyFileEx(), and
that is where the actual problem (I guess) lies.
Robocopy does seem to manage the memory a little better, but the real bugger
seems to be that all procedures use up the Page Table Entries and not release
them.
During the copy procedure (tested robocopy multiple times today with PerfMon
up tracking PTEs) the PTEs decrease to about 500, then all processes stop.
Does anyone know how to get the PTEs back short of a reboot?
Thanks,