VAD TargetInvocationException on DefaultDisconnectHandler

[comnia]

Hello,

we have a slightly complex VAD-Flow that seems to fail only in one particular case... So here is the Scenario first.

The Mainflow starts by directly doing an external Code execution.
After that it goes into an conditional branch. In this conditional branch there is another one which selects and executes an specific audio playback.
Afterwards there is another conditional branch with an input branch with an additional audio playback and a voice recorder in it (only if the caller presses 1...).
Right after that its going to the Default Disconnected Handler.
At the Disconnected Handler there are is another external code execution (and it usually works, too).
The flow sucessfully stops with an email to be sent.

Everything in this flow works fine, excepted if the caller hangs up at one of the playbacks or voice-record.
I get some errors out of a log file located at: c:\ProgramData\3CX\Data\Http\Interface\ivr\<vadname>\Errors_ExternalCodeExecution.txt
The Error is as attached in the end of the post (its originally in german so feel free to contact me for any particular translationquestions)

The point is that it looks like an error thrown by the VAD itsself.
Furthermore the IIS-Appserver creates an intsance of the ExternalCodeExec dll but does not free it!
If the Caller hangs up the call due the first seconds of a voice record the same happens to the recorded file (the IIS doesnt free the file after the error happened...)

Any suggestions for this weird error?

2015-01-26 18:02:00.929
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.ArgumentNullException: Der Wert darf nicht NULL sein.
Parametername: source
bei System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)
bei ComniaExtension.DIDInfo.GetOriginalCalledDID(String ani, String dnis)
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
bei System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
bei ASP.<vadname>_callflow_dh_getoriginalcalleddid_doit_aspx.Page_Load(Object sender, EventArgs e) in c:\ProgramData\3CX\Data\Http\Interface\ivr\<vadname>\Callflow_DH_GetOriginalCalledDid_DoIt.aspx:Zeile 77.

getoriginalcalleddid is the name of the external code execution module in the default disconnected handler.

With regards

Marcel Köberl
Comnia GmbH

 

[VAD_Support]

Re: VAD TargetInvocationException on DefaultDisconnectHandle

Hi Marcel,

If you look at the first part of the exception:
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.ArgumentNullException: Der Wert darf nicht NULL sein.
Parametername: source
bei System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)

You will note that the root cause is the ArgumentNullException, complaining that the "source" parameter is null. That means that the method in your DLL:
ComniaExtension.DIDInfo.GetOriginalCalledDID(String ani, String dnis)

is sending NULL as parameter in the Linq expression.

So, you need to look in your voice app and check why the parameter you're sending in that case is null.

Please check that and let me know if you need further assistance.

Kind regards.

 

[comnia]

Re: VAD TargetInvocationException on DefaultDisconnectHandle

Hello,

oh I thought that those .dll files are only written on VAD-internal errors :roll:
So there was an error in my Code. And I was able to fix it after writing a test for it.

After testing, everything looked great... I was not able to reproduce the problem. All .dll files are freed after a caller hungs up.
Thanks for that one!

But the IIS still holds a handle on the .dll file (and keeps instanciating new versions from time by time) when for example sending an email does not work.
Is this only happening on our particular "VAD-version to callflow" constelation or default behavior? (using the send mail component in default disconnected handler)

Best wishes!

 

[VAD_Support]

Re: VAD TargetInvocationException on DefaultDisconnectHandle

Hi Marcel,

The Web Server (IIS or Abyss) needs to load to memory the DLL you create. That DLL will be kept in memory and can't be replaced by re-deploying. In order to replace them, you need to restart the web server, so it frees the DLLs, and then deploy before making any call to the callflow.

That's standard for .NET processes, the DLL can't be unloaded from an application domain. So that's the way you need to work. Anyway, this will just bother you during development, once the application is live and running, you will not be updating the DLL.

Kind regards.