Application_DispatcherUnhandledException

[Ruediger]

For reporting bugs please use the following guideline to describe the problem:

[ X] Is the issue reproducible?
[1.10.RC003 ] Are you running the latest version?
[ yes] Are all prerequisites that are mentioned inside the manual met?

Description

NINA regularly throws an exception and disconnects telescope and ASCOM observing HUB. All other devices like CCD, filter wheel, focuser stay connected and functioning. Manuel reconnect of telescope and ASCOM observing HUB is possible. The telescope is connected via ASCOM and wired via Ethernet (cable) so an USB hick-up can be excluded.

The problem occurred only since the last two or three Beta versions. Before it has been stable.

Steps to Reproduce

• it happens sporadic one or two times per hour. I have not identified any dedicated action to provoke the error.

Expected behaviour

stay connected, No exception.

Actual behaviour

There is a popup saying UnhandledException and the usual “Yes” / “no” dialog.

Logfile attached please also see sniplet below. full log attached.

‌

Thank you in advance!

Ruediger

‌

‌

[2020-07-11T22:59:26.9199] [ERROR] [MemberName] Application_DispatcherUnhandledException
[2020-07-11T22:59:26.9199] [ERROR] [FileName] E:\Projects\nina\NINA\App.xaml.cs
[2020-07-11T22:59:26.9199] [ERROR] [Message] Arithmetic operation resulted in an overflow. at System.Windows.Shell.WindowChromeWorker._HandleNCHitTest(WM uMsg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Shell.WindowChromeWorker._WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Interop.HwndSource.PublicHooksFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

[2020-07-11T22:59:27.0039] [ERROR] [MemberName] Connected
[2020-07-11T22:59:27.0039] [ERROR] [FileName] E:\Projects\nina\NINA\Model\MyTelescope\AscomTelescope.cs
[2020-07-11T22:59:27.0039] [ERROR] [Message] An outgoing call cannot be made since the application is dispatching an input-synchronous call. (Exception from HRESULT: 0x8001010D (RPC_E_CANTCALLOUT_ININPUTSYNCCALL)) at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 350
at ASCOM.DriverAccess.AscomDriver.set_Connected(Boolean value) in C:\ASCOM Build\Export\ASCOM.DriverAccess\AscomDriver.cs:line 146
at NINA.Model.MyTelescope.AscomTelescope.set_Connected(Boolean value)

[Ruediger]

Please find also the profile attached

[Stefan B]

Hi,

from what i can grab inside the log files, this looks like some driver issue.Furthermore you are using a release candidate of the ASCOM platform (6.5) and no official release, and i have already heard of issues with that version. So this might be related.

Can you check if that problem persists with a downgrade to the ASCOM platform 6.4?

[Ruediger]

Hi Stefan,

Downgrading is currently not possible, since ALPACA / Remote ASCOM requires ASCOM 6.5 and I have to use other SW which only uses ALPACA and a parallel install of both ASCOM is not possible.

But the older betas / nightly were running without any issue with ASCOM 6.5 for months. This problem occurred only a few version back.

[Ruediger]

Hi Stefan,

ASCOM 6.5 was officially released today. It is no RC anymore. So the issue needs to be addressed.

Thank you!

CS

Rüdiger

‌

[Stefan B]

The problem still resides inside the ascom driver, as you can see inside the call stack. there is not much we can do about that, as this seems to be a driver problem.

[Ruediger]

The ASCOM driver did not change for months. The mount driver runs stable and 100% reliable with other software in many installations. The problem started a few versions back of NINA. With the older NINA Nightlies the driver was also stable.
So have some doubts that it is related to the mount’s ASCOM driver.

[Stefan B]

The last change to the ASCOMTelescope class in NINA was in February and not related to the part the stack trace is pointing at.

Furthermore the AscomTelescope and AscomObservingCondition fail at the exact same point in time in your log which sounds like it is happening inside ASCOM as the telescope and weather data stuff is not related in any way in nina and decoupled.
Without a clear way to reproduce this issue, it is impossible to find any root cause this way.

[Ruediger]

One question: I see the line “E:\Projects\nina\NINA\App.xaml.cs” which does not exist on my system. Is this ok?
Do I have any chance to drill down, which is the trouble maker?

‌

[Ruediger]

I have reported and sent link of this issue to 10 Micron support. I will report back.