Closed jonty-comp closed 6 years ago
Explorer.exe is launch ? Hyperion Screen cap crash when explorer.exe not started ... it's problem ...
I thought it could be that, but it still crashes if i try to launch it after explorer.exe is started:
I think I have also noticed this issue. I always thought that this happens on a system reboot because Windows 10 tries to re-open / restore the state of apps that were open before shutdown and because HyperionScreenCap got started before I logged in, it would crash.
However, since you are facing this issue even while starting it manually, I don't think the above mentioned explanation is correct. I think that the issue could be as simple as some variable being NULL or undefined since I have done a lot of code refactor with the most recent release.
A temporary fix could be to try version 2.2 until this get fixed. Or if you could debug the issue using Visual Studio, that would be incredibly helpful. I don't have access to my PC for a couple of weeks so I might not be able to help you out quickly.
So the unpredictability of this bug is proving very annoying! Whenever I start debugging from VS2017, it seems to run okay. The main installed exe also seems to run file while VS is open. If I close VS, sometimes it runs, sometimes it doesn't - and if I start a debugging session when the release exe crashes it just says that it crashed in native code. Will keep probing!
EDIT: aha, I've gotten it to crash in a debugging session:
System.InvalidOperationException
HResult=0x80131509
Message=Invoke or BeginInvoke cannot be called on a control until the window handle has been created.
Source=System.Windows.Forms
StackTrace:
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
at HyperionScreenCap.MainForm.ExecuteToggleCaptureCommand(CaptureCommand command) in C:\Users\jonty\Source\HyperionScreenCap\HyperionScreenCap\Form\MainForm.cs:line 195
at HyperionScreenCap.MainForm.<>c__DisplayClass19_0.<ToggleCapture>b__1() in C:\Users\jonty\Source\HyperionScreenCap\HyperionScreenCap\Form\MainForm.cs:line 177
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
Looks like some kind of race condition? It's worth noting that I have auto start capture at startup enabled.
Agreed! This does seem like a race condition. Will look into this soon.
Same behavior here. Just for the records. Thanks for already taking care.
Based on the stacktrace you provided, I think I have found the solution. Will be including that in the next release.
Awesome, I have just updated and enabled automatic connection - will hopefully be able to close this in a couple of days if it doesn't crash!
Seems like this is fixed now. Resolving.
I've put a HyperionScreenCap shortcut in my startup folder to start with Windows and while sometimes it works fine, sometimes it won't launch at all and the tray icon will disappear as soon as I hover over it. Sometimes I also get a "HyperionScreenCap has stopped working" message.
There's nothing mysterious in the log:
...then when I click the Close Program button on the crash popup, a single extra line is added before it is killed:
Bizarrely, if I start it a bunch more times and let it crash each time, suddenly it will work.
My Hyperion server is a Raspberry Pi 3 connected via wired LAN. It's hard to pin down when this started happening, but it was before I reformatted my PC earlier this month. I've tried connecting via both hostname and IP address and the strange behaviour persists.
I can debug further with Visual Studio if you need me to!