VIsual C++ is installed, I think that’s a requirement for EQMOD
That DLL is used by visual studio apparently… SGPro is crashing outside of .NET inside that DLL (thus no crash report). I’m afraid, I don’t know what causes this… or how SGPro is getting into it, though I suspect it is from ASCOM.Astrometry -> Some C++ thing. SGPro cannot intercept this kind of crash…
Strange, as I do not have Visual Studio installed as I would not have the need to have that on the observatory NUK, I quite literally only have:
ASCOM
EQMOD
SGPro
QHYCCD Drivers
Sesto Senso
Pegasus Astro USB Controller
I am going to do some testing today to see what actually triggers the issue (Which piece of software), it only does this after a sequence run, it doesn’t do it if say I have SGPro open and the next day I change a target.
I tried to do some stuff this morning to trigger, but it didn’t happen, so tonight I will be imaging, and tomorrow morning I will check to see if the app crashes again
Actually it just did it again, so I can re-produce this
- Start SGPro
- Run a sequence, let end of sequence run
- Leave SGPro running for 3+ hours
- Edit a target…gone
Sorry, I meant the VC runtime redistibutable, not visual studio.
I have not done this, but it’s easy enough to try
The only way to prevent this is to figure out what conditions are causing it. With a lot of errors, we can be a little sloppy and intercept them after the error has occurred. This error is so deep beyond the control of SGPro that it is simply not interceptable and will ALWAYS crash the parent process. If we can determine what it is AND show that the state that causes the crash is actually invalid, we can stop it. What I’m worried about is that the state that causes crash will be perfectly valid and therefore, indistinguishable from others.
Also… since there are no other reports of this, it may be that the issue is specific to some localized corruption. It may be worthwhile to re-install / repair the VC++ Runtime Distributable.
I’m going to have a look at when C++ Runtimes were installed, then I can trace back as to what other application was installed at that time too, then I can narrow it down. But the sky is clear tonight 
Hmmmm seems the last update to SGPro reset all of my progress on targets too 
There is one other similar report to this also, but I have not been able to locate anything. Did the progress get reset when the sequence opened or some other time?
@Ken Must have been when the sequence opened after SGPro upgraded and self opened, as I didn’t check the sequence again since imaging the other night
I also answered on the forum per your link here.
It may happen when I open a saved imaging session but I can recall that being the case. It happens during the FLATS gather session - as soon as I can I will repeat that season and report the logs with the time the lost “PROGRESS” occurs so perhaps you can nail down what may be happening.
Thanks again.
Ed
Hmmm strange, I have removed all the Visual C++ apps and now SGPro doesn’t start!
However, I have just done a re-install of the QHY Drivers, and that has re-installed the Visual C++ Routine, also ASCOM requires Visual C++ as well, as I just repaired that installation and that installed the runtimes, since performing that install, SGPro works again
I do believe certain components of ASCOM astrometry might depend on those redistributables. Let us know if that makes any difference for the crash. I will attempt to run the “3 hr wait and crash” test today.
Waiting for all of this high altitude cloud to go away!
Has not happened today 
1 Like
And has not happened today either, so looks like whatever I did with the C++ Runtimes has fixed it
Aborted Sequence around 11pm last night with End of Sequence Options, this morning I went to change a target and SGPro closed, now PHD2 was still running in the background (Not connected to equipment), just sat there doing nothing
Faulting application name: Sequence Generator.exe, version: 3.1.0.449, time stamp: 0x5e2e2c14
Faulting module name: ucrtbase.dll, version: 10.0.18362.387, time stamp: 0x6dbf7eae
Exception code: 0xc0000409
Fault offset: 0x0009caa2
Faulting process ID: 0x1d54
Faulting application start time: 0x01d5d5c16b207a3d
Faulting application path: C:\Program Files (x86)\Sequence Generator\Sequence Generator.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report ID: e36a4232-eef4-4d4f-9d1e-bf8fd0593fee
Faulting package full name:
Faulting package-relative application ID:
Fault bucket 1512158347295109294, type 5
Event Name: BEX
Response: Not available
Cab Id: 0
Problem signature:
P1: Sequence Generator.exe
P2: 3.1.0.449
P3: 5e2e2c14
P4: ucrtbase.dll
P5: 10.0.18362.387
P6: 6dbf7eae
P7: 0009caa2
P8: c0000409
P9: 00000005
P10:
Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA3A4.tmp.dmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA77D.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA78E.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA78C.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA79C.tmp.txt
These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_Sequence Generat_0e190c01d94123bd47517d070d22d1061538_78289f24_ebf30601-085e-4d1c-8b0b-06c8d49e9990
Analysis symbol:
Rechecking for solution: 0
Report Id: e36a4232-eef4-4d4f-9d1e-bf8fd0593fee
Report Status: 268435456
Hashed bucket: a7f6dc0b79962b3a44fc44014eaab0ae
Cab Guid: 0That’s a bummer. Unfortunately I don’t think there is anything we can do about this without a significant amount of research (it might have to do with Astrometry calls we make, but we cannot control a crash across a COM barrier). As of this moment, the error appears to be isolated to a specific machine (or a specific set of software).
Seems like the culprit is PHD2, ran through the same process last night, only this time I manually closed PHD2 after the sequence had been aborted and all equipment disconected, I will verify on my next imaging run that if I leave PHD2 application running until the following morning and then try and edit a target I suspect I will hit the issue again.