Interesting problem involving the runtime engine

[Dennis]

Hi
I did the following:

1. Made a .TKN file out of my application (QMAIN.BAS) and saved the .TKN file into a directory. No problem and I now had a QMAIN.TKN file in a directory.
   
2. I copied the runtime engine (RUN451.EXE) and all the v*.dll files into the same directory with no problem.
3. I then renamed the RUN431.EXE file to QMAIN.EXE - no problem.
4. Successfully ran the application using the now named QMAIN.EXE program a few times with no problem.
5. I decided to delete the directory using standard Windows Explorer - got a Windows error that a file was still open in QMAIN.EXE.
6. I double-checked my application to make sure that all the files were being properly closed and that the program was terminated with an END statement. All in order.
7. Decided to delete the files in the directory one-by-one and testing to see if the error remained.
8. I successfully deleted most of the files including the QMAIN.TKN file with no problem.
9. I was left with 3 files which did not want to delete. When attempting to, Windows gave me the "file in use" error. 
10. The files were; the renamed runtime engine (QMAIN.EXE), vvm31w.dll, and vvmt31w.dll.
11. Rebooted the computer and tried again. All files could then be successfully deleted.

Am I doing something wrong or is this a problem with the runtime engine?

I am running Win10 Pro.

Thanks

[xxgeek]

To figure out if it is your code, I would need to see the code.

You could add a line to kill the process (QMAIN.EXE) and that should take care of the dll files too as it dies.

RUN "taskkill /IM QMAIN.EXE /F", HIDE

HIDE will prevent the black command window from appearing.

/F forces quit without the 'are you sure' message if there is anything of the sort.

[Brandon Parker]

I would assume that it is something in your code not closing properly.


{:0)

Brandon Parker

[Rod]

Yes, you are not reaching the END statement if you have one in your code.

[Dennis]

Hi

Thanks all for responding.

I spent a long time checking to make sure that everything was closed and that the END statement was processed. I used numerous "diagnostic" messages to prove and test that all files were closed and that the END was reached.

If you END with open files, LB normally warns you that it is closing them for you - I did not get any such warning.

I cannot supply the code as the "QMAIN" I refer to is something I offer commercially and is over 2000 lines long. The original QMAIN was developed in another BASIC about 10 years ago and runs as an .EXE in many sites.

I will strip things down and experiment when I have the time. I will also add the "RUN" statement to see if that does the trick.

Of interest is that it is the runtime engine - perhaps Carl can comment?

Regards
Dennis

[Carl Gundel]

Oct 28, 2021 4:47:31 GMT -5 Dennis said:

Of interest is that it is the runtime engine - perhaps Carl can comment?

Is anything written to the error.log when this happens?  I'm not sure how to pursue this if we cannot reproduce it.

-Carl

[Rod]

It is possible that the program crashed earlier. If the program crashes it will leave files open. These can sit unseen for some time and require Task Manager use to close all instances of qmain.exe. So while you have been testing and it all appears fine what may have been happening is that you have been opening and closing one instance successfully while another failed instance hangs about in the background.

More testing required. I would say that it definitely has to have been a crash at some point that left one instance of qmain.exe hanging. Check the error log for older crashes. However I suspect that there was nothing written to the error log else you would have been shown the error.log notification. Some crashes just crash straight out close the window and make it appear the application has closed.

Clear out your error.log so that you will be surer of any new entries.


I don't restart my computer very often. My programming is so bad I often find I have six or more instances of liberty.exe listed in Task Manager!

Another thought, what happens if two instances of your program are fired up side by side by an impatient user clicking the icon more than once? Do you get two instances or do they fight over file access?

[Dennis]

Hi Carl and Rod

Rod, I think you are pointing me in a direction as I was testing the system earlier. I will test the "two-file" situation.

You are right Carl - without the error log you are flying blind. The problem is long past and hasn't occured again so I think Rod's reasoning about an earlier test is plausible. I don't often reboot so the "file lock" could have been from that earlier testing causing a "crash".

I will clear the error log and keep a watchful eye on the situation.

The problem is not a dealbreaker! I am just imagining a remote "user" of my systems who is not too experienced in operating systems being faced with the situation.

Rod, rebooting the system was my quick way of getting Windows to release any "lock attributes" that may be set. I could have played around with the operating system functions but did not have the time or inclination .

Thanks for responding - I am not too familiar with using the runtime engine so was concerned that I was doing something wrong.

Regards

Dennis

[Dennis]

Hi Rod and Carl

Confirmed that the problem is due to earlier crashes.

I am experimenting with the Windows' mmc, tasklist, and taskkill commands. I will probably create a short utility using a RUN command as suggested by xxgeek...

Thanks for responding

Regards
Dennis

[Dennis]

Thanks xxgeek. I am going to use your suggestion for something else...