cmd.exe slows RegSvr32

  • Thread starter Thread starter Gene
  • Start date Start date
G

Gene

Hello,

The easiest way to explain the problem is to show examples...

The task is to silently register several COM dll's using RegSvr32.

This first example is ok. Performance through the console window is as
expected.
for %i in (COM1.dll COM2.dll COM3.dll) do RegSvr32 /s %i

Performance is good here too. The file contains the names of 77 dll's. The
whole lot is registered in two to three seconds. Very acceptible.
for /f %i in (RegisterList.txt) do RegSvr32 /s %i

However, if either of the two examples above are executed from a .cmd file,
performance is poor. (8 to 20 seconds per dll.) (Yes %i is changed to %%i
in the .cmd file.)

I also noticed that simply invoking a new processor can cause the slow
behavior at the console window...I would expect this to be slower, but in
the millisecond range, not tens of seconds or more...
for /f %i in (RegisterList.txt) do cmd /c RegSvr32 /s %i

What could cause the command processor to slow RegSvr32 (and GACUtil.exe)
down to such a crawl? Could it be from a Windows 'Critical Update'? I have
one machine that was not recently updated and it does not exhibit this
behavior. How can we restore normal performance?

Gene
 
Gene wrote:
snip
I also noticed that simply invoking a new processor can cause the slow
behavior at the console window...I would expect this to be slower, but in
the millisecond range, not tens of seconds or more...
for /f %i in (RegisterList.txt) do cmd /c RegSvr32 /s %i

What could cause the command processor to slow RegSvr32 (and GACUtil.exe)
down to such a crawl? Could it be from a Windows 'Critical Update'? I have
one machine that was not recently updated and it does not exhibit this
behavior. How can we restore normal performance?
Click to expand...
Hello Gene,

I've had similar behavior when my search path had several entries on
a netware server with poor performance.

Try with a fully qualified path for RegSvr32.exe and cmd.exe

@echo off
set Regs=%systemroot%\system32\RegSvr32.exe
for /f "delims=" %%A in (RegisterList.txt) do "%comspec%" /c %Regs% /S %%A

HTH
Matthias
 
Matthias Tacke said:
Gene wrote:
snip
Hello Gene,
Click to expand...
I've had similar behavior when my search path had several entries on
a netware server with poor performance.
Click to expand...
Try with a fully qualified path for RegSvr32.exe and cmd.exe
Click to expand...
@echo off
set Regs=%systemroot%\system32\RegSvr32.exe
for /f "delims=" %%A in (RegisterList.txt) do "%comspec%" /c %Regs% /S %%A
Click to expand...

Why would you do
for /f "delims=" %%A in (RegisterList.txt) do "%comspec%" /c %Regs% /S %%A
instead of
for /f "delims=" %%A in (RegisterList.txt) do %Regs% /S %%A

Is it necessary to start a new command processor for each invocation of
RegSvr32?
 
Gary said:
Why would you do
for /f "delims=" %%A in (RegisterList.txt) do "%comspec%" /c %Regs% /S %%A
instead of
for /f "delims=" %%A in (RegisterList.txt) do %Regs% /S %%A

Is it necessary to start a new command processor for each invocation of
RegSvr32?
Click to expand...
No, I just took the last approach from OP to point out where the problem was.

Greetings
Matthias
 
Invoking a second command processor is not required. However, in this case,
it caused the slow behavior in a situation where it wasn't before.

Matthias' solution fixed the problem in the command window. Unfortunately
for me, these were all examples. The problem persists in production. Even
when I give full paths to everything in a command file.

"C:\WINDOWS\system32\RegSvr32.exe" /S "C:\Program Files\Common
Files\Software\Shared Components\DLL1.dll"
"C:\WINDOWS\system32\RegSvr32.exe" /S "C:\Program Files\Common
Files\Software\Shared Components\DLL2.dll"

So, I am back to where I started. Typing via a command window works, but
doing the same thing via a command file is slow.

Gene
 
Invoking a second command processor is not required. However, in this case,
it caused the slow behavior in a situation where it wasn't before.

Matthias' solution fixed the problem in the command window. Unfortunately
for me, these were all examples. The problem persists in production. Even
when I give full paths to everything in a command file.
Click to expand...

Do you have on-access AV scanning slowing things down?
 
No. This is occuring on all developer and tester systems (approx 30 XP SP2
machines + 2 2003 Servers.)
 
Gene said:
Invoking a second command processor is not required. However, in this case,
it caused the slow behavior in a situation where it wasn't before.

Matthias' solution fixed the problem in the command window. Unfortunately
for me, these were all examples. The problem persists in production. Even
when I give full paths to everything in a command file.

"C:\WINDOWS\system32\RegSvr32.exe" /S "C:\Program Files\Common
Files\Software\Shared Components\DLL1.dll"
"C:\WINDOWS\system32\RegSvr32.exe" /S "C:\Program Files\Common
Files\Software\Shared Components\DLL2.dll"

So, I am back to where I started. Typing via a command window works, but
doing the same thing via a command file is slow.
Click to expand...

When you say command window, are you using CMD or COMMAND? Likewise, when
you say "command file", are you using .cmd or .bat extension?

ISTM, RegSvr32.exe is a GUI utility which may be opening a separate process
depending one which command processor is used. Are you sure RegSvr32.exe is
completing it's task before returning the command prompt? You might try
typing the RegSvr32.exe command and watch task manager to verify it's not
actually still running in the background after the prompt has already
returned. This may explain why the command line appears to be faster than a
batch file. Just a guess.
 
Todd,

I am using cmd windows and .cmd files for these tests.

I can tell that RegSvr32 is launching itself as a separate process because
in one test scenerio, the prompt returns quickly, while the success dialog
appears 10 to 20 seconds later. Ufortunately, I can not use that in
production. We really want the user to be able to see the name of each
object being registered and the registration tasks overall progress. We
just don't want registration of 77 objects to take 8 to 9 minutes in spurts
of some fast and some slow.

What are the mechanics of RegSvr32? Does it do more than make registry
entries? We have never encountered such poor performance from it before.
Is it VS2005? DotNet 2.0? Is it because our COM dll's are much 'richer' now
with dependencies that must be tracked down as part of registration? I have
tried tinkering with the PATH and putting our folders first in the chain.
No joy there either.

Thanks,

Gene
 
Back
Top