mIRC Homepage
Posted By: Zabache Crash Report analysis please.... - 17/11/13 10:39 AM
I see crashes for this same error daily, any clues will be helpful.

<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="mirc.exe" FILTER="GRABMI_FILTER_PRIVACY">
<MATCHING_FILE NAME="mirc.exe" SIZE="3298864" CHECKSUM="0x61FC9E5F" BIN_FILE_VERSION="7.32.0.0" BIN_PRODUCT_VERSION="7.32.0.0" PRODUCT_VERSION="7.32" FILE_DESCRIPTION="mIRC" COMPANY_NAME="mIRC Co. Ltd." PRODUCT_NAME="mIRC" FILE_VERSION="7.32.0.0" ORIGINAL_FILENAME="mirc.exe" INTERNAL_NAME="mirc" LEGAL_COPYRIGHT="Copyright © 1995-2013 mIRC Co. Ltd." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x32E0C9" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="7.32.0.0" UPTO_BIN_PRODUCT_VERSION="7.32.0.0" LINK_DATE="05/23/2013 14:18:26" UPTO_LINK_DATE="05/23/2013 14:18:26" VER_LANGUAGE="English (United States) [0x409]" />
<MATCHING_FILE NAME="uninstall.exe" SIZE="149920" CHECKSUM="0xCA95F9CA" BIN_FILE_VERSION="7.32.0.0" BIN_PRODUCT_VERSION="7.32.0.0" PRODUCT_VERSION="7.32" FILE_DESCRIPTION="mIRC" COMPANY_NAME="mIRC Co. Ltd." PRODUCT_NAME="mIRC" FILE_VERSION="7.32" LEGAL_COPYRIGHT="Copyright © 1995-2013 mIRC Co. Ltd." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x24C0D" LINKER_VERSION="0x60000" UPTO_BIN_FILE_VERSION="7.32.0.0" UPTO_BIN_PRODUCT_VERSION="7.32.0.0" LINK_DATE="12/05/2009 22:50:46" UPTO_LINK_DATE="12/05/2009 22:50:46" VER_LANGUAGE="English (United States) [0x409]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="kernel32.dll" SIZE="989696" CHECKSUM="0x7D737C09" BIN_FILE_VERSION="5.1.2600.5512" BIN_PRODUCT_VERSION="5.1.2600.5512" PRODUCT_VERSION="5.1.2600.5512" FILE_DESCRIPTION="Windows NT BASE API Client DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Windows® Operating System" FILE_VERSION="5.1.2600.5512 (xpsp.080413-2111)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xF44A2" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.5512" UPTO_BIN_PRODUCT_VERSION="5.1.2600.5512" LINK_DATE="04/14/2008 00:11:24" UPTO_LINK_DATE="04/14/2008 00:11:24" VER_LANGUAGE="English (United States) [0x409]" />
</EXE>
</DATABASE>
Posted By: Khaled Re: Crash Report analysis please.... - 19/11/13 09:54 PM
The information you have provided is a list of the properties of the mIRC executable, uninstaller and the Windows kernel DLL. Unfortunately this information by itself does not indicate what errors occurred or help in tracking down any issues.

In order to help track down any issues, you would need to provide more information, such as: When does the error occur? Are you able to reproduce it through a series of steps? Are you using any scripts? Do any of them use DLLs? If you install a clean copy of mIRC in an empty folder with no scripts, are you able to reproduce the issue? If you add your scripts back one by one, are you able to pinpoint which one is causing the issue? And so on.
Posted By: Zabache Re: Crash Report analysis please.... - 21/11/13 09:15 AM
thanks for clarifying what information was contained within that crash report. I'd hoped it contained some all knowing keycode or something.

The crash was triggered by a remote script connection I wrote myself. mIRC would only crash when running in concert with a dozen other mircs performing the same task of updating a database. The crash occurred hundreds of times as a result of this function $ini(%hv.fnpl,PL,0) It would appear mirc cannot on windows xp read from files that are currently being read from or written to by other mircs without crashing itself or others in the process, probably due to something outside of your control.

I since consolidated my endeavors into a single multi-socket connection that no longer crashes but, every problem has a solution every solution has a problem, presents a second oddity that seems to be in your neighborhood. No matter how hard i push the now single mirc on my i3-3225 i cannot get a single mirc running my own remote scripts, regardless of priorities set in task manager, to exceed 27% processes used on average. 10 sockets or 30 sockets it seems its total load level is being limited to 27% whereas when i ran a dozen mirc doing the same task i could push it to 95% processes and beyond. IS this an artificial limit? Can something somewhere be changed to make mirc consume 100% of CPU processes available?



P.S. I severely miss the script editor "find text" button. That whole empty space where it once sat should be full of handy buttons. I've never in 10 years used the check brackets button, rather i hit the find text a 100 times a day.
Posted By: Wims Re: Crash Report analysis please.... - 22/11/13 04:58 AM
I can confirm the INI problems, if you run the same mirc.exe like 3 or 4 times and you get them to perfom the same INI operation on the exact same file, it will crash, easily.
Quote:

