$com call crashing mirc - mIRC Discussion Forums

Code:

alias comtest {
  .comopen a MSScriptControl.ScriptControl
  if (!$comerr) {
    var %vb set s = createobject("Shell.Application") $lf set f = s.namespace( $qt($1) ).items $lf s.namespace( $qt($2) ).copyhere(f)
    if ($com(a,Language,4,bstr,VBScript)) && (!$comerr) {
      echo -a $v1 -- $com(a,ExecuteStatement,1,bstr,%vb) -- $comerr
      .comclose a 
    }
  }
}

The following code create a little vb script to extract files from a zip file. To use it:
//noop $comtest(C:\file.zip,path\to)
This extract files from C:\file.zip to path\to. Both parameters must be complete filename/path.

I use a zip file with only one .txt file in it and pretty much everytime, if mIRC doesn't crash right after, you get this:

Quote:

1 -- -- 0
* No such Com 'a' open (line 20, script10.mrc)

Although the operation was successful, files have been extracted.

Now this leaves mIRC in a quite unstable state, mIRC will crash soon after using that alias, reusing that alias usually results in the crash being there faster, but it's not required to get the crash.

I'm using mIRC 7.29 and Windows 7.

Is this a direct consequences of mIRC's implementation of com object?

Could this be because you're not freeing the memory used by the 'set' keyword in the vbscript? If you do a 'set f = nothing' afterwards does that solve the problem?

No, it doesn't.
I don't know if it's related to the vb script, but usually when the script is wrong, $com return 0.
Also:

Quote:

* No such Com 'a' open (line 20, script10.mrc)

Line 20 is the /comclose a command.

Thanks for your bug report, unfortunately I have not been able to reproduce this issue. I tested your script under Windows 7 using mIRC v6.35, v7.29 and a debug beta. All three versions of mIRC return the result "1 -- 1 -- 0", regardless of how many times I run the script. I experience no crashes while running or when exiting mIRC.

If you use /comopen and then immediately /comclose and exit, do you see the same issue? How about if you /comclose and exit immediately after the first $com()?

Are you using the built-in Windows 7 zip support? Or have you installed a file archiver such as 7-zip or Winzip?

I rarely got "1 -- 1 -- 0" but it happened.
I never tried exiting mIRC, the crash always occured before I could have a chance to (but I wouldn't have tried anyway, to be honnest).

Quote:

If you use /comopen and then immediately /comclose and exit, do you see the same issue?

I don't know if you meant using /exit or not but using this code:

Code:

alias comtest {
  .comopen a MSScriptControl.ScriptControl
  .comclose a
  exit -nr
  if (!$comerr) {
    var %vb set s = createobject("Shell.Application") $lf set f = s.namespace( $qt($1) ).items $lf s.namespace( $qt($2) ).copyhere(f) $lf set f = nothing
    if ($com(a,Language,4,bstr,VBScript)) && (!$comerr) {
      echo -a $v1 -- $com(a,ExecuteStatement,1,bstr,%vb) -- $comerr
      .comclose a 
    }
  }
}

First, I didn't know /exit wasn't halting the current script, is this intended? Anyway, that code works fine, the first $com call produce an error since com 'a' doesn't exist (has been closed) and mIRC exits (and restarts).

Quote:

How about if you /comclose and exit immediately after the first $com()

Now using this code:

Code:

alias comtest {
  .comopen a MSScriptControl.ScriptControl
  if (!$comerr) {
    var %vb set s = createobject("Shell.Application") $lf set f = s.namespace( $qt($1) ).items $lf s.namespace( $qt($2) ).copyhere(f) $lf set f = nothing
    if ($com(a,Language,4,bstr,VBScript)) && (!$comerr) {
      .comclose a
      exit -nr
      echo -a $v1 -- $com(a,ExecuteStatement,1,bstr,%vb) -- $comerr
    }
  }
}

Also works as expected, an error on the second $com call and mirc restarts.

I use winrar as a file archiver

Thanks, unfortunately I have still not been able to reproduce the issue. I also tried testing your script under Windows XP, with different versions of mIRC, and they all returned "1 -- 1 -- 0".

I also installed WinRAR, as well as other archivers, with no difference to the result. It looks the type of archiver is not relevant in this case - the $com() call seems to be calling the Windows built-in zip support.

It may be that there is an issue with your Windows built-in zip configuration that is causing the issue. Other than that, I am not sure what else to suggest without being able to reproduce it myself.

Yeah well, I'll try to investigate this myself, I'll try to see if people can reproduce it.
It would be great if users looking at this post could try the (original) script and gives feedbacks if they can reproduce the issue or not.

wims, per your request..

I ran this on current mIRC, with no other scripts loaded (i keep a mirc_clean directory just for this use) and my results:

1 -- 0 -- 1
1 -- 0 -- 1
1 -- 0 -- 1
1 -- 0 -- 1
1 -- 0 -- 1
1 -- 0 -- 1

If I can do more to help you or Khaled with other testing let me know..

my system: windows xp sp2 with all current fixes applied.
Did NOT run this on a secure connection (to dalnet, where i tested) but if that is needed. let me know..

Tried several times on both XP(sp3) and Win 7 (sp1). No crashes, results the same on both...

Zipfiles contain...

Single files
1 -- 1 -- 0

Multiple files; single directory
1 -- 1 -- 0

Multiple files; multiple directories
1 -- 1 -- 0

Tried also with a mix of zips in a while loop, same result.

Originally Posted By: Wims

First, I didn't know /exit wasn't halting the current script, is this intended?

Khaled can probably affirm, but I imagine mIRC is just calling PostQuitMessage here, which means your script has to finish executing for mIRC to go back to the run loop and start the process of exiting the application. In other words, yes, it is intended for exit to not halt your script. You'd want to exit AND halt/return. It would be weird if exit did halt execution, since it's a command, not a control flow keyword like halt or return. The latter two keywords should really be the only way to prematurely end execution of a script.

I finally took the time to investigate this to realize I had a timer running each 5 secs, retrieving the ram usage with COMs, one of the COM name used was 'a'. I'll try to give steps using that specific situation.

Figured it out:

Code:

alias comtest {
  .comopen a MSScriptControl.ScriptControl
  if (!$comerr) && ($com(a,Language,4,bstr,VBScript)) && (!$comerr) {
    noop $com(a,ExecuteStatement,1,bstr,MsgBox(Now))
    if ($com(a)) && (!$comerr)  .comclose a
  }
}

execute the alias and once the window is opened, go back to mirc and type /comclose a, close the window and repeat, mirc should crash.

Thanks for looking into it. The reason this is happening is that you created a COM object and then closed it while it was still in use by MSScriptControl.ScriptControl. This causes MSScriptControl.ScriptControl to attempt to modify/free memory, allocated by mIRC, that no longer exists, corrupting mIRC's memory pool.

One way around this would be for mIRC to prevent you from using /comclose on an active COM connection. However, users have in the past asked to be able to /comclose an active connection. Whether this causes an issue depends on the COM object. It is up to the scripter to determine whether this is something that can be done with the COM object that they are using.

I agree with this, I reported the problem just in case.
A lot of questions/reports are asked/made about mirc/msl because we have no way to know if the behavior is intended than to hear it from you (or others trusted source but ultimately you).
For example there could be a note in the help file about /comclose saying that we are allowed to comclose at anytime, but that depending on the object and how it is used, the result is undefined behavior or may result in a crash.