Forums Feature Suggestions Better crash handling

Simple concept, better handling of mirc crashes.

It is not a very common occurance for mirc to crash, but when it does its often impossible to tell why. Infact half the time it does crash, with no warning, for no apparent reason (under all sorts of circumstances, ie in systray, while actually active and reading something in a window, while in background behind another program and so on). Sometimes windows crash box pops up telling you a debug or whatever is being created, however not at all times.

So i guess my suggestion is better built in crash handling, ie create a crash.log with as much information as possible. Many programs incorporate such features, which greatly helps in determining exactly what caused the crash.

Personally, i have been unable to determine any constants in the situations, apart from actually being connected to multiple servers. Have also been unable to find anything in any of my script files that could be causing crashes.

I do not recall ever experiencing crashes pre mirc 6.x and not sure even about 6.0, and my system/background processes and so on have not changed since before they started.

As i said, they are not common occurances, but some better crash handling would definately help pin point the causes.

I would assume that if it was possable to create adquit crash handling, then it would be possable to thus mitergate it occuring. The whole fact that something crashes is the problem with handling it, you cant it crashed!

Well, last night, my mirc.exe file got corrupted somehow. It froze and I closed it and reopened it and it would crash immediately every time. I replaced the exe and it works fine again, so it wasn't a script problem. Anyhow, you know that "send bug report" window that wil usually pop up when it crashes? If you view what's in it and view the tech info (you click two links to get to the info), you'll see the data that would be sent. If you scroll down, you'll see the hex information. Scroll down far enough and watch the ASCII representation of that hex (the right side) and you'll find the reason why it crashed. Of course, you may not be able to figure out what it means... but, it will still give you the reason and it may be useful.

No such box has ever come up for me when mirc has crashed, sometimes i will get the 'windows is creating a crash log' box from windows, however not always. Besides, windows crash detection and logging is generally not a lot of help (and hard to find). In cases where this does not occur, mirc seems to just crash without warning and no crash log creation (unless it happens to quick for me to see it).

DaveC, it is possible, i use several other programs that have such extended crash handling in the program itself (perhaps this is just something in the os that the program has to be written to trigger, i dont know, but point is that it is there for several programs i use, but not mirc which has been crashing randomly on occasion recently). Plus, i think we are all aware of windows itself being and to create detailed crash log / memory dump etc when is blue screens...

Oh dont get me wrong, I know mosty (if not all) things can be trapped, its just, what level of recoverability the application might have from it, say mirc throws a accessed memory out of bounds error, Well hell what are we ment to do next? I wouldnt think just plunging it back into some main code loop (if there is one) is going to be overly stable. An amagine an unknown instruction error. eeeek what is the cpu doing, what code can we trust is ok if it reached that!?!?!?.

PS: Im not overly if at all familar with the cpus error trapping procedures, i do know different levels of programs superceed each other, this is somewhat how the OS multitasks, with the OS's kernal always being able to gain control even if the program has entered a dead loop, well thats the theroy at least LOL!

Indeed i understand what your saying, but even a minimal level of crash handling would be useful, not specifically suggesting any type of crash recovery although i do understand that some level of recovery would be required to be able to generate a crash log before the process is terminated, shrug, perhaps even a special copy of the mirc.exe could be compiled with advanced debug output or crash handling that people experiencing undeterminable crashes could run temporarily to try and pin point the problem.