Slow console app startup after Windows 10 Pro update

After updating to Windows 10 (64 bit) Pro 1809 Build 17763.316, we are experiencing an initial slowdown in the appearance of our console apps' first screens but no problems with GUI based apps.

Once the initial screens of the console apps appear, everything seems normal.

We are using Winflector 3.9.6.7 and the machine has 8 GB RAM

an example of a console app is a legacy xbase Clipper app (compiled into 32 bit executable using the Harbour compiler so that they can run in Windows 10 since Windows 10 no longer supports 16 bit apps) and an example of a GUI app is a legacy FoxPro app and a WPF-based homegrown file explorer (WPF = Windows Presentation Framework).

the slowdown in the first appearance of a console app screen is about 3 minutes. after that, everything seems to work fine.

this slowdown is part of our experience updating to Winflector 3.9.6.7 also. Reverting to an earlier version of Winflector resulted in same slow down so we thought the Windows 10 Pro update may also have a role to play in the slow down?

we have since done a clean install of Winflector 3.9.6.7.

please advise if there's anything we could do to further troubleshoot or improve the situation.

thanks for helping

**** FIRST  EDIT   *****

you could try this to see the problem:

add CMD.exe as an application remotely accessible thru winflector.

after  login to that winflector server machine, try to access the CMD app.

the screen will come up fairly quickly, but the prompt (c:\users\blah>  ) will take 3 minutes to show up.  since our Clipper console app is sort of like a cmd.exe app, we cant do anything until we can interact with the first screen.

we didn't have this problem previously.  also, if we double click on CMD.exe while sitting locally in front of the machine itself, the prompt comes up immediately and we can interact with the console / terminal right away.

**** END FIRST EDIT ******

thanks for the suggestion, but we still have the same problem.

here's some new info:

*** BEFORE WE GLOBALLY CONFIGURE cmd.exe to Use Legacy Console:

When we start up our Clipper console app, we first get a blank frame. After 3 minutes, the frame resizes to the size settings for our Clipper app (smaller than the initial blank frame's size) and then our app's login screen comes up.  After that, the subsequent app screens come up immediately as expected.

When we start up a plain cmd.exe, the command prompt (c:\users\blah) does not display until after 3 minutes.

Again, when we do these startups locally when in the server machine itself, no problem.

Even though we have not globally configured cmd.exe to Use Legacy Console, once our Clipper app's first screen has displayed, Use Legacy Console has actually been set, but a plain cmd.exe does not have this setting set.

*** AFTER WE'VE GLOBALLY CONFIGURED cmd.exe to Use Legacy Console:

NO change in behaviors whatsoever. Same problems.

So I guess the logical question is: What's happening behind the scenes during the 3 minute wait that might be causing our problem when accessing our apps thru winflector (but not when starting those apps locally)?  We would be interested in knowing this. (remember: the problem occurs only with console apps, not the gui-based apps)

Thank you again for any assistance you could give.

EDIT:

there have been some Windows 10 1809 Release-related problems reported in https://github.com/Microsoft/console/issues.  I wonder if any of those issues provide a clue?

Thank you for the reply.

With both client and server-side consoles globally set to legacy mode (both machines are Windows 10 (64 bit) Pro 1809 Build 17763.316) , we're still experiencing the same problem.

We're also experiencing the same problems on a Windows 8 client (we don't see a Use Legacy  Mode property that can be set globally, so we're assuming the new vs legacy modes apply only to Windows 10 consoles).

Do you experience the problem we reported just with attempting to bring up a console and having to wait 3 minutes just to see the command prompt (c:\users\blah) ?

Thank you for the new info.

Is it worth trying out the Winflector Console product itself? If so, is there a free-for-two-users download we can try out?

I was assuming that the Winflector server/client package we're using already incorporates the functionalities of the Winflector Console product.