1. Stefan B Avatar Stefan B
  2. nina
  3. NINA
  4. Issues

Nightly: NINA crashes when monitor is switched off because of crashing QHY driver

Issue #770 resolved
Ruediger created an issue

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

[yes ] Is the issue reproducible?
[ yes, 1.11.46] Are you running the latest version?
[yes ] Are all prerequisites that are mentioned inside the manual met?

Description

When turning off any monitor with a built in USB hub causes NINA to crash silently. It makes no difference whether anything is plugged in into these USB hubs or not. It is sufficient, that these hubs are connected to the computer.
Switching the monitor off, causes a rescan of the USB tree which then leads to crash NINA. There is no entry in the log, but it is attached.

If you disconnect the USB connection between computer and monitor than you can turn off the monitor without crash.

But there is an Event Log entry in Windows Application logfile:

Faulting application name: NINA.exe, version: 1.11.0.1046, time stamp: 0x602300bb
Faulting module name: qhyccd.dll, version: 21.2.1.10, time stamp: 0x601766e7
Exception code: 0xc0000005
Fault offset: 0x00000000001f98dd
Faulting process id: 0x585c
Faulting application start time: 0x01d701e0e9188643
Faulting application path: D:\Programs\Science\NINA\NINA.exe
Faulting module path: D:\Programs\Science\NINA\External\x64\QHYCCD\qhyccd.dll
Report Id: 6d79c44a-bca9-4be9-a32b-b4ec7bfda692
Faulting package full name:
Faulting package-relative application ID:

After renaming the entire QHYCCD folder (so it cannot be found by NINA) the problem is gone.

It looks like the QHY driver crashes when rescanning the USB bus. I have no QHY device at all. So I do not need it.
Probably this will also happen, if you disconnect any other USB hub and trigger a USB tree rescan.

Steps to Reproduce

  • All monitors are switched on and NINA is running
  • Switching off or un-power all monitors cause NINA window to close. No error at all.

This behaviors is 100% reproducible. NINA needs not to be connected to any device. When deleting QHY folder then everything works.

Expected behaviour

NINA continuous running. Older version had not shown the problem. Suppose buggy QHY driver package.

Actual behaviour

NINA window closes instantly. No error shown.

Comments (18)

  3. Stefan B repo owner

    Seems like there is a critical bug inside the QHY SDK unfortunately. I will check how to deal with it. Either by downgrading again or by introducing a temporary toggle to disable the sdk. (until QHY has fixed it)

    ‌

  5. Dale Ghent

    I was able to reproduce this. I’m guessing that the device scanning thread in the QHY SDK is keeping a handle open and a crash happens when the topology of the bus changes. I will let them know. The work-around for now is just delete the qhy sdk folder

  6. Albert Miethaner

    @Dale Ghent also users who have running qhy devices?

    II run qhy163m and cfw3.

    What should I delete exactly?

  7. Stefan B repo owner

    @Albert for now you have to wait for QHY to fix it and/or downgrading back to the released version of NINA. Nightlies are here exactly to identify these kind of issues when we upgrade external stuff and develop new things.

  8. Dale Ghent

    This issue appears to happen when there is a USB hub connected to the system when NINA starts and it has downstream devices connected to it. If the hub is disconnected or is put to sleep by the OS, the topology of the USB bus changes in a way that the SDK does not account for and a crash results. If the hub has not devices connected and it is unplugged/suspended, then no crash occurs. I have sent this info, along with some debugging info from the SDK, to QHY and they are aware of it now.

  9. Chris Turchin

    Additional context on my end: This happened to me last night at 12:43 (latest nightly build). Only I do not have a monitor attached (headless only connecting with RDP) and cannot imagine what on the topology of the USB hub has changed, since I had been asleep (and the RDP session disconnected) for like 3 hours. I had a couple crashes last night when setting up also, when I clicked on slew and center. Now I looking back in the system logs I see it was the same message at 21:08 and 21:23 which I think was the initial crash and me seeing if I could reproduce it. Probably does not matter, but I do not use any QHY hardware.

    Reading Dale’s last comment, I wonder if it is the externally powered USB3 hub I use to connect my devices to. It was COLD last night and maybe that is what was causing the issues.

    ‌

  10. Ruediger reporter

    Hi Chris,

    RDP is changing USB topology since it can / does forward USB devices to the remote client. So depending on how you disconnect the session and it's settings, it could cause this effect.

    After I had deleted the subfolder of the QHY driver, it runs stable. Tonight's session finished as expected.

  11. Chris Turchin

    Thanks Rüdiger, that could also be the case. I was using remmina (xfreerdp) from a pi 4 to connect to my imaging PC last night - that is also a change from my standard process. And thanks for the tip, I think I will bin the QHY folder as an interim solution as well 🙂

  12. Albert Miethaner

    I ve a question (without testing it). If I plug my qhy163m from the usb hub directly to the laptop, should it then run fine?

  15. Ruediger reporter

    No crash during the complete night. For my perspective the issue can be closed.

    @Albert: what about you? Can I close it?

  16. Albert Miethaner

    yes, close it. I ve this “crash” only one time. the 047 i test this night. last night i run 46 without any problems.

  19. Log in to comment
Assignee
–
Type
bug
Priority
blocker
Status
resolved
Component
User Interface
Version
–
Votes
0
Watchers
2
Jira: the preferred issue tracker for Bitbucket. Join the team!