CreateProcess on a console program - started program doesn't exit cleanly.

[R.Wieser]

Hello all,

I'm starting "list.exe"* contained in the below 2003 SDK

http://download.microsoft.com/download/8/e/c/8ec3a7d8-05b4-440a-a71e-ca3ee25fe057/rktools.exe

using CreateProcessA. Afterwards (ofcourse) close the thread and process
handles (way before the started program exits)

*Which uses "CreateConsoleScreenBuffer" and family

The thing is that when I start the "list.exe" program* this way it does not
exit cleanly.

It is as if the cursor gets updated, but the screens contents do not - not
directly anyway: I can type a console command (like "dir") (no characters
visible but the cursor moves) and see the output. After doing that twice
the screen seems to return to normal though.

I've tried to fill the "StartupInfo" record with data (using
"GetStartupInfoA") before calling "CreateProcesA", but that didn't seem to
make a difference.

Question: Does anyone have an idea why this difference occurs ? What did
I forget to do ?

Remark: The same approach as worked fine for other programs, just not this,
"list.exe" one.

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
using CreateProcessA. Afterwards (ofcourse) close the thread and process
handles (way before the started program exits)
*Which uses "CreateConsoleScreenBuffer" and family
The thing is that when I start the "list.exe" program* this way it does not
exit cleanly.

That shouldn't cause any problem, unless something else is interfering.

Post by R.Wieser
It is as if the cursor gets updated, but the screens contents do not - not

Looks like the color attribute data in the console buffer is not
initialized/restored properly, because by default, when we type something
into a console, only the character data part is overwritten. The color
attribute data part is untouched. Meaning that the text color data part in
the console buffer are not all light grey. Some of them are black.

If you select the invisible typed characters and copy it into the clipboard,
the clipboard should contain the typed characters, instead of just blanks.

Post by R.Wieser
I can type a console command (like "dir") (no characters
visible but the cursor moves) and see the output.

Console command? I thought you ran `list.exe` from your own program, and not
from CMD.EXE.

However, IIRC when I still use XP, COMMAND.COM console sometimes produces
such console screen inconsistency after running Win32 console program that
manipulates console buffer. i.e. when the console has switched to real mode
environment, executes a Win32 console program (thus switched to protected
mode), then switch back to real mode when the program ends. Even if
initially, the console window was created by CMD.EXE.

[R.Wieser]

JJ,

Post by JJ
That shouldn't cause any problem, unless something else is interfering.

Interference that only turns up when the program is started by my (absolute
minimal) program ? Unlikely.

Post by JJ
Looks like the color attribute data in the console buffer is
not initialized/restored properly, because by default, when
we type something into a console, only the character data
part is overwritten.

I just rechecked: even when the cursor restores to a place where there is
still text visible, the cursor moves, but the already-there text doesn't get
overwritten.

Post by JJ

Post by R.Wieser
I can type a console command (like "dir") (no characters
visible but the cursor moves) and see the output.

Console command? I thought you ran `list.exe` from your own program,
and not from CMD.EXE.

Correct. But after that I exit "list.exe" (started by my program or not) I
get back to the commandline.

Post by JJ
However, IIRC when I still use XP, COMMAND.COM console
sometimes produces such console screen inconsistency [snip]

Although thats possible, should it not than result in the same behaviour,
regardless of how that "list.exe" program gets started ? And it works
alright when started directly ...

And pardon my asking, but is there a possibility that a none or incomplete
initialisation of the "StartupInfo" record might be causing it ?

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
And pardon my asking, but is there a possibility that a none or incomplete
initialisation of the "StartupInfo" record might be causing it ?

IME, no.

Such anomaly would either caused by a bug in Windows' own console handling,
the program being run, or outside interference. But I know that it's not a
bug in `list.exe`, because I also use that exact same Resource Kit Tools.
And reproducing the scenario in my Win7, doesn't produce the anomaly.

[R.Wieser]

JJ,

Post by JJ
Such anomaly would either caused by a bug in Windows' own console
handling, the program being run, or outside interference.

Agreed.

Post by JJ
But I know that it's not a bug in `list.exe`, because I also use that
exact
same Resource Kit Tools.
And reproducing the scenario in my Win7, doesn't produce the anomaly.

Disagreed.

It could still be a bug in "list.exe", which only shows itself when
interacting this way with my OS (which, by the way, is XPsp3). Though its
ofcourse also possible that the OS itself is to blame.

Shucks. I've got no idea how to progress ...

Thanks for the testing, appreciate it.

Regards,
Rudy Wieser

