SGPro Closes when Session Finished and attempt to Edit a target

Description

This has happened to me twice now, but after an imaging session is completed, if you attempt to edit a target, SGPro will just close down

Link to Logs

Useful Info

OS: Microsoft Windows 10 Pro
Ver: 3.1.0.425
.NET: 4.8

Thanks. Because you, or others, were kind enough to share anonymous analytics about SGPro this has already been addressed and released in 427.

1 Like

E.T Phone Home :slight_smile:

It just did it again on me, imaging session ended last night (Stopped it manually), I Just logged into remote PC this morning and clicked on a target to edit settings and SGPro closed

Did you restart SGPro after this crash? I’m only asking because that’s when the crash data is sent to our crash analytics service.

Yes I did, in fact that restart is my current session :slight_smile:

@Ken It did it again this morning on .421 also, I have just started it back up again

Ok, thx. I have not yet had a chance to go through the crash reports, will try to do so shortly

@STAstro

I assume you meant 431 right? Can you provide details on what you mean by “clicked on a target to edit settings”? Do you mean clicking the target’s gear icon or something else?

@Ken

Sorry yep, 431

Yes clicking on the gear icon for a target

Would be good for the Anonymised Data to have an option to have the data not anonymised, so something that each person has to “Opt” into.

We have something like that in our product called the CEIP “Customer Experience and Improvement Program”, but a customer has to opt into it, if we choose to opt into it that should help you identify our crash reports quicker right?

Not marking this fixed yet, just noting that 3.1.0.432 will prevent a crash, but does not fix the underlying issue (not sure what it is yet). So… when this happens again, it will look like a the click on the gear icon was just ignored. I have new logging here so we can see what’s going on.

@Ken Will have an update for you in the morning, just finished imaging for the night, so will see what happens in the morning

@Ken Here you go buddy

https://www.dropbox.com/s/6wbznz9fsv33uin/sgpro_log_archive_ac8c63fc-6a10-48fe-a3c9-9836b69189c8.zip?dl=1

Same thing, sequence was finished, SGPro left open, came back to it this morning, hit Target Settings (Cog) and SGPro just closed

I am not seeing a crash report from your machine. Did you opt into sending anonymous info to us? Or maybe that machine does not have a network connection?

Also… can you take a look to see if there are any Windows events that describe the crash? You can do this by running “Even Viewer” and then go to “Windows Logs” -> “Application”, then navigate to around 01/16/20 07:25:51.270.

@Ken Yes I have the option to send anonymous usage statistics sent selected

Faulting application name: Sequence Generator.exe, version: 3.1.0.432, time stamp: 0x5e127e52
Faulting module name: ucrtbase.dll, version: 10.0.18362.387, time stamp: 0x6dbf7eae
Exception code: 0xc0000409
Fault offset: 0x0009caa2
Faulting process ID: 0x2584
Faulting application start time: 0x01d5cbc4636d9b75
Faulting application path: C:\Program Files (x86)\Sequence Generator\Sequence Generator.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report ID: de0b83a5-66de-4a24-aecd-86fc09ecf066
Faulting package full name:
Faulting package-relative application ID:

Further Info:
Fault bucket 1246594022597225152, type 5
Event Name: BEX
Response: Not available
Cab Id: 0

Problem signature:
P1: Sequence Generator.exe
P2: 3.1.0.432
P3: 5e127e52
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\WEREF15.tmp.dmp
\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF261.tmp.WERInternalMetadata.xml
\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF272.tmp.xml
\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF270.tmp.csv
\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF281.tmp.txt

These files may be available here:
\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_Sequence Generat_7197e6b52b8c4c614cc5de27a695a812d39d60_d3b72436_e66e43e2-6d02-4964-8a98-c9ba08e66839

Analysis symbol:
Rechecking for solution: 0
Report Id: de0b83a5-66de-4a24-aecd-86fc09ecf066
Report Status: 268435456
Hashed bucket: a285c8265cc4ce1a614ccaa8a8086ac0
Cab Guid: 0

Whoa… Do you have Visual Studio installed on that machine?

I’ll have a look but I do not think so

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…