Forums Bug Reports mIRC sometimes does not exit when it should; hangs

Executing this code, you should be able to minimise mIRC, then right click on it in the task bar and click "close"...

mIRC pops up saying "Are you sure you want to exit mIRC? mIRC is connected to a server."

However, confirming the decision to exit merely goes back into the infinite loop, and mIRC doesn't close as you'd expect.

Thanks for your bug report. What you are seeing is expected when an infinite loop script is running in a single-threaded application like mIRC because it does not allow Windows PostMessage()s to be processed, which are used both by Windows and mIRC for the majority of events.

So what you are saying is when I confirm that I want to exit mIRC and it hangs, this is "not a bug; it's a feature"?

Just so you realise, this attitude sucks for you because it makes your software seem inferior in quality. It has the potential to impact your sales; those sales aren't mine, so I'm not actually that bothered. Do you understand?

Seb: If ...

1. Windows is an event driven operating system; and
2. If mIRC is designed to work under Windows and is therefore designed to be event driven; and
3. An in finite loop prevents events being processed, including a close event

Then ... mIRC hanging is an inevitable consequence.

Ditto for any other single threaded application in an infinite loop. In other words its not just mIRC.

Yes - you could argue that mIRC should be multi-threaded, but that brings its own complications - complications which might well be surmountable in a tool without scripting capability (though infinite loops would not then be possible anyway), but are almost certainly insurmountable in a product like mIRC with scripts.

After all if an interpreted language like python cannot solve the multi-threading problem, I can't see why mIRC should be any different.

If you don't like mIRC there are many alternative IRC clients out there - including one which professes to have some sort of mIRC scripting compatibility. Good luck.

There is an DLL about that situation i used in the past in order to not stuck the mIRC during some big while loops, i don't know if it is out-dated or not have a look if you want into that link, you may find that you need.

I would approach it by iterating using a one-off timer with a 0ms delay.

Inbetween the current script finishing and the new one starting it should execute the event loop and process outstanding events like quit.

Then why do you respond as though you were personally attacked?

FWIW, you can stop such a broken script with Ctrl+Break. After that, you can close mIRC normally if you wish.

I can't reproduce what you're seeing. When I create that alias and run it, mIRC does not respond either to clicking the red X in the taskbar popup window to close it, nor does it respond to clicking on the minimize button. When I press Ctrl+Break, then mIRC is no longer frozen, but it still doesn't respond then to the prior clicks of the close icon or the minimize button.

When I use from an editbox instead, i get slightly different behavior, but not as you're describing. From an editbox I do:



... and mIRC is frozen, I click on on the minimize button in the upper right corner, and nothing happens. However as soon as I press Ctrl+Break, mIRC immediately minimizes. If I repeat the editbox command, only this time I use the taskbar icon's red X in the taskbar popup window to close the program, and again nothing happens. I then press Ctrl+Break, and now the "are you sure" prompt comes up. I'm not sure what you're doing to get it to display the "are you sure" during the while() loop.

I cannot reproduce this either. However, different versions of Windows behave differently in this context.

Since the confirm exit dialog is being displayed, this means that Windows is using a SendMessage() to trigger WM_CLOSE. However, mIRC uses asynchronous messages to exit, which is why it needs to wait for the script to finish.

If I recall correctly, the exit method used to use synchronous messages to force an immediate close but this had a number of side-effects, including issues relating to scripts, COMs/DLLs, and so on. It was eventually changed to use a slow, asynchronous exit to allow scripts to finish normally.

It is difficult to remember the rational behind all of these decisions because there have been so many changes to the exit method but looking at the code, the script parser has a check for a global exit flag but it has been commented out. My guess is that there was a decision to allow scripts to complete normally during an exit, instead of halting them in the middle of a run.

mIRC does set $exiting, so any script that does take a long time to process can detect whether a user or windows has requested an exit, which allows the script to halt safely without leaving behind corrupted files/data/etc. However, a badly written script, such as one that uses an infinite loop, will simply persist, and mIRC can then only be closed forcefully by Windows.

I haven't tested this but we should also remember that infinite loops will almost certainly stop other scripts from processing and might stop other stuff processing - like displaying messages in channels - indeed, since stuff cannot be displayed until any scripts have run, this is quite likely to be the case.

As suggested before, long running looping scripts should probably loop by using a timer in order to let other stuff get a look in and execute.

If I run a while loop from the editbox, "//while (1) /", Windows can be sending anything it wants to, mIRC will never ever check the message loop until the msl's while loop ends, therefore it is impossible, under any version of Windows, for mIRC to see the WM_CLOSE while the loop is running, is that not correct?

That should be the case but... I just checked and it isn't. mIRC is actually processing SendMessage()s, even during a busy script. After looking into this a little more, I found the cause: some versions ago, a user reported that when mIRC was busy, eg. running a long script, for more than a few seconds, Windows 10 was treating mIRC like a hung application and was preventing users from minimizing mIRC. This is different to how previous versions of Windows behaved. To get around this, I tried a number of different methods, all of which had side-effects, and finally settled on using PeekMessage() with PM_NOREMOVE and PM_NOYIELD to let Windows know that mIRC was still "awake".


Unfortunately, it turns out that calling PeekMessage(), even without processing messages, causes Windows to trigger SendMessage()s processing. So it now looks like I will have to revert this change.

Alright, thanks.

I never said "click the minimize button".

Switch to a different process. Right click on the mIRC task item. Click close. You get a confirmation dialog, right? Do it while the infinite loop is running.

It was a logical assumption from your "you should be able to minimise mIRC".

And no, I don't get any response from mIRC during the time when your 'testcase' alias or '//while (1) noop' is running, regardless whether or not I keep mIRC as the active app, or whether I switch to another process by clicking on the other icon in the taskbar or using Alt+Tab. It won't respond to the minimize/close buttons in the upper right corner, it won't respond to closing from the taskbar, either from the red X in the taskbar popup window or rightclicking the taskbar to get the 'close window' choice to appear. The closest thing I can get to a response during the infinity loop is that the taskbar does let me toggle the "pin this program to taskbar" setting.

When I switch to another process, the display switches to that process. When I click on the taskbar or use Alt-Tab to switch back to mIRC, there's no visual feedback of the process switching back until I press Control+Break. Only then does the display change from the other app's contents back to displaying the mIRC window.

This will no longer be the case in the next beta/version. A script running an infinite loop will make mIRC unresponsive, and such a dialog will not be displayed until the script finishes.

Thanks for your comments everyone.

Just in case anyone reads this because they are trying to stop a lengthy looping script causing issues, here is sample code which can be used as the basis for such a script:


P.S. If you find you need to add a small delay between loops then ".timer -m 1 10" is an alternative.