P.s.
Heck, I just realized that it /might/ even be on purpose (a special usage of
the program - its designed to be part of a development environment), who
knows.

[R.Wieser]

Post by R.Wieser
Hello all,
I'm starting "list.exe"* contained in the below 2003 SDK
http://download.microsoft.com/download/8/e/c/8ec3a7d8-05b4-440a-a71e-ca3ee25fe057/rktools.exe
using CreateProcessA. Afterwards (ofcourse) close the thread and process
handles (way before the started program exits)

The problem seems to be related to the program executing CreateProcessA
exiting (and dropping back to the commandline) before "list.exe" does: When
I delay the exiting of the first (with either a "sleep" or
"WaitForSingleObject") the problem doesn't appear.

IOW, its probably the combination of the 'list.exe" program creating its own
console screenbuffer, and the OS trying to write to the console screen too.

Regards,
Rudy Wieser

[T]

Post by R.Wieser

Post by R.Wieser
Hello all,
I'm starting "list.exe"* contained in the below 2003 SDK
http://download.microsoft.com/download/8/e/c/8ec3a7d8-05b4-440a-a71e-ca3ee25fe057/rktools.exe
using CreateProcessA. Afterwards (ofcourse) close the thread and process
handles (way before the started program exits)

The problem seems to be related to the program executing CreateProcessA
exiting (and dropping back to the commandline) before "list.exe" does: When
I delay the exiting of the first (with either a "sleep" or
"WaitForSingleObject") the problem doesn't appear.
IOW, its probably the combination of the 'list.exe" program creating its own
console screenbuffer, and the OS trying to write to the console screen too.
Regards,
Rudy Wieser

Hi Rudy,

Windows 10-1909 Pro

raku -v
This is Rakudo version 2020.01 built on MoarVM version
2020.01.1 implementing Perl 6.d.
I am having the problem when running from teh registry:

I am opening Raku from the registry with

[HKEY_CLASSES_ROOT\*\shell\OpenWithFileAttributes.pl6\command]
@="\"C:\\rakudo\\bin\\raku.exe\"
\"K:\\Windows\\NtUtil\\FileAttributes.pl6\" \"%1\""

Problem: up pops a big black box with Raku running it in.
Is there a way to rid myself of the big black box?
(I have pops for the information that is reported to
the user.)

Where would I put the delay? In my program? Before
my program?

-T

[R.Wieser]

T,

Post by T
Problem: up pops a big black box with Raku running it in.

...

Post by T
Where would I put the delay?

You wouldn't. That solution has got nothing to do with your problem, but
with one I had (in relation to CreateProcess). :-)

In your particular case you could try to put "start /min " infront of that
registry line:

"start /min \"C:\\......\""

That should cause the program to run minimized (you only see the program on
the taskbar). Though do take a peek at that program yourself, maybe W10
has got a "run at background" switch (that XP doesn't have): type "start /?"
on the commandline to see its arguments.

Though a question: Are you sure that those doublequotes (\") both before
the C:\\ and at the end of the line are nessesary ? I think it will work
as well without those two.

Regards,
Rudy Wieser

[T]

Post by R.Wieser
Though a question: Are you sure that those doublequotes (\") both before
the C:\\ and at the end of the line are nessesary ? I think it will work
as well without those two.

You get kicked out if you don't. A backslash is an
escape character in the registry. So you have to use two
of them to get one.

Raku does the same thing, but has an "exact quote" syntax
that I use a lot to get around it

$ raku -e 'say "\\";'
\

$ raku -e 'say Q[\];'
\

[R.Wieser]

T,

Post by T
You get kicked out if you don't. A backslash is an
escape character in the registry. So you have to use two of them to get
one.

:-) Thats not what I was taking about. I mean you start that registy value
with "\" , and are ending it with \"". Are those two escaped doublequotes
neccesary there ? Why not just start with " and end with ".

Post by T
You get kicked out if you don't. A backslash is an
escape character in the registry.

Are you sure about that ? I know its an escape character in the
C{something} language (and as such often in derivates thereof), but as far
as I can tell, not in the registry itself - at least not under either W98
and XP.

Regards,
Rudy Wieser

[T]

Post by R.Wieser
T,

Post by T
You get kicked out if you don't. A backslash is an
escape character in the registry. So you have to use two of them to get
one.

:-) Thats not what I was taking about. I mean you start that registy value
with "\" , and are ending it with \"". Are those two escaped doublequotes
neccesary there ? Why not just start with " and end with ".

Post by T
You get kicked out if you don't. A backslash is an
escape character in the registry.

Are you sure about that ? I know its an escape character in the
C{something} language (and as such often in derivates thereof), but as far
as I can tell, not in the registry itself - at least not under either W98
and XP.
Regards,
Rudy Wieser

Sure. I tried it both way.

[T]

Post by R.Wieser
In your particular case you could try to put "start /min " infront of that
"start /min \"C:\\......\""

That I will try as soon as I get my nf-winreg-regcreatekeyexw
module working.

Thank you!

[R.Wieser]

T,

Post by T
That I will try as soon as I get my nf-winreg-regcreatekeyexw
module working.

What about just opening the "registry editor" (regedit.exe) and edit that
entry by hand ? :-)

