Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
"EXE has stopped working ..."
#1
I have started converting 3 of a family of inter-related QB programs to QB64 and have run into the issue of getting the Windows message:

"program" has stopped working

A problem caused the program to stop working correctly.
Windows will close the program  etc, etc.

The message is not immediate but comes up within a minute on all 3. 

Each program can start another using RUN. Sometimes the message appears when another program loads but before the program itself displays its screen.

Within one program I do some data file access and after pulling up records a few times the error appears.

Any suggestions on how to diagnose or eliminate the issue?

Thanks,




[Image: Win-error-2.jpg]
Reply
#2
Instead of RUN use Shell and Shell a compiled bas. You can Compile a bas and Shell that exe (to Run it) on the fly if you are careful with folders.
b = b + ...
Reply
#3
Thanks. Tried it:

Replaced RUN with SHELL. It didn't solve problem (still got WIN error) and when SHELLING the calling program remains open which I don't want since going between programs leaves multiple iterations of programs still open.

Also, I am not sure what you mean by "Shell a compiled bas." I am compiling using QB64.exe and running the EXEs.

(FYI the original QB programs used CHAIN because of common variables but I removed CHAIN and used RUN, but that's going to be a question for a different thread.)

A
Reply
#4
Can you share the code so we can test the issue ourselves?
Reply
#5
I'd say start by integrating all 3 sources in one.
Just change overlapping labels/linenumbers or break up in easier to maintain subs and functions.

Chain was used because of memory limitations.
Now with QB64 this is virtually gone.
45y and 2M lines of MBASIC>BASICA>QBASIC>QBX>QB64 experience
Reply
#6
Thank you for the responses. I did "solve" the problem but I want to reply to you both first.

To SMcNeill:
                    It would not be beneficial to give the source code since the programs require a specific directory structure and data files to execute properly. Also, what turned out to be the offending program is probably around 4000 lines long.

To mdijkens:

A bit of background on the programs would be useful here:

I started developing a "suite" of interrelated programs starting in the mid 80's. Because of QB program size restrictions I used $INCLUDE often as well as compiling multiple .BAS modules at into a single EXE.

The result has been about 60+ fairly large BAS programs compiled into around 40+ EXEs all using CHAIN (to go to other modules) for COMMON variables. I will probably be changing that.

To see if converting to QB64 was a job I wanted to tackle I "converted" 3 programs enough to run. So to your point, trying to combine them (all 60+) into one module was a thought I had but there are so many overlapping labels and line numbers as well as contradictory/reused variable names that I would give up if that was the only route.

--->
Now as to the original reason for this thread, after much insertion of my own debugging code and many recompilings of the larger of the 3 programs I was able to narrow the cause of the error down to several lines of code:

FIELD #10, 80 AS LG$
also
GET #1, rn
and perhaps I will still find others.

Strangely I didn't get the error every time one of these lines was executed.

If I REM these lines the error disappears completely. So it had something to do the the file I/O or access.
I rewrote some code before these lines which OPENed the file, unREMed the offending lines, and now it works fine.

I don't know why I didn't just get a more specific RUN TIME I/O error with error line # instead of the generic and extremely unhelpful Windows "program stopped responding" message.

Again, thanks for the replies. Will probably post more questions later.

A
Reply
#7
Thanks for your clarification.
Been there also in the 80's; used same techniques.
Your errors are strange and non-saying indeed
With refactoring of much of my old ('80-'90) code I've, in a lot of cases, rewritten the file access parts too to get things reliable.
Another point of attention is serial
45y and 2M lines of MBASIC>BASICA>QBASIC>QBX>QB64 experience
Reply




Users browsing this thread: 1 Guest(s)