App startup time is slow using CreateProcess

[Keith Rogers]

I see very different performance of a Windows application if launched from a
command prompt window vs. started by a console app via CreateProcess. The
latter is very show to display the UI, even though the process appears in
Task Manager "instantly" in both cases. The application window displays
immediately when launched from the command line, but literally can take
seconds via CreateProcess. Any suggestions?

Seeing this on both 32-bit and 64-bit Win7.

[Pavel A.]

"Keith Rogers" <Keith...@discussions.microsoft.com> wrote in message
news:6C47F47E-6C5F-4E99...@microsoft.com...

There is no other way for a command prompt to run the app
than to call CreateProcess.
So the difference is somewhere in the parameters of CreateProcess
or in properties passed to child process implicitly
( environment, inherited handles, etc).

--pa

[boris]

"Keith Rogers" <Keith...@discussions.microsoft.com> wrote in message
news:6C47F47E-6C5F-4E99...@microsoft.com...

Did you try using a profiler?

Boris

[Keith Rogers]

Hmm. No. I guess that's the right next step. I assume you mean on the
launched process? (I confess I'm in new territory here.)

[Volodymyr Shcherbyna]

You can measure time of execution of different pieces of code by using
GetTickCount function.Basically, shell us using CreateProcess to launch it,
so your problem comes from different conditions in environment.

--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

"Keith Rogers" <Keith...@discussions.microsoft.com> a écrit dans le
message de news:39F1089C-A871-4496...@microsoft.com...

[Keith Rogers]

I know how to time code, but the problem is the launched app is not developed
by me, so I don't have access to that source to do any kind of
instrumentation.

Much as I hate playing "whack-a-mole" with these kinds of things, are there
any obvious changes that I should try in the launching process' environment
that might impact the environment in a way that the "launchee" would run
faster?

Thanks for everyone's help.

[Pavel Lebedinsky [MSFT]]

If you can attach a debugger to the child process while it is in this state,
you can check its thread stacks to see what they is doing/waiting for.

If this happens too fast for you to attach debugger manually, you can
use IFEO\Debugger registry key to attach automatically, or start the
parent process under debugger (windbg or cdb) and tell it to
automatically debug child proceses:

c:\debuggers> cdb -gG -o parent.exe

When the child process appears in task manager, press Ctrl+C to
break in, then execute these commands:

|1s; .symfix; .reload; ~*k

(this will switch to the second (child) process, fix symbol path, reload
symbols and finally dump all thread stacks)

--
Pavel Lebedinsky/Windows Kernel Test
This posting is provided "AS IS" with no warranties, and confers no rights.

[Francois PIETTE]

> > I see very different performance of a Windows application if launched
from
> > a command prompt window vs. started by a console app via CreateProcess.
> > The latter is very show to display the UI, even though the process
appears
> > in Task Manager "instantly" in both cases. The application window
displays
> > immediately when launched from the command line, but literally can take
> > seconds via CreateProcess. Any suggestions?
> >
> > Seeing this on both 32-bit and 64-bit Win7.
>
> There is no other way for a command prompt to run the app
> than to call CreateProcess.
> So the difference is somewhere in the parameters of CreateProcess
> or in properties passed to child process implicitly
> ( environment, inherited handles, etc).

There is another possibility: the application calling CreateProcess may use
all available CPU just after starting the child application, so the startup
phase of the child application run slowly.

For example, the application calling CreateProcess could use bad code
(Simple loop polling something instead of using one of the WaitForXXX
functions) to wait for child application to terminate, using a lot of CPU,
slowing down the child application.

This could be verifyed using TaskManager or ProcessExplorer. Both display
the resources used by the processes.

--
francoi...@overbyte.be
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be

[Volodymyr Shcherbyna]

"Keith Rogers" <Keith...@discussions.microsoft.com> wrote in message

news:3D7A3913-124A-48F6...@microsoft.com...

>I know how to time code, but the problem is the launched app is not
>developed
> by me, so I don't have access to that source to do any kind of
> instrumentation.
>
> Much as I hate playing "whack-a-mole" with these kinds of things, are
> there
> any obvious changes that I should try in the launching process'
> environment
> that might impact the environment in a way that the "launchee" would run
> faster?

Probably the only solution is to use profilers to figure out the problem,
but they are useful if you have symbols and sources, the second solution is
to decompile entry point of application and see why it is faster if you run
it via shell. I can suggest Ida Free edition for decompilation and OllyDbg
for debugging.

[Charitha Herath]

I got the same problem you are having. If you were able to figure out a
solution could you please post it here.

url:http://www.ureader.com/msg/14743837.aspx