At least that way you can check if it works.

Regards,
Rudy Wieser

[T]

Post by R.Wieser
T,

Post by T
That I will try as soon as I get my nf-winreg-regcreatekeyexw
module working.

What about just opening the "registry editor" (regedit.exe) and edit that
entry by hand ? :-)

Hi Rudy,

WHERE IS THE FUN IN THAT !!!!!

:-)

The program I am working on will set up the registry for you
if you give it the --SetReg switch. And I have to
get the supporting modules working anyway.

Post by R.Wieser
At least that way you can check if it works.

I exported a similar key just to check. And I
base my new values based on that. And I have
done it manually and saved a copy to make sure
my module matches it.

Post by R.Wieser
Regards,
Rudy Wieser

Thank you!

[T]

Post by R.Wieser
Though a question: Are you sure that those doublequotes (\") both before
the C:\\ and at the end of the line are nessesary ? I think it will work
as well without those two.

Hi Rudy,

You were correct. I had so many other issues to
fix that I though I was seeing something else.

Thank you for the heads up!
-T

It is more fun when you are not the one that is wrong.

:'(

[R.Wieser]

T,

Post by T
Hi Rudy,
You were correct. I had so many other issues to
fix that I though I was seeing something else.

Don't worry about it. The same happens to me (and likely everyone). When
you have too many things that beg your attention you need to make choices to
what to focus on, and what to put on the back burner. If you wouldn't you
would come to a grinding halt, looking up a disabilitating mountain of stuff
to do.

Post by T
It is more fun when you are not the one that is wrong.

You where not wrong. What I mentioned was rather inconsequential - it
worked and was not any kind of an ugly hack. It was just unneeded (and
/could/ have caused some head-scratching in the future).

Regards,
Rudy Wieser

[T]

Post by R.Wieser
In your particular case you could try to put "start /min " infront of that
"start /min \"C:\\......\""

Poop. "Start" is build in shell command. When I
put this in the registry, I got a prompt as to
what program I should open "Start" with.

cmd.exe /q /c ....

still opens a shell.

But I have decided I like the stuff I wrote to the
shell. So, another day I will hunt down teh bit
that runs the shell.

And I opened:

RFE: shell / no shell switch
https://github.com/rakudo/rakudo/issues/3582

So now we wait ...

[R.Wieser]

T,

Post by T
Poop. "Start" is build in shell command.

Poop indeed. I forgot all about that. Sorry. :-\

Post by T
But I have decided I like the stuff I wrote to the
shell. So, another day I will hunt down teh bit
that runs the shell.

Using the console window as a kind of logging/progress output window. Now
where have I seen that been done before ... :-)

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
The problem seems to be related to the program executing CreateProcessA
exiting (and dropping back to the commandline) before "list.exe" does: When
I delay the exiting of the first (with either a "sleep" or
"WaitForSingleObject") the problem doesn't appear.
IOW, its probably the combination of the 'list.exe" program creating its own
console screenbuffer, and the OS trying to write to the console screen too.
Regards,
Rudy Wieser

That's likely related to the child process initialization where at some
part, the system creates new thread(s) in host process to do it. MSDN
recommends that when creating a child process, it should wait for the
process initialization using `WaitForInputIdle()`. So, ending the process
right after creating the child process may interfere the child process'
initialization.

[R.Wieser]

JJ,

So, ending the process right after creating the child process
may interfere the child process' initialization.

I already thought of that, and tested if that might be causing the problem
by putting a number of seconds of "Sleep" after the "CreateProcess" call.
Nothing changed.

But to make absolutily sure I just tried it with "WaitForInputIdle" too.
Alas, the same problem occurred.

Just as with using "Sleep" I saw the cursor jump, in the "list.exe" program,
to the location it should be after exiting. Which (ofcourse) should not
happen.

Not a bad idea to keep it in there though (the program is supposed to be a
bit of template).

Regards,
Rudy Wieser