Forums Bug Reports Mirc Keeps freezing

In your clean mIRC, type the following in any window:

//echo -a $version $os $md5($mircexe,2) $script(0) $dll(0) $com(0)

Report the results here.

6.35 Vista 2f63a83968f9586fe4fb48134253619c 1 0 0

The issue happens randomly when I'm idling or otherwise, downloads go through fine. I'm not using SSL. The issue did happen before I added any scripts, but I'm going to do another clean reinstall and see how it goes for a couple days.

Does this happen only when mIRC is maximized? Or whenever it's the active window? Or when it is minimized? Or does it happen no matter the state of the mIRC window?

If it only happens when mIRC is the active window (maximized or not), does it happen if your mouse is NOT over the switchbar (if you have that enabled)?

I never have the mirc window maximised. It happens for me only when the channel the Japanese characters are displayed on is active. I do use the switchbar, but it doesn't seem to matter whether my mouse is over it or not, it has crashed in both occasions. It is very simple for me to reproduce this, but only when using gtsdll. All I need to do is play a song on winamp that has fullwidth characters in it (taking into account that all Japanese characters are usually fullwidth), for example ノート・ネイティヴ - Ｔｗｉｌｉｇｈｔ, use /aud to display what I'm playing, the encoding gets screwed along the way and it displays garbage in the mirc channel window, I'd copy the garbage to show, but mirc pretty much crashes instantly with AppHangB1. Note that this is the on-demand way to make it crash, not the only way it happens to me.

*Edit: before someone says this is because of gtsdll sending mirc crap it can't handle, that's not entirely true. I can't make it crash by simply copying those same characters straight into the chat window, it displays the characters correctly and nothing happens. However, when I use the gtsdll command /aud in a different chat channel, it displays the characters correctly and does not crash. The difference is in font script. In the channel it didn't crash I use Arial Unicode MS with Japanese script, in the channel it displayed garbage and crashed I use Arial Unicode MS with Western script. Why Western script can display Japanese characters often times just fine, but occasionally crashes on them, I have no idea.

With your situation, I'm sure it's an issue in the DLL. It may not handle multibyte/unicode characters properly. If you were to display the song using either COM or mIRC's built in methods ($sound, $mp3, $insong, etc), it probably wouldn't crash for you. That, of course, means playing the songs in mIRC to test.

You might check to see if anyone can use that DLL to display the same title(s) without crashing. If no one can, then the DLL likely needs updated or another method should be used. If anyone does, then see what OS and mIRC version they have and that would narrow down if it's an OS change or mIRC change.

For the others in this thread, please also respond with the answers to those questions as they may help narrow down the cause(s) of those particular situations.

