I found a $utfencode bug which can cause a GPF, but it does that only intermittently, and the first attempt to trigger the GPF hasn't ever succeed. I've encountered the GPF both with/without unchecking the box options/irc/messages/utf8-encode, and with the output either displayed to a window or silently filled into a %variable. The only common factor seems to be using the 2nd parm of $utfencode.

I was trying to help someone who had been using v6.35 at a server which uses a non-UTF8 Turkish codepage, which was able to display nicks containing the stylish S from $chr(350) correctly in v6.35, but in the current v7 versions it was appearing instead as the thorn character of $chr(222). In hunting to see if there was another codepage not listed in the sticky thread https://forums.mirc.com/ubbthreads.php/topics/224231/unicode-support or seeing how charset 162 behaved, I was hunting for detail on the Turkish charset 162, and to see if there were any other charsets which showed the expected stylish S. I was able to get both of these to crash mIRC several times, whether echoed to screen or silently filled into %a.

//var %i 128 | while (%i isnum 128-350) { echo -a %i : $utfencode( $+($chr(%i),test) ,162 ) | inc %i }

//var %i 128 | while (%i isnum 1-999) { echo -a %i : $utfencode( $+($chr(350),test) ,%i ) | inc %i }

//var %i 128 | while (%i isnum 1-999) { echo -a %i : $utfencode( $+($chr(350),test,$chr(222)) ,%i ) | inc %i }

It never happens the 1st time after restart that I try either of the above, and seems more likely to happen if I try it after permitting mIRC to be idle for a while. It never seems to help by trying the above command multiple times in a row. The 1st crash was on beta 649 while connected to that Turkish server, but all the other crashes were on beta 956 without being connected to any server. I know bugs are harder to nail down when you can't make them happen on-demand, but I'm stumped on what to do which would 100% trigger this, other than it happens sometimes with this kind of usage of $utfencode.