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?
>
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,

Bingo !! You nailed it. That seems to have done the trick.

Many Thanks,

Gene

"Matthias Tacke" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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?
> >
> 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 <(E-Mail Removed)> wrote:
> 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?
> >
> 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

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 L. Smith
Columbus, Ohio

Gary Smith wrote:

> 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?
>
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


"Gary Smith" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Matthias Tacke <(E-Mail Removed)> wrote:
> > 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?
> > >
> > 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
>
> 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 L. Smith
> Columbus, Ohio

On Mon, 12 Mar 2007 14:46:40 GMT, "Gene" <(E-Mail Removed)> wrote:

>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.

Do you have on-access AV scanning slowing things down?

>"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.

No. This is occuring on all developer and tester systems (approx 30 XP SP2
machines + 2 2003 Servers.)

"foxidrive" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Mon, 12 Mar 2007 14:46:40 GMT, "Gene" <(E-Mail Removed)> wrote:
>
> >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.
>
> Do you have on-access AV scanning slowing things down?
>
> >"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" <(E-Mail Removed)> wrote in message
news:kJdJh.7320$(E-Mail Removed)...
> 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.

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 Vargo
(Post questions to group only. Remove "z" to email personal messages)

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




"Todd Vargo" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Gene" <(E-Mail Removed)> wrote in message
> news:kJdJh.7320$(E-Mail Removed)...
> > 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.
>
> 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 Vargo
> (Post questions to group only. Remove "z" to email personal messages)
>