Thanks to the above testers for their help in tracking down this issue.
I am posting the following mainly as documentation for future reference.
The testers were able to reproduce a heap corruption crash by running test scripts that called specific commands/identifiers in mIRC for ten minutes to an hour. Unfortunately, I could not reproduce the issue, despite:
Using the same configuration as them, ie. a clean copy of mIRC v7.69 release version, default settings, with the test script.
Testing on five different computers, including a cutting edge Ryzen, with Windows 10.
Testing on Windows XP, 7, Windows 11 22H2, Ubuntu Wine under VirtualBox.
Testing mIRC with full debugging, AppVerify, etc.
Running the script, and variations of it, for hours at a time.
Repeating the tests many times in different contexts.
An intermittent bug like this one usually involves threads and data races/race conditions but a code review did not show up anything. Testers were able to reproduce the issue with different combinations of commands/identifiers but it wasn't clear which was the cause. Private betas were released with code changes hoping to improve robustiness in several features without result. Unit tests that created multiple threads to try to force heap corruption/data races/race conditions did not reproduce the issue for me. Dump files, exception codes, fault offsets, etc. did little to help narrow down the cause.
The testers eventually determined that the issue began with v7.53. I also finally reproduced the issue once in a debug version of mIRC after several weeks of testing.
It turns out that the issue was due to a combination of changes, across several features, related to memory-handling that resulted in a data race/race condition window outside of the critical sections that were in place to prevent this.
The issue was resolved by making minor changes to how memory is handled in several features, including hash tables, regular expressions, INI files, binary variables, and file handling.
This fix is in the most recent beta.
