[...] so I feel like the error might be misleading [...]
The renpysteam error
is misleading. Like I said, this line is on all the logs.
For some reason, Ren'Py now try to import the module by default, what obviously lead to an error for all games that don't depend on Steam. Therefore, unless you're playing such game, it should be seen as a warning, not an error.
P1: TroubleinParadise.exe
P2: 0.0.0.0
P3: 58942445
P4: StackHash_d01d
P5: 10.0.22000.918
P6: 81cba20a
P7: c0000374
P8: PCH_50_FROM_ntdll+0x0007513C
P9:
P10:
P7 point to a heap corruption. ntdll appear in the report more surely because it's where the error became fatal, than because it's what caused it.
The fact that it's a heap corruption error would also explain why the log is stopped mid writing. It's a critical error and the process at fault must totally stop to prevent a global corruption ; this could compromise the data from other software or crash the system itself.
Now the problem is that it's something constant enough for it to stop the log at the exact same place for anyone who face it. But also something so specific that it happen exceptionally in regard of the number of people playing Ren'Py games.
It's also something that have been "solved" with Ren'Py 7.4.x branch. As I said the only difference is the version of Python used. But this change seem to also imply a difference in the way the interpreter link to the needed libraries. Its own library pass from a size of 2.34MB for 2.7.10, to a size of 5.64MB for 2.7.18.
It's not possible that the interpreter had so much code addition for what is just a bug fix version released after the end of life of Python 2.7. It looks like they included in the library a part of the code that was previously dynamically linked to Windows' libraries.
In the end, my guess goes to an error in Windows C libraries. That would also explain why the guy in the link gave by ambir can run Ren'Py games on safe mode. Windows being then more conservative, it would rely on the base libraries and not a (corrupted ?) redistributable version of them. That would also explain the heap corruption (that would be more virtual than real) if the link table is wrong.
Now, and if I'm right, how to fix this is something else... Personally I touched the limits of what I still know about Windows and C libraries.