PHD2 shutting down for unknown reason..

[BendGrampie]

I've seen this 3-4 times in the last couple weeks using NINA.

The end of the Debug Log is here...

00:54:28.914 00.000 9040 GuideAlgorithmLowpass2::Result() returns 0.00 from input -0.03, slope = 0.00
00:54:28.914 00.000 9040 GuideAlgorithmLowpass2::Result() returns 0.00 from input -0.02, slope = 0.02
00:54:28.914 00.000 9040 MoveAxis(E, 0, ABG)
00:54:28.914 00.000 9040 Move returns status 0, amount 0
00:54:28.914 00.000 9040 MoveAxis(N, 0, ABG)
00:54:28.914 00.000 9040 Move returns status 0, amount 0
00:54:28.914 00.000 9040 move complete, result=0
00:54:28.914 00.000 9040 worker thread done servicing request
00:54:28.924 00.010 12692 UpdateImageDisplay: Size=(1936,1216) min=0, max=256, med=3, FiltMin=1, FiltMax=255, Gamma=1.000
00:54:28.926 00.002 12692 UpdateGuideState exits: m=1560 SNR=27.8
00:54:28.929 00.003 12692 OnExposeComplete: CaptureActive=1 m_continueCapturing=1
00:54:28.931 00.002 12692 ScheduleExposure(3000,3,1) exposurePending=0
00:54:28.933 00.002 12692 Enqueuing Expose request
00:54:28.935 00.002 9040 Worker thread wakes up
00:54:28.935 00.000 12692 GuideStep: -0.0 px 0 ms EAST, -0.0 px 0 ms NORTH
00:54:28.940 00.005 9040 worker thread servicing REQUEST_EXPOSE 3000
00:54:28.940 00.000 9040 Handling exposure in thread, d=3000 o=3 r=(427,520,31,31)
00:54:29.968 01.028 12692 GetBoolean("/Confirm/quit_when_looping_ok", 0) returns 1
00:54:29.971 00.003 12692 MyFrame::OnClose proceeding
00:54:29.977 00.006 12692 StopCapturing CaptureActive=1 continueCapturing=1 exposurePending=1
00:54:29.980 00.003 12692 Status Line: Waiting for devices...
00:54:29.987 00.007 12692 StopWorkerThread(0x01A0D660) begins
00:54:30.038 00.051 9040 ZWO: stopexposure
00:54:30.993 00.955 12692 StopWorkerThread(0x01A0D660) thread did not terminate, force kill
00:54:30.996 00.003 12692 StopWorkerThread(0x01A0D660) ends
00:54:30.999 00.003 12692 WorkerThread destructor called
00:54:31.002 00.003 12692 StopWorkerThread(0x019AA2F8) begins
00:54:31.016 00.014 5336 Worker thread wakes up
00:54:31.016 00.000 5336 worker thread servicing REQUEST_TERMINATE
00:54:31.016 00.000 5336 worker thread done servicing request
00:54:31.016 00.000 5336 WorkerThread::Entry() ends
00:54:31.021 00.005 12692 StopWorkerThread() threadExitCode=0
00:54:31.038 00.017 12692 StopWorkerThread(0x019AA2F8) ends
00:54:31.042 00.004 12692 WorkerThread destructor called
00:54:31.048 00.006 12692 Shutdown: forced=1
00:54:31.052 00.004 12692 Shutdown complete
00:54:31.064 00.012 12692 UPD: shutdown
00:54:31.068 00.004 12692 stopping server
00:54:31.073 00.005 12692 event server stopped
00:54:31.077 00.004 12692 Status Line: Server stopped

Thanks.

Marc

[Brian Valente]

Marc

Please use the log uploader and send the entire logs

https://openphdguiding.org/getting-help/

Thanks

Brian

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/428a3cad-1306-4175-9b8c-34e2f1bdbab8n%40googlegroups.com.

--

Brian 

Brian Valente

astronomy portfolio https://www.astrobin.com/users/bvalente/ 

[BendGrampie]

https://openphdguiding.org/logs/dl/PHD2_logs_GEsw.zip

[Bruce Waddington]

The log shows the exact pattern of responding to a Windows close message.  This happens if you click on the 'Close' icon in the upper right part of the main window frame or if PHD2 is told to close by some other running application or by the OS.  It isn't happening because of any sort of internal action in PHD2 or by an unexpected error condition.  It happened at 00:54 so I don't know if you were present or not -  it was about 48 minutes before meridian cross-over.  Certainly we've all experienced situations in the middle of the night when we are fumbling around on the keypad or with the mouse.  If you're running remotely, it's a good practice to leave the mouse outside the display area that has active windows.   I think it's highly unlikely that NINA triggered this so it's probably something else.  Were any other applications shut down automatically, for example as part of a Windows update?  There's really no way for us to back-track where this is coming from, the Windows Close message just arrives asynchronously.    Needless to say, no one else has reported this and many of us are running automated imaging sessions every clear night.  

Sorry I can't give you any more info.

Bruce

[BendGrampie]

No problem.    It's definitely odd.   I'm not awake during any of these shutdowns and I'm pretty sure I don't sleepwalk.   Also, all of the other AP-related apps ran through the night without a hiccup and there's nothing in the Event Log.

Marc

[BendGrampie]

So this has happened 3-4 times in the last couple of weeks.   I haven't been awake during any of the failure times, and no other applications shut down.   Indeed, the session ran without issues (unguided, of course) for the rest of the night.

Odd!

Marc

On Thursday, September 18, 2025 at 8:10:15 AM UTC-7 bw_m...@earthlink.net wrote:

[Bruce Waddington]

Well, this isn't very satisfactory.  If it's happened multiple times, it will probably happen again.  So here are two suggestions:

1.  Go ahead and update to the 2.6.13dev release of PHD2, available here: https://openphdguiding.org/development-snapshots/

I'm not aware of any changes we've made that would have any effect on this problem but the dev7 release will put you on the same source level as the one we're using.  If you think about it, you're currently running a 2.6.13 base release that's been around since the beginning of 2024 - and obviously hasn't been changed.  So if your problem is suddenly showing up, can you identify anything in your environment that has changed?  When you install the dev7 release, don't un-install or change anything else, just run the installer.  

2.  The next time you start an imaging session and everything is going, minimize the PHD2 window.  This will leave it running on the taskbar but its window won't be active and it shouldn't receive any errant keystrokes or mouse clicks.  I'm not suggesting you did that unless you were walking in your sleep - but it will eliminate the possibility that anything like a remote desktop app could generate that kind of traffic.

To be thorough, it would also be good to check the Windows logs at the time of the shut-down to be sure something like an anti-malware app didn't trigger the event.  If we can't get anywhere this way and once you're on the dev7 release, I can either give you an instrumented version of PHD2 or perhaps one that will simply ignore Window-Close events if the guiding session is still active and devices are still connected.

Good luck,

Bruce

[Brian Valente]

Marc 

Is it possible there's an instruction of shutdown phd in your sequence that's getting fired unintentionally? 

Just thinking about other things that could emulate this

(and now i get the 'bend grampie' part haha)

To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/bab37956-bad0-4803-9833-1b6e96e23995n%40googlegroups.com.