Pressing CTRL causes running WinBatch processes to exit ...

[mhall]

Hi,

I am running into an intermittent issue where, when I press the CTRL in any application, my running Winbatch/Webbatch processes exit with "194: Execution Terminated by user request."

I've actually had this problem for years (10+) on a number of different machines and operating systems (going back to Windows 2000). I had usually only observed it after I'd exited a Winbatch process using CTRL+Break/CTRL+C and had simply learned to avoid that as, once the problem starts, it has always required a restart of the machine to handle the issue.

But I'm now also developing in the Node.js environment which is command line driven and CTRL+C is the prescribed method for stopping the running instance.

This is resulting in Winbatch/Webbatch processes exiting when processing CTRL in any other application throughout the system.

I thought I had seen a question related to this in the past, but a search both on the boards and the Tech Database didn't return anything.

Currently running 2018A on Windows 7. Happens with scripts running via WinBatch Studio, Compiled Scripts and Webbatch scripts.

Is there something I should be looking at? Is this an issue others run into at all? Simple fix?

Thanks,
Micheal

[td]

WinBatch does not by default terminate because the control key is pressed.  Although it is possible to write a script that does this using the "IsKeyDown" function.   WinBatch does terminate via the control+break combination.  This is the documented method for interrupting a  running script.   This behavior can be modified using IntControl 12.

If WinBatch had a ubiquitous problem with unexpected termination as a result of the control key over the last 10 years, it most certainly would have been brought to our attention by now by multiple users.  But it hasn't. The only thing I can think of that might cause such a problem over many years is some favorite piece of software that travels with you from computer to computer and is somehow generating a cancel virtual key sequence (control+break) when the control key is pressed or place the equivalent virtual key in the keyboard buffer for some reason. Of course, there is always the possibility that there is some other crucial factor you have neglected to mention.

[mhall]

If WinBatch had a ubiquitous problem with unexpected termination as a result of the control key over the last 10 years, it most certainly would have been brought to our attention by now by multiple users.

Which is really why I never brought it up - I figured it had to be something on my end and I've never really been able to consistently narrow down a fully reproducible set of steps needed to demonstrate the problem. And I'd also trained myself to avoid using Ctrl+Break.

Last night, after I posted the problem, I went ahead and did a re-start and noticed one thing that I had failed to mention. Each time I restart because of the issue, Windows informs me of a "Task Host Window" (I think that was it) that is not responding and I have to force close it before Windows will shut down/restart.

As to a favorite piece of software or environment I bring along with me from machine to machine ... well, there's Photoshop, but I've certainly updated it in the past 10 years and it's not always running. And there's an explorer replacement called DirectoryOpus which does run all the time and listens for keystrokes ... next time the issue comes up I'll see if restarting that makes any difference.

Thanks for the tip on IntControl(12).

Regards,
Micheal

[snowsnowsnow]

With all due respect, td, this *is* a long-standing problem with WinBatch.  Note that I didn't say "a WinBatch problem" - I said "a problem with WinBatch".  I.e., in the final analysis, if this boils down to finger-pointing, I don't want to get involved in that.

But this is a real problem, going back to at least the early 2000s, which is, I think, before your time as the main support guy (at least as seen on this forum/support board).

That said, if you go back into the archives, you will see that this problem has come up in the past - and it has certainly affected me personally.  It isn't affecting me personally at the moment (i.e., on my current hardware/software rig), but it has in the past (occurring just as the OP described).  The solution is to add the appropriate IC(12) call to basically every program.  Yes, this means you can't kill your program via the Ctrl/Break trick anymore - but that's really a small price to pay.  Think of this as a bit of "defensive programming".

Finally, and back to the subject of "finger pointing", when this has come up in the past, the response from the board support people has been to blame it on a "keyboard driver problem".  Again, with all due respect, this always sounded like a cop-out to me.  That is, a way to "triangulate" - that is, avoid it being either a Windows problem or a WinBatch problem - sort of a "blame the other" type solution.

But, again, to summarize, just add the appropriate IC(12) call to your program, and the problem will go away.

[ChuckC]

Base on personal experience running 1000's of scripts on many different types of computers since 1994, using 16-bit, 32-bit & 64-bit versions of WinBatch, with some scripts run interpreted and many run compiled, being run on Windows 3.1, Win95, Win95 OSR2, Win98, WinME, Windows NT 3.51/4.0/2000/XP/2003/Vista/7/8/10, never once have I had a problem with a script erroneously terminating due to just hitting the CTRL key regardless of whether the script had a window open with foreground focus or was running in the background.

I would highly suspect that there is some sort of application running that is remapping keys or is otherwise performing "accelerator key" functions.  With the ubiquitous nature of USB-based keyboards and the associated driver & support software that comes with them, as well as the sometimes complex issue of heavily overloaded function assignments for various keys being accessed via one or more "function key" levels being enabled or selected, I wouldn't be at all surprised if these occurrences of the problem being observed were being caused by such 3rd party keyboard hardware & software being present.

[td]

With all due respect, td, this *is* a long-standing problem with WinBatch.  Note that I didn't say "a WinBatch problem" - I said "a problem with WinBatch".  I.e., in the final analysis, if this boils down to finger-pointing, I don't want to get involved in that.

But this is a real problem, going back to at least the early 2000s, which is, I think, before your time as the main support guy (at least as seen on this forum/support board).

That said, if you go back into the archives, you will see that this problem has come up in the past - and it has certainly affected me personally.  It isn't affecting me personally at the moment (i.e., on my current hardware/software rig), but it has in the past (occurring just as the OP described).  The solution is to add the appropriate IC(12) call to basically every program.  Yes, this means you can't kill your program via the Ctrl/Break trick anymore - but that's really a small price to pay.  Think of this as a bit of "defensive programming".

Finally, and back to the subject of "finger pointing", when this has come up in the past, the response from the board support people has been to blame it on a "keyboard driver problem".  Again, with all due respect, this always sounded like a cop-out to me.  That is, a way to "triangulate" - that is, avoid it being either a Windows problem or a WinBatch problem - sort of a "blame the other" type solution.

But, again, to summarize, just add the appropriate IC(12) call to your program, and the problem will go away.

Cynicism aside there is no interest in "finger pointing".  It is not in the best interest of ILC LLC or WinBatch users to do so.  However, how WinBatch detects the control+break key state is extremely simple and requires all of two lines of code. It is done in the manor recommend by MSFT documentation.  It is very simple - if the OS reports that the VT_CANCEL (control+Break) virtual key is in the down state, WinBatch begins termination processing.  How that key state is produced is another question and something WinBatch has no control over.

In the past, keyboard drivers have been an issue.  This has been verified because updated drivers have fixed reported issues.  But in the last 10 years or so Microsoft has improved the quality and diversity of drivers shipped with their OS so it has become a much less frequent problem.   This is not to say that it doesn't happen but buggy antimalware software has replaced drivers as the biggest cause of problems for WinBatch.  Fortunately, buggy antimalware usually causes a crash which usually makes it easy to "point the finger" in the right direction, given a cooperative user.

Now that you mention it, I do remember your problem with control+break.  But the point was that over the last 10 year we haven't had a pattern of reports of this being an issue and not that it has never been reported as an issue over the last 25 years.   

[td]

If WinBatch had a ubiquitous problem with unexpected termination as a result of the control key over the last 10 years, it most certainly would have been brought to our attention by now by multiple users.

Which is really why I never brought it up - I figured it had to be something on my end and I've never really been able to consistently narrow down a fully reproducible set of steps needed to demonstrate the problem. And I'd also trained myself to avoid using Ctrl+Break.

Last night, after I posted the problem, I went ahead and did a re-start and noticed one thing that I had failed to mention. Each time I restart because of the issue, Windows informs me of a "Task Host Window" (I think that was it) that is not responding and I have to force close it before Windows will shut down/restart.

As to a favorite piece of software or environment I bring along with me from machine to machine ... well, there's Photoshop, but I've certainly updated it in the past 10 years and it's not always running. And there's an explorer replacement called DirectoryOpus which does run all the time and listens for keystrokes ... next time the issue comes up I'll see if restarting that makes any difference.

Thanks for the tip on IntControl(12).

I guess this will have to remain a mystery for now.  Not saying that is the source of your problem but given that an Explorer replacement would likely be involved in shortcuts processing and other keyboard activities it is a possible candidate.

If you do discover anything more, please let us know.

[chrislegarth]

Just to add my 2¢, I have been using WinBatch since 1994 also at two different jobs and, like ChuckC, have not run into this issue even once that I can remember.

[kdmoyers]

Just another data point: I've been doing winbatch since the earliest days, and I've never seen a problem with CTRL causing aborts.

I do see crazy key stuff sometimes, but it always boils down to various other software I'm running.

The problem with the windows platform is, everybody's set up is so *different*.  Of course, that's also the best part too :-)

$0.02  -Kirby

[snowsnowsnow]

What happened to my post?

[td]

It was deleted by mouse button clicking on one link when intending to click on another.  You could re-post if it would make you feel better...

[snowsnowsnow]

The occupational hazards of being a moderator, eh?

[td]

Yup and it is not the first time it's happened either.  Itchy trigger finger when mouse buttons are involved I guess.