When debugging my Embedded system which outputs a debug log, I get this:
An unhandled asynchronous non-synchronized 'TargetInvocationException' occurred while running YAT.
YAT with Mono/Linux 2.8.0
@ 13:41:08.826 @ 0001 : Exception (written by .ctor at D:\Workspace\YAT\Trunk\YAT\YATApp\YAT.View.Forms\UnhandledException.cs line 76)
Exception:
Type: System.Reflection.TargetInvocationException
Message:
Exception has been thrown by the target of an invocation.
Source: mscorlib
Stack:
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Delegate.DynamicInvokeImpl(Object[] args)
at YAT.SystemEx.EventHelper.Item.InvokeOnCurrentThread(Delegate sink, Object[] args)
at YAT.SystemEx.EventHelper.Item.RaiseSync(Delegate eventDelegate, Object[] args)
at YAT.IO.Serial.SerialPort.SerialPort.OnDataReceived(DataReceivedEventArgs e)
at YAT.IO.Serial.SerialPort.SerialPort.ReceiveThread()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
Inner exception level 1:
Type: System.Reflection.TargetInvocationException
Message:
Exception has been thrown by the target of an invocation.
Source: mscorlib
Stack:
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Delegate.DynamicInvokeImpl(Object[] args)
at YAT.SystemEx.EventHelper.Item.InvokeOnCurrentThread(Delegate sink, Object[] args)
at YAT.SystemEx.EventHelper.Item.RaiseSync(Delegate eventDelegate, Object[] args)
at YAT.Domain.RawTerminal.OnChunkReceived(EventArgs`1 e)
at YAT.Domain.RawTerminal._io_DataReceived(Object sender, DataReceivedEventArgs e)
Inner exception level 2:
Type: System.ArgumentException
Message:
The output char buffer is too small to contain the decoded characters, encoding 'Unicode (UTF-8)' fallback 'System.Text.DecoderReplacementFallback'.
Parameter name: chars
Source: mscorlib
Stack:
at System.Text.Encoding.ThrowCharsOverflow()
at System.Text.Encoding.ThrowCharsOverflow(DecoderNLS decoder, Boolean nothingDecoded)
at System.Text.UTF8Encoding.GetChars(Byte* bytes, Int32 byteCount, Char* chars, Int32 charCount, DecoderNLS baseDecoder)
at System.Text.DecoderNLS.GetChars(Byte[] bytes, Int32 byteIndex, Int32 byteCount, Char[] chars, Int32 charIndex, Boolean flush)
at System.Text.DecoderNLS.GetChars(Byte[] bytes, Int32 byteIndex, Int32 byteCount, Char[] chars, Int32 charIndex)
at YAT.Domain.TextTerminal.MultiByteToElement(RepositoryType repositoryType, Byte b, DateTime ts, String dev, IODirection dir, Radix r, Int32& code, Boolean& requiresDataSeparator, Boolean useGeneric)
at YAT.Domain.TextTerminal.ByteToElement(RepositoryType repositoryType, Byte b, DateTime ts, String dev, IODirection dir, Radix r, Int32& code, Boolean& requiresDataSeparator, Boolean useGeneric)
at YAT.Domain.Terminal.ByteToElement(RepositoryType repositoryType, Byte b, DateTime ts, String dev, IODirection dir, Int32& code, Boolean& requiresDataSeparator, Boolean useGeneric)
at YAT.Domain.TextTerminal.DoLineContent(RepositoryType repositoryType, ProcessState processState, Byte b, DateTime ts, String dev, IODirection dir, DisplayElementCollection& elementsToAdd, Boolean& replaceLine, Boolean& overwriteIsTriggered, DisplayElementCollection& elementsToAddAfterOverwrite)
at YAT.Domain.TextTerminal.ProcessByteOfChunk(RepositoryType repositoryType, Byte b, DateTime ts, String dev, IODirection dir, Boolean isFirstByteOfChunk, Boolean isLastByteOfChunk, DisplayElementCollection& elementsToAdd, DisplayLineCollection& linesToNotify, DisplayElementCollection& elementsToAddAfterOverwrite, Boolean& breakChunk)
at YAT.Domain.Terminal.ProcessAndSignalChunkContent(RepositoryType repositoryType, RawElement re, Int32& byteCountProcessed)
at YAT.Domain.Terminal.ProcessChunk(RepositoryType repositoryType, RawElement re, PostponeResult& postponeResult)
at YAT.Domain.Terminal.ProcessRawElement(RepositoryType repositoryType, RawElement re)
at YAT.Domain.Terminal.ProcessRawElement(RawElement re)
at YAT.Domain.Terminal._rawTerminal_ChunkReceived(Object sender, EventArgs`1 e)
Also, this pops up the "After the unhandled exception YAT will have to exit. Would you like to restart YAT after exit?" Which I click on "Yes" and that dialog closes, but nothing happens. Yat doesn't close. When I close it (using right click on icon and "Close window"), it closes. When I reopen, the com port reports: "COM3 - Closed - Waiting for reconnect". If I unplug the Usb serial adapter and rescan, then plug it back in, it seems to work again.
Last edit: Mark Stokes 2026-06-18
Hi Mark, thanks for reporting! Do you have any idea on what data triggered the issue? Is it a
TextorBinaryterminal? IfText, what isTerminal > Settings... > Text... > Encoding? I am asking because of the error message:I have never seen such an error. However, I indeed did some refactoring in decoding, so there is potential for this being a regression.
Any additional input is appreciated, Matthias
PS: For the temporarily broken device, this likely is cause by this known issue (see limitations):
Last edit: Maettu 2026-06-18
Diff:
Sure. Essentially the data starts out as straight ascii, but then eventually starts sending SLIP encoded hexadecimal. The log file has some garbage in it (likely slip encoded hex), but unfortunately it's proprietary and likely I can't send it to you. But I can tell you it's full of a ton of <nul> and just garbage before it crashes.
Here's the last line from the captured log file:
(13:41:00.986) <stx><nul><nul><nul><nul><eot><nul><eot><nul><nul><nul><nul><nul>?钤???ő<nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><bel><nul><dc3 xoff=""><nul><vt><stx><nul><nul><nul><nul><eot><nul><dle><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><dc3 xoff=""><nul><ff><stx><nul><nul><nul><nul><fs><nul><eot><nul>???<si><dc3 xoff=""><nul><cr><stx><nul><nul><nul><nul><fs><nul><eot><nul><nul><nul><nul><nul><dc3 xoff=""><nul><so><stx><nul><nul><nul><nul><si><nul><<nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><dc3 xoff=""><nul><si><stx><nul><nul><nul><nul><soh><nul><eot><nul><nul><nul><nul><nul><dc3 xoff=""><nul><dle><stx><nul><nul><nul><nul><soh><nul><soh><nul><nul><dc3 xoff=""><nul><dc1 xon=""><stx><nul><nul><nul><nul><soh><nul><eot><nul><stx><nul><nul><nul>6?????<nul>?<nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><nul><dc3 xoff=""><nul><dc2><stx><nul><nul><nul><nul><soh><nul><eot><nul><nul><nul><nul> (259)
I did set the list max to 100 lines and 10000 characters to try to "fix" it (or get past it), but this didn't help. I also set the input buffer to 65536 assuming something was too fast or overrunning a buffer. Also, no help. I also tried the break after 256 characters (you can see the (259) part at the end of the line). I also tried just "discard invalid bytes" and this didn't make any difference.</nul></nul></nul></nul></eot></nul></soh></nul></nul></nul></nul></stx></dc2></nul></dc3></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></stx></nul></eot></nul></soh></nul></nul></nul></nul></stx></dc1></nul></dc3></nul></nul></soh></nul></soh></nul></nul></nul></nul></stx></dle></nul></dc3></nul></nul></nul></nul></nul></eot></nul></soh></nul></nul></nul></nul></stx></si></nul></dc3></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></si></nul></nul></nul></nul></stx></so></nul></dc3></nul></nul></nul></nul></nul></eot></nul></fs></nul></nul></nul></nul></stx></cr></nul></dc3></si></nul></eot></nul></fs></nul></nul></nul></nul></stx></ff></nul></dc3></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></dle></nul></eot></nul></nul></nul></nul></stx></vt></nul></dc3></nul></bel></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></nul></eot></nul></eot></nul></nul></nul></nul></stx></nul>
Ok, I was able to capture the data w/ TeraTerm. I'll have to evaluate to derermine what was sent.
Alright, these pieces of information already help:
?钤???,???,6?????Two options:
Terminal > Settings... > Text... > EncodingtoASCIITerminal > Settings... > Terminal TypetoBinaryStill, I'd be interested in the very sequence of bytes that cause the exception. YAT should be able to detect the mismatching encoding and give a comprehensive error message, like seen in this test. Apparently that is not the case for the situation you face. Having the bytes, I should be able to reproduce the issue. You may also send the capture to the e-mail stated in
Help > About, then the data doesn't get public here.PS: The SLIP control chars alone are correctly handled, no matter how many of them I send:
Last edit: Maettu 2026-06-19
Fixed with r7136 by additionally handling
ArgumentException.However, I was not able to reproduce the exception so far. @markstokes71, I'd still appreciate a condensed chunk of data that lets me reproduce the exception, in order to better understand how this situation can happen. As visible from the referred piece of source code, YAT 2.8.0 actually already considered
var chars = new char[origin.Count];being the worst-case situtation, i.e. theArgumentExceptionwas not expected to happen. Apparently, that assessment was a wrong and I would like to understand why.Leaving this ticket open so others can see it until the upcoming YAT 2.8.1 release.
@markstokes71, I think I now know how this bug can be reproduced with revealing just a couple of bytes of data:
Terminal > Settings... > Text... > Encoding=Unicode UTF-8.Terminal > Settings... > Text... > Encoding > Behavior on decoding mismatch=Comprehensive warning.r7136/r7140 will then state all pieces that cannot be handled by the UTF-8 encoding, including the bytes involved.
Last edit: Maettu 2026-07-12
YAT 2.8.1 fixing this issue has been released.