|
|
|
|
|
|
RRX
|
|
RRX
|
Since I use 6.21 (but it may be not related since I work further on this script from time to time), mIRC sometimes suddenly hangs without apparent reason. It takes all CPU it can get, doesnt update its windows anymore, and pingouts on all connections.
Two days ago I used a tool (TCPview from SysInternals) to kill all the connections mIRC had to IRC servers, and mIRC started to respond, but only for a dozen seconds and not swift, and I was again forced to kill the process.
This morning it happened again and I used Process Explorer to save the process information.
The mIRC process had 902 threads. The situation was 11 irc server connections and low script load (due to not much IRC activity).
I assume this isn't a bug in mIRC but something in my script. It's a rather big one so I'm not sure how to track this down.
It's probably caused by an execution path that gets stuck in a loop.
The problem is, I have no idea where to start. Adding filelog writes to every alias and digging through the logs (of ex like 2 days between two 'hangs') would be a giant job.
Maybe someone has an idea on how to cope with this?
This is the log Process Explorer wrote:
Process PID CPU Description Company Name
Idle 0x0 System Idle Process
SNDVOL32.EXE 0xFFFA7BB7
DDHELP.EXE 0xFFFA22FF Microsoft DirectX Helper Microsoft Corporation
KERNEL32.DLL 0xFFCF36C7
MSGSRV32.EXE 0xFFFF60DB
SPOOL32.EXE 0xFFFF68C3 Spooler Sub System Process Microsoft Corporation
MPREXE.EXE 0xFFFF48F7 WIN32 Network Interface Service Process Microsoft Corporation
TABLET.EXE 0xFFFFF8A3 WacomService Wacom Technology, Corp.
PERSFW.EXE 0xFFFFB157 Tiny Personal Firewall Engine Tiny Software
mmtask.tsk 0xFFFF4177 Multimedia background task support module Microsoft Corporation
EXPLORER.EXE 0xFFFE36B3
TASKMON.EXE 0xFFFEF453 Task Monitor Microsoft Corporation
SYSTRAY.EXE 0xFFFEECEB
PDESK.EXE 0xFFFEDDF7 PDesk Matrox Graphics Inc.
MIRC621.EXE 0xFFFE9A5B 54 mIRC mIRC Co. Ltd.
DSCLOCK.EXE 0xFFFE41AF DS Clock Duality Software
TABUSERW.EXE 0xFFFD45AB TABUSERW Wacom Technology, Corp.
MISITRAY.EXE 0xFFFD32FB miroVIDEO Tray Application Pinnacle Systems
misiCTRL.EXE 0xFFFD0123 miroVIDEO DCxx Playback Control Utility Pinnacle Systems GmbH
INCD.EXE 0xFFFD050F InCD Nero AG
VIRTUALDUB.EXE 0xFFFBC16F VirtualDub
PROCEXP.EXE 0xFFF8EF57 46 Sysinternals Process Explorer Sysinternals
VIRTUALDUB.EXE 0xF640C763 VirtualDub
Process: MIRC621.EXE Pid: FFFE9A5B
Type Name
Device VNETBIO
Device WSOCK2
Event WacomNewFrontAppEventName
File C:\WIN98\SYSTEM\SHDOCVW.DLL
File D:\TEMP\IEXPLO~1\INDEX.DAT
File C:\WIN98\COOKIES\INDEX.DAT
File C:\WIN98\GESCHI~1\INDEX.DAT
File C:\WIN98\SYSTEM\STDOLE2.TLB
MappedFile D:_TEMP_IExplorer_index.dat_65536
MappedFile C:_WIN98_Cookies_index.dat_16384
MappedFile C:_WIN98_Geschiedenis_index.dat_81920
MappedFile fileAllocatorMutex
MappedFile DCOMSharedGlobals12321
MappedFile fileAllocatorMutex
MappedFile rpcrt4sharedmem
MappedFile mIRC
MappedFile mIRC
Mutex WininetStartupMutex
Mutex MPRMutex
Mutex OLESCMLOCKMUTEX
Mutex _!MSFTHISTORY!_
Mutex d:!temp!iexplorer!
Mutex c:!win98!cookies!
Mutex c:!win98!geschiedenis!
Mutex OleCoSharedStateMtx
Mutex OLESCMSRVREGLISTMUTEX
Mutex OLESCMGETHANDLEMUTEX
Mutex OLESCMROTMUTEX
Mutex OleDfSharedMemoryMutex
Mutex ScmWIPMutex
Mutex WacomTouchingAppNameMutexName
Mutex Winsock2ProtocolCatalogMutex
Mutex Winsock2ProtocolCatalogMutex
Mutex ObjectResolverGlobalMutex
Mutex Microsoft RPC UUID Mutex
Mutex Autodial
Process MIRC621.EXE(FFFE9A5B)
Semaphore DocfileAllocatorMutex
Semaphore DocfileAllocatorMutex
Thread MIRC621.EXE(FFFE9A5B): FFFCEA97
Thread MIRC621.EXE(FFFE9A5B): FFF0CE23
Thread MIRC621.EXE(FFFE9A5B): FFFEE717
Thread MIRC621.EXE(FFFE9A5B): FFFCFA5B
Thread MIRC621.EXE(FFFE9A5B): FFFEE467
Thread MIRC621.EXE(FFFE9A5B): FFFCF53F
Thread MIRC621.EXE(FFFE9A5B): FFFCFFB3
Thread MIRC621.EXE(FFFE9A5B): FFFAFF97
Thread MIRC621.EXE(FFFE9A5B): FFFCFD8F
Thread MIRC621.EXE(FFFE9A5B): FFFCF837
Thread MIRC621.EXE(FFFE9A5B): FFFCC2AB
Thread MIRC621.EXE(FFFE9A5B): FFFCC603
Thread MIRC621.EXE(FFFE9A5B): FFFCC4DF
Thread MIRC621.EXE(FFFE9A5B): FFFCC087
[snipped]
|
|
|
|
|
Joined: Jan 2007
Posts: 259
Fjord artisan
|
Fjord artisan
Joined: Jan 2007
Posts: 259 |
My suggestion would be to debug your script. Generally, if mIRC crashes/etc, its a DLL. Here are some hints on how to debug your script: Add this to everyplace where you loop, call a DLL, deal with big files, etc.
if (%debug) {
_debug $+([,$script,:,$scriptline,]) $+(%,var) = xxx
...
}
And an alias:
alias _debug {
if (!$window(@debug)) {
window -e @debug
}
echo @debug $timestamp $1-
}
This way you can just to /set %debug 1 and it does. You can also do "_debug Matching wildcards.." "_debug $v1 iswm $v2 $+ : True/False" "_debug Done matching wildcards." to make it easier to debug. Make it easy to read the code, use ()s in if statements, and {}s after statements.
|
|
|
|
|
|
RRX
|
|
RRX
|
My suggestion would be to debug your script. Generally, if mIRC crashes/etc, its a DLL. Here are some hints on how to debug your script: Add this to everyplace where you loop, call a DLL, deal with big files, etc.
if (%debug) {
_debug $+([,$script,:,$scriptline,]) $+(%,var) = xxx
...
}
And an alias:
alias _debug {
if (!$window(@debug)) {
window -e @debug
}
echo @debug $timestamp $1-
}
This way you can just to /set %debug 1 and it does. You can also do "_debug Matching wildcards.." "_debug $v1 iswm $v2 $+ : True/False" "_debug Done matching wildcards." to make it easier to debug. Make it easy to read the code, use ()s in if statements, and {}s after statements. If it was a loop in one alias or event, control break would stop it. Since it doesnt, it must be some loop across aliases. Alias 1 calling alias 2, which calls alias 1 again, maybe alot more script pieces along what I called 'execution path'. So putting something 'everywhere I loop' isn't relevant in this situation, it's likely a loop that isn't ment to loop. It occurs sometimes and I have no single clue regarding the circumstances. The script reports already alot, but only for the higher-level stuff and somewhat more in case failures. But when I check the scripts logs, there's just nothing on that level. For example, I log whois results which are triggered by join, parts etc, there is nothing. Adding debug echoes all over the place is like a last option for me, the thing is over 17000 lines and like 500 aliases. I was hoping the process info, the addresses, were giving a clue on where to start searching. What all causes a new thread in mIRC?
|
|
|
|
|
Joined: Jan 2007
Posts: 259
Fjord artisan
|
|
Fjord artisan
Joined: Jan 2007
Posts: 259 |
I would suppose a new thread would be called by timers, COM objects, /run commands. However, I'm not sure if this is correct.
But I would recommend implementing my suggestion into your script.
It will help you now, and It will help you again if there is another error.
Another option would be to make a temporary hash table, and use error catching to dump the hash table to a file, and halting the script. If no errors or anything happen, It would just free the hash table and make it once a alias/etc is called again.
|
|
|
|
|
Joined: Oct 2004
Posts: 8,061
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2004
Posts: 8,061 |
I don't know anything about those sort of application error dumps, so can't really help you based on that. However, I'll just mention that some infinite loops can be cancelled by *holding* control-break for up to 5 seconds rather than just hitting it once. This will do a repeat of Ctrl-Break and often that's enough to break out of a loop that doesn't want to cancel. That doesn't help you with the problem unless it shows an appropriate line number, but it at least breaks you out of the problem without restarting mIRC.
The best method, imo, is to keep track of exactly *when* it hangs. What's going on? Use that to try and track the cause.
|
|
|
|
|
|
|
|
|
