BETA 4.1.0.733 - crash after meridian flip plate solve?

General
#1

Running a sequence last night which stopped at 00:37. The observatory PC was still running this morning, the scope and dome were tracking, the camera was still being cooled, PHD2 was running - no sign of SGPro though. It hadn’t stopped or gone into recovery, it must have crashed?

Link below to the log file. It looks like the sequence needed to do a meridian flip. This executed OK, SGPro waited for the dome movement to complete, then did a plate solve. The first plate solve was OK so did an adjustment, then SGPro did a second plate solve which SGPro " Checking to see if solve might be bad…". Seems to be after this that it’s gone wrong?

I use an EQ8 mount with GSServer driver - the drivers log file doesn’t seem to report anything wrong.

SGPro log file:

GSServer log file:

#2

It looks like SGPro started doing what it was supposed to do, by presenting a “blocking dialog” (a window that will not allow sequence to resume unless it is dismissed) that notified of the possible bad solve and then gave you 10 minutes to override the decision to abort the sequence. But… it looks like SGPro did not auto close this dialog. When you went to the machine in the morning, what did SGPro look like? Was there a message onscreen about a possible bad solve?

#3

That was the strange thing, SGPro had completely disappeared. The SGPro user interface wasn’t on screen, there was no taskbar button for it, I Alt-Tab’d to sanity check that it hadn’t disappeared off the screen. In retrospect, I should have had a look in Task Manager whether it had processes running, so I don’t know whether some element of it was running - but the log file just stops abruptly at 00:37:17.724.

I’ve just checked on the observatory PC and the last Date modified timestamp on the log file was 30/01/2022 00:37 - same as the last entry written.

I restarted SGPro and it showed progress to where the log file indicated - 9 images of Sh2-290 complete. Looking at the start of the log file for this SGPro run compared to the one that failed -

[01/30/22 07:39:40.184][DEBUG][Background startup thread][NONE] Cleaning 49 files in directory C:\Users\micro\AppData\Local\SequenceGenerator\Temp…

So there were a load of files in SGPro’s Temp folder that were left over from the failed run - I’ll know to check next time before restarting SGPro.

?

#4

Hmmm. Ok well, that’s disconcerting. Looking in the Task Manager if it happens again will be helpful. I haven’t ever seen SGPro crash with absolutely no message so that would be new. But, if it is doing that the windows system log will usually have a message in it. Not sure if you have experience looking through that swamp. I recreated this exact scenario here by forcing a “bad solve” and everything worked like it was supposed to. I’ll need to think about this for a minute…

#5

Think I’ve found it in Event Viewer:

Log Name:      Application
Source:        Application Error
Date:          30/01/2022 00:38:25
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Observatory
Description:
Faulting application name: Sequence Generator.exe, version: 4.1.0.733, time stamp: 0x61ef34a7
Faulting module name: USER32.dll, version: 10.0.19041.1466, time stamp: 0x91540ae3
Exception code: 0xc00000fd
Fault offset: 0x00038538
Faulting process ID: 0x25e8
Faulting application start time: 0x01d8153bd9053864
Faulting application path: C:\Program Files (x86)\Sequence Generator\Sequence Generator.exe
Faulting module path: C:\WINDOWS\System32\USER32.dll
Report ID: dc4f4c1a-5775-49ba-840a-08aad8accd4a
Faulting package full name: 
Faulting package-relative application ID: 
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
	<Provider Name="Application Error" />
	<EventID Qualifiers="0">1000</EventID>
	<Version>0</Version>
	<Level>2</Level>
	<Task>100</Task>
	<Opcode>0</Opcode>
	<Keywords>0x80000000000000</Keywords>
	<TimeCreated SystemTime="2022-01-30T00:38:25.5133554Z" />
	<EventRecordID>7067</EventRecordID>
	<Correlation />
	<Execution ProcessID="0" ThreadID="0" />
	<Channel>Application</Channel>
	<Computer>Observatory</Computer>
	<Security />
  </System>
  <EventData>
	<Data>Sequence Generator.exe</Data>
	<Data>4.1.0.733</Data>
	<Data>61ef34a7</Data>
	<Data>USER32.dll</Data>
	<Data>10.0.19041.1466</Data>
	<Data>91540ae3</Data>
	<Data>c00000fd</Data>
	<Data>00038538</Data>
	<Data>25e8</Data>
	<Data>01d8153bd9053864</Data>
	<Data>C:\Program Files (x86)\Sequence Generator\Sequence Generator.exe</Data>
	<Data>C:\WINDOWS\System32\USER32.dll</Data>
	<Data>dc4f4c1a-5775-49ba-840a-08aad8accd4a</Data>
	<Data>
	</Data>
	<Data>
	</Data>
  </EventData>
</Event>
#6

Yes, that’s it for sure. Thanks. The logs indicate the error occurred while attempting to save your sequence to disk. For this error we’re looking at one of two things. Either:

  • There is a bug in SGPro, where it gets into a state that continually gobbles up memory until there is none left and then crashes.
  • Your system is critically low on memory and SGPro was not able to allocate new memory. This kind of memory shortage can be caused by insufficient RAM, but is more commonly caused by failures with the Windows Virtual Memory system.

Windows Virtual Memory failures can be caused, typically, by one of two things:

  • If you are letting Windows manage the system’s virtual memory, the error is often the result of very low hard disk drive space remaining.
  • If you have overridden Window’s auto management and are supplying your own parameters, the value you have chosen for the page file size may be too low.

So… because this is a super gross error, before we go diving in, we just want to verify the state of your machine wrt this stuff. Here is a reasonable writeup that has basic steps for checking.

Appreciate the help…

#7

C: drive is a 240GB SSD (Kingston SV300S37A240G), 173 GB used, 48.8GB free space.
PC has 8GB of RAM.
Virtual Memory tab has “Automatically manage paging file size for all drives” ticked. Shows min 16MB, recommended 1905 MB, currently allocated 1280MB.

#8

ok, thx. All that seems reasonable.