I had edited my previous post while you replied. This shouldn't be an issue with gtsdll, as this has happened with simply having correctly displayed Japanese characters in the channel window (with the Western script). I can't recall there ever being a crash in the chat window where I had Japanese as font script since the time I had changed it to Japanese there (should've noticed this when I did the change, but I still thought it was about the font).

*Edit: before someone says this is because of gtsdll sending mirc crap it can't handle, that's not entirely true. I can't make it crash by simply copying those same characters straight into the chat window, it displays the characters correctly and nothing happens. However, when I use the gtsdll command /aud in a different chat channel, it displays the characters correctly and does not crash. The difference is in font script. In the channel it didn't crash I use Arial Unicode MS with Japanese script, in the channel it displayed garbage and crashed I use Arial Unicode MS with Western script. Why Western script can display Japanese characters often times just fine, but occasionally crashes on them, I have no idea.

It helps to know that the font/encoding plays a part. That definitely narrows it down a lot better. Because you can copy/paste the text directly into mIRC and it shows fine regardless of encoding (Japanese vs Western), it still points to the DLL being at least partially the cause. It may also be possible that the text you're trying to display actually has another character that you're not seeing... one that Japanese encoding can deal with, but Western cannot. If you were to edit the ID3 for that song (make a backup of the song first so we still have the original to test with) and paste in what you see in the channel then try displaying it in the Western encoded channel, it might work because you might not end up pasting in a "bad" character. I've come across certain MP3s that had corrupted ID3 tags that mIRC didn't like and just editing the ID3 with what appeared to be the same information fixed the problem. Just to note, a better way than copy/paste of that would be to get someone to type the song name using the Japanese characters and then copy that so that you can't accidentally copy some character that isn't visible from the original.

Just to check, see if you can display the title in the Western encoded channel using mIRC's built in identifiers like I mentioned earlier. If it crashes then too, then it's likely a problem with the ID3 tag. If it doesn't, then it's likely a problem with how the DLL sends that particular tag to mIRC. Remember to display the title tag rather than the filename.

I can do that, yes, but before I do, you should know that using DLL was just a way for me to reproduce the issue on demand. gtsdll or mp3 ID3 tags are definitely NOT the cause of the problem, or it's a different issue. There is a log channel I'm in where a bot reports any changes made in a database of a website, often the changes include titles and names in Japanese characters. So what I did was change font script from Japanese to Western in that channel and scrolled up until mirc crashed. During that time the following non-ascii characters were on screen: "ギルバート・ケント", "魔星降臨" and "Le siècle de l`enfer". I later forced that same bot to report the same words again to see which of them makes mirc crash, "魔星降臨" and "Le siècle de l`enfer" didn't, but right after "ギルバート・ケント" appeared, mirc crashed. These are all katakana characters, save for the middle dot and the long vowel mark ー. I checked if there were any characters specifically that would make it crash, but none of them displayed alone did. Eventually I narrowed it down to バー, that made mirc crash (while ート didn't). However, when I entered that text myself or had someone else type it to channel, it didn't cause any crashes. What's the difference? Colour codes. DLL and the bot both output with colour codes. I can type in "(ctrl+k 3)バー (ctrl+k 7)bla" or "(ctrl+k 3)バ・ (ctrl+k 7)bla" and crash myself and so can anyone else. It only seems to work with certain character combinations, which I suppose happen often enough if you are in the right channels. This would explain the crashes with DLL and fullwidth characters, when encoding fails and it displays garbage, there are many non-standard characters there and combined with colour coding, they'll make mirc crash. But you still need to have Windows 7 (not sure if it matters if it's 32 or 64 bit), Japanese locale and mirc font script set to Western (or probably anything unable to properly handle certain characters).

Very interesting. Thanks for the detailed testing and results. That should make it much easier for Khaled to reproduce and fix the bug. If I were to make a guess, I'd imagine that the Western encoding is trying to display a character by combining the $chr(3) with the katakana... basically what multibyte is meant to do in the first place, but just getting confused over which bytes to combine. Of course, I may be way off there.

I'll test this out at home later today and see if I can make it work. Unfortunately, I don't have a Japanese locale. I'm not sure if that will matter, but I'll try anyhow. I'll probably run it through a few different versions of mIRC to see if it affects "all" versions (of the ones I test) or if it might be a change made somewhere along the road that caused it. If that turns up anything, it might help to point out exactly what the cause is.

Thanks again for all the testing and detail. That kind of bug report makes fixing bugs much easier!

