Tech Support > Microsoft Windows > Development Resources > User can run app from command line. CreateProcess() Fails
User can run app from command line. CreateProcess() Fails
Posted by Larry Lindstrom on April 9th, 2008


Hi Folks:

Developing on Win XP Media, C++ VS 2008, WIN32, no MFC.

My application checks to see if the Firebird DBMS has
been installed, and if not, it calls CreateProcess() to run
the Firebird install executable.

So far so good.

Firebird installs itself in \Program Files\Firebird\Firebird_2_0,
and puts some utilities in its bin directory.

When this is finished CreateProcess() is called again to run
Firebird's gsec utility, which manipulates the DBMS's security
tables. The command line that follows modifies the DB admin's
default password with one the user enters.

Gsec.exe can be run interactively, or can take it's commands
from the command line, which is how it's being run here.

The CreateProcess is followed by a call to WaitForSingleObject()
waiting for gsec's process handle.

This runs fine on my PC, the XP media machine with VS 2008. It
fails with a timeout on my partner's laptop, which also runs XP.

When CreateProcess() times out, testing shows that the DB admin's
password was not updated.

Here are some clues that I haven't been able to decipher.

This ran fine when I was building my app with VC6, but has never
worked after I started using VS 2008. I don't build any of the
Firebird utilities, they are just unpacked to Firebird's bin
directory. So why would they stop working? As stated, my code
starts gsec with CreateProcess().

From the command line, gsec runs if Microsoft.VC90.CRT.manifest,
is present, or not.

My partner's XP pops up something about my programs coming from
a different machine, and asking if he wishes to unblock them. I
don't know if this is the problem, but how can I handle this
message if a process started by CreateProcess() triggers it?

Is there a way to tell XP not to ask this question? Is it
even coming from XP?

I'm running VS 2008, he has run vcredist_x86.exe. He only
needs to run that once, right?

Thanks
Larry

Posted by Sebastian G. on April 9th, 2008


Larry Lindstrom wrote:



Quick standard guess: Did you call CloseHandle() on pi.hProcess and
pi.hThread afterwards? Without closing all handles, a process can't be
properly teared down, which might be blocking further progress.