I’m working on a project using the TADS 3 Workbench together with someone else. He had compiled the windows exe to send it to someone to playtest. The playtester unfortunately got back to us with a tadscrsh.txt and I have no idea how I should interpret it. Both the compiling PC and the playtesting PC are using Windows 11. The game opens and then closes immediately on the playtesting PC. The project does run correctly on other PCs running Windows 11, but for whatever reason not on that playtesting PC.
The tadscrsh.txt:
exc_handler = 005b8e50
CS:EIP = 00000023:00552ce1
00472eaa
59252d6d
I tried finding any sort of explanation to what those numbers in the crash report could mean, but I can’t find anything in the documentation. Are the numbers explained somewhere? Does someone know what this crash report could mean?
Depending on how you sent the file to them and the fact that it is a windows executable, I think that the executable is somehow untrusted on the playtesting machine. This could be an overzealous A/V. This is not enough information to say anything more but you may want to send him some another game that you know works and see if it crashes as well. Build up some data points on if it their environment, a flaw in how the compilation is being done, or something else. There may be a security screen log to tell you something. I know digging in the event viewer is not everyone’s cup of tea but it should tell you more.
1 Like
@Candy64 offers sound advice, @3AMRambler .
Unless you understand machine code (Intel in this case), those numbers won’t mean anything. (It is the program pointer Code Segment (CS) register along with the program counter (EIP) offset followed by a partial CS stack dump. The Exception Handler address is listed first.) BUT, unless you have the source code (for TADS) compiled and can see the optimized code offsets, you won’t be able to figure it out anyway.
TADS is very stable, but some things can make it go sideways and it is almost always due to something in your game source code causing it – because, in the end, it is a compiled code.
My additional suggestion is to have this tester install frobstab or similar and send them the compiled tads file (.t3) to play on that engine rather than the “wrappered” Windows EXE. That would eliminate the wrapper as the problem and, if it still happens, you can now focus on the game content non-obvious issue.
1 Like