If mIRC crashes, there is no way to guarantee that a file will be saved properly. For example, if the crash is due to a bug that overwrites mIRC's settings in memory, and mIRC then attempts to save the settings to mirc.ini, it may end up saving invalid data. The only solution in this case is to try to find out the cause of the crash so that it can be fixed. That said, when Windows is in a low resource state, and Windows and/or applications are unable to allocate memory or save files to disk, and end up freezing/crashing because of the low resource state, almost anything can happen, including crashing and file corruption.
I was just talking about infinite loop + force closing to simulate crashes, but yes, when the app crash all handles are closed and their content might be corrupted, however, in this case mIRC does not have mirc.ini opened so mirc.ini will never be corrupted, that situation only happens when mIRC exits, where it has to save the settings. I'm sure a lot of people use sleep mode with mIRC without any trouble, so the real issue is probably just low spaces on the disk or too few ram available when mIRC is about to do this saving process.
I got my C:\ to be full again for the purpose of this test and I reproduced the issue.
$disk(C:\).free returned 0 and I immediately /exit -nr, mIRC reboot with a blank mirc.ini. I had plenty of ram so the temp file was probably fine, it's just when you are writting to the disk that it must get an error.
I'm not blaming mIRC, clearly I have no space left on the disk, mIRC can't magically find spaces but I'm saying that, well, for one thing it could check if there is spaces available, but in any case the current mirc.ini file on disk should not be touched in this situation, what do you think?