It would appear mirc cannot on windows xp read from files that are currently being read from or written to by other mircs without crashing itself or others in the process, probably due to something outside of your control.
It does not depend on the OS being used, it's the same on windows 7, and it's due to mIRC doing weird things when it cannot open the file or something.

As far as your cpu goes, keep in mind that if I have 4 cores, one mirc.exe runs only on 1 core, so it would use a maximum of 25%.

Posted By: Zabache Re: Crash Report analysis please.... - 25/11/13 02:13 AM
Thank you, Wims

This answers my wonders, though I think mirc splits its tasks across processors; currently i have but one mirc running with 27% processes used with one thread showing 60% and a second showing 20% on a two core processor. Perhaps you meant as you said cores and not threads.

After removing that offending $ini i was able to reduce the crashes to all but 0, when it found a second seldom used $ini that would interfere when one file was emptied, and being removed to read the next in the list while the mirc above it was for a brief second still reading that file leaving two mirc reading from the same file. I resolved this by moving the two mirc readers three files apart.

Seems room for improvement on both these issues. A 4 core capable mirc that wont crash from the $ini bug.
Posted By: TRT Re: Crash Report analysis please.... - 25/11/13 12:05 PM
What thread runs on which core is up to the OS scheduler. Don't forget mIRC also has to share the load with other applications.

While the crash should be addressed, having multiple mIRC all perform unsynchronized file operations on the same file is hardly efficient and just asking for trouble.
Posted By: Khaled Re: Crash Report analysis please.... - 03/12/13 12:45 PM
Thanks this issue has been fixed for the next version. It occurred in situations were mIRC was trying to access an ini file which was already in use by another application.

Allowing multiple applications to modify the same file simultaneously can cause a file to become corrupted or, at the very least, not contain all of the saved data, so this is usually not a good idea. Normally, the only way to do this reliably is to synchronize access to the file between applications.
Posted By: Wims Re: Crash Report analysis please.... - 06/12/13 01:49 PM
Quote:
Allowing multiple applications to modify the same file simultaneously can cause a file to become corrupted or, at the very least, not contain all of the saved data, so this is usually not a good idea. Normally, the only way to do this reliably is to synchronize access to the file between applications.
True, but this is not really easy with mIRC, how exactly would you suggest one does it?
Posted By: Khaled Re: Crash Report analysis please.... - 06/12/13 07:55 PM
Implementing synchronized resource access can be tricky in any programming language. I am not sure if it is possible using mIRC scripting but perhaps someone else can think of a method. My guess is that you will need to create a DLL that implements an atomic shared resource lock, such as a global mutex.

The tricky part is deciding what the application should do if the resource is currently in use. Should the application freeze until access is granted? Should it store the data elsewhere temporarily and attempt to update the file later? And so on.

It is unlikely that you will be able to use INI files for shared resource access as they were never designed for that.
Posted By: Wims Re: Crash Report analysis please.... - 06/12/13 08:34 PM
Yeah I don't want to use shared ressource access with INI file, I was merely introducing the shared ressource idea using mIRC scripting grin
Without a dll, one could probably achieve something with DDE but DDE isn't really the best way to go about it.
If a dll can be made to allow us to create mutex or similar, it could be implemented in mIRC scripting laugh
Clearly not a priority for you but for the rare time one need that, it would be great to have it, note that one might very well understand the mutex concept while still being unable to create that dll.
Quote:
The tricky part is deciding what the application should do if the resource is currently in use. Should the application freeze until access is granted? Should it store the data elsewhere temporarily and attempt to update the file later? And so on.
As far as mIRC scripters are concerned, that's their problem smile but I'm curious, what was mIRC doing before and what is it doing now? aren't INI file in memory anyway, wasn't the problem just flushing to disk?
Posted By: Khaled Re: Crash Report analysis please.... - 06/12/13 08:57 PM
Quote:
Without a dll, one could probably achieve something with DDE but DDE isn't really the best way to go about it.

DDE would very likely be too slow in most scenarios. A global mutex is probably the best method. An alternative method would be to lock the file for exclusive access (although I am not sure how atomic that is). Currently, /fopen does not support an exclusive access switch. I have added /fopen -x to do this in the next version. If a file is already in use, /fopen -x will fail. This can be used to create generic lock files for shared resource access.

Quote:
As far as mIRC scripters are concerned, that's their problem smile but I'm curious, what was mIRC doing before and what is it doing now? aren't INI file in memory anyway, wasn't the problem just flushing to disk?

If you are referring to the bug reported in this thread, the crash was due to a multi-threading issue when attempting to access a file that was already in use. This is the issue that has been fixed. However the issues related to multiple applications accessing the same INI file simultaneously will still be present.
Posted By: Wims Re: Crash Report analysis please.... - 06/12/13 10:09 PM
Thanks for /fopen -x!
I thought mIRC itself was running one single thread confused

© mIRC Discussion Forums