Ok well after running it for a few hours it was working pretty well, but after I went to sleep (literally, didn't put the computer to sleep)and woke up the program crashed. mIRC was maximized, but it happens regardless if it's active or not. I disabled the switchbar cause I use the tree instead. I have one more thing to test out. Currently I'm in a couple of channels that use different Japanese encoding (UTF-8 vs SJIS or ISO2022). I'm going to try leaving all those channels today and see if it still crashes.

Yeah, try that and see. You might also want to check timestamps when it crashes (leave it active so you can see even if it freezes) and see what time it freezes if it does. If you can find any common time, there is a possibility of a conflict with some program that does something at a specific time of day or night (such as an antivirus scan). If the times vary, then it isn't related to a timed event. It's something to check, though. But because you are also in Japanese language channels, I'm thinking it may end up being a similar situation. If it doesn't crash when you're not in those channels, let us know.

It's possible that all of this will be fixed "automatically" when we get the unicode version of mIRC as that will handle unicode differently than it does now since it will be fully unicode compliant.

Well it still crashed even after leaving the channels. Let's hope the unicode version of mIRC fixes this issue, since I'm in channels where people still use Japanese occasionally.

For those experiencing the freezing issues I have found a few very aggravating factors:
1.having a switchbar that's filled(and forced to reduce size of the buttons there), this somehow critically slows down mirc very slowly.(it makes me wish that the switchbar could get more than 10 lines)
2.Having font linking on

Another problem might be having more than 128 windows open... but I have not yet been able to confirm that.

So far with a non full switchbar, less than 128 windows and font linking off I'm not experiencing any freezes any more.

If you are logging 128 windows and/or have the buffer set high, you will experience lag issues and potential freezing. Consider what happens if you are trying to write data from even half those windows on a regular basis, or if you had for example a 5000 line buffer, then that is 128 * 5000 (640,000) lines to keep in memory. These things are going to slow down the computer and there's not a lot you can do other than to limit logging or reduce the buffer... 1000 is plenty for most people for a buffer, especially with that many windows open at once. Even less may even be advisable for that many windows.

Obviously, there may be other factors involved, but either of these items is likely to be a major factor for you. And, font linking that many channels may also be a slow down as well, though I'm not sure if that's only used when a line is received, or all the time. If it's only when a line is received, then it's not likely an issue unless you're getting constant lines in all of those windows at once.

I'm just wondering: are you aware of the Treebar? (View > Treebar or /treebar on)

Font linking should only slow down on the first (few) run(s) as mIRC builds up its internal cache. Afterwards the delay should not be noticeable.

Low buffer helped here too, forgot to mention that. Also I turned off logging on the mirc side a long time ago.


If I have to scroll, which is quickly the case with the treebar, then it's not useful to me. That's why multi-row switchbars are great, they display everything.


Maybe the linking is fast, but maybe having to query (certain) other fonts is slow. It certainly did change display speed in some cases with tons of odd glyphs.

I think the point in your case is that your slow downs or freezing aren't likely bugs. If lowering the buffer enough prevents it, then that's just a matter of memory usage caused by so many windows. Yes, it may be possible to optimize things some more to make it possible to handle larger numbers of windows with large buffers, but in the end, you're still going to be limited to what the system can handle. That's not a bug. The same with font linking - it can possible be optimized some, if that's even necessary when we get the new unicode release, but it isn't a bug.

It's no different than if you tried to open a hundred programs... unless they were really small, that many would likely slow Windows (or any OS) to a crawl. That isn't the OS's fault - it's not a bug. Just a limitation on system resources.

As such, I think it would be good to stick to actual bugs, or what are possibly bugs, in this thread/forum to avoid confusing the issue and making it more difficult to find the actual bugs. If you'd like to request optimization of mIRC's features to allow so many windows, that is better placed in the feature suggestion forum even though it's not technically a feature. So many people with completely different (or seemingly different) problems have used this same thread just because the results are the same... it makes it difficult to determine what the cause is or even if they are related.

Thanks for your help in narrowing down this issue. I have not been able to reproduce it yet (tested under Windows 7 32bit, an English version with system locale set to Japanese, using Western/Japanese font scripts in mIRC, and /echoing and /msging myself with the combination of characters you mentioned).

Could you try one more thing: could you try toggling the switches in the Options/IRC/Messages dialog "SJIS/JIS conversion", "Multibyte display" and "UTF-8 display" to see which one is the cause of the crash? That would help narrow it down even further.

Also, if you use the "/debug on" command it will output raw server text to a debug.log file. When mIRC crashes, the last line or two in the debug.log file will likely be the cause of the crash. That would be of immense help as well.