WinBatch does not end its process after finishing script (only versions 2015B-)

Started by bru, November 25, 2016, 01:58:47 AM

Previous topic - Next topic

bru

I experience a more than strange behaviour with one particular WinBatch script (out of dozens of similar scripts performing correctly):
This script executes correctly to the end, then the WinBatch icon in the task bar disappears but the WinBatch process still keeps running.
It seems as if WinBatch is hanging somewhere in the middle of closing itself ...
I can kill the process in the task manager without any problem, but this script is called from another script via RunWait, and the calling script keeps waiting forever ...
(but this bug also occurs if I start the script from Windows Explorer).

This bug occurs only for one particular script (reproduced on 2 different computers), all other (rather similar) scripts are being closed correctly.
I could not find any special characters in the script, the script is stored in ANSI encoding (like all other scripts).
Even the EXIT command at the end of the script does not end its process.

And - to make it even more mysterious - this script is being closed correctly with WinBatch 2013C!
After updating to WinBatch 2015B or WinBatch 2016B the process keeps hanging ...
Operating system: Windows 7

Any hints on this ugly problem wil be very much appreciated!
Thanks,
Juergen

td

In many instances, when a WinBatch users states that a script works with an older version of WinBatch but does not work with a newer version of WinBatch, the problem is not the version of WinBatch.  It is usually some other less obvious difference in the execution environment that is causing the problem.   It is also the case that nothing has changed internally in the WinBatch shutdown process between the 2013C and 2016B version of WinBatch and no other users have reported any issues with a WinBatch process hanging because of some 'ugly problem' in resent versions of WinBatch.

That said.  There are reasons why a WinBatch process might fail to exit.  One potential cause has to do with not properly terminating an external process used by the script like an out of process COM Automation server.  However, without knowing more about your script not much additional advice can be given.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

bru

Thanks for your answer.

We luckily could find out the source of the problem - and it seems to be a WinBatch-incompatibility to older versions.

Try to execute this simple script with WinBatch 2013C and WinBatch 2016B:

str10 = "123456789_"
str = ""
FOR i = 1 TO 28
   str = str : str10
   BoxTitle(i : " " : str)
ENDFOR
Pause (i, StrLen(str))


With WinBatch 2016B the WinBatch process will NOT terminate at the end (WinBatch process still exists within task manager), while with WinBatch 2013C it will.

Reduce the FOR i-counter from 28 to 27: It will also terminate with WinBatch 2016B.

The newer versions seem to have a length limit for the BoxTitle, which will cause the process to hang up.
The older versions seem to tolerate this...

Our workaround now is to wrap a StrSub inside our BoxTitle calls (no one needs that long titles),
but I would wish that a future WinBatch version will do this StrSub automatically within the BoxTitle command.

td

The problem isn't some kind of new limit in the WinBatch BoxTitle function nor the box window itself.  The problem involves a bug that has been around for at least the last 16 years.  The likely reason that it doesn't show itself in 2013 and does in 2016b is that the latter is compiled with a newer C++ compiler that happens to arrange process memory a little differently.  That difference caused a bit of memory used during process shutdown to be corrupted.  Previously, the  corruption didn't effect memory that was important enough to cause issues.   

Thank you for reporting the problem.  It will be fixed in the next release of WinBatch and WinBatch+Compiler.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade