SEB 3.7.1 unexpectedly terminated #977
Assignees
Labels
can't reproduce
This issue cannot be reproduced and thus also not be fixed.
information required
This issue lacks information or requires feedback.
stale
This issue had no recent activity and will thus soon be closed.
Comments
|
Adjusting my Google search (the - was eliminating the exit code from search), I came across the following at least: The exit code -1073741819 in hex is 0xC0000005. If you look up this code in Microsoft's documentation (NTSTATUS Values) you will see that it indicates that your program was terminated due to an access violation. This error can occur for a variety of reasons, including de-referencing a NULL pointer or referencing an invalid address. |
|
Are there any hints in the client log? If the client application component crashed, then you'll normally find the reason in the event logs of Windows itself; open "Event Viewer" via the start menu and search the "Application" log under "Windows Logs". |
dbuechel
added
the
information required
|
Just had zoom call with end-user on their phone while they reproduced it on their laptop, and indeed two Event Viewer entries. (waiting on ZIP file on the three SEB log files, as they appear to be stuck in Microsoft O365 queue -- probably anti-virus scanner stuck on them) |
|
Thanks, this looks like a crash caused by the internal browser engine: This can unfortunately happen, so unless there is a reliable way for reproducing the problem, I'm afraid there is not much we can do. |
dbuechel
added
the
can't reproduce
|
@dbuechel it appears random indeed. Only impacts a few students, and I'm unable to create any scenario masquerading as them where I can reproduce it on the test-systems available to me, but the users themselves can reproduce it consistently. I've had a few Teams/Zoom meetings and go through their OS/system and ensured default Windows updates were all done, but also the optional ones and verified the "other Microsoft updates" toggle was active. Then also had them update videocard driver as we rely on WebGL/Tensorflow. To be safe went through installed-apps list and had them remove anything they weren't using anymore such as Citrix, RDLB, and other apps. But crash still happened. Weirdly it happens at the very end when everything successfully completed and quiz submitted. But it happens like 10+ seconds afterwards. The last action is that SignalR connection between LMS and pop-up is closed. Finally located the ZIP files stuck in Azure Exchange Security section, so I have little bit more info to share. One student has these entries in their browser.log as the final two with nothing after (nobody else had these entries): But the crash happens 7 seconds later for them, and only this student had these sync_reader.cc entries, with this being their runtime log: client.log last entries are: Scenario is quick the reproduce as you can see. They click button to launch pop-up (window #2). Camera/microphone started in window #2 with FaceAPI JS framework active and a SignalR connection between window #2 and LMS in #1, and they go back to #1 (window #2 becomes a pop-under), submit single-question quiz. JavaScript in #1 via SignalR tells window #2 to close and the end-user sees success message. Then a few moments later crash. But majority of end-users have no issue at all. Needle in the haystack, but I'll take pointers or have the end-user install a special trace version of SEB if you have one. |
|
Thanks for the additional information. A possible next step would be to verify whether this might be an upstream issue in the browser engine itself. To do so, please try to reproduce the issue in the CEF sample application (see https://cef-builds.spotifycdn.com/index.html). If it does reproduce there, then we'd be a step further. |
|
Sorry for the long delay, but it took a while to connect with students experiencing the issue as it is only a small number impacted. Both users updated to v3.8.0.742 just to be on the safe side. Google CEF Sample app with --enable-media-stream does not give a camera+microphone ID, so we needed to modify our code to accept this workflow in order for windows #2 to proceed with the proctoring. There is one warning in developer console "Warning: No client method with the name 'connect' found." which relates to signalr.min.js library we use, so going to investigate that next week on our end, but it did not at all impact functionality (and with vast majority of users having no issues at all using SEB it would be extremely unlikely, but I personally don't like any errors and/or warnings, so will work on it). CEF-Sample app did not crash. So, tried again with SEB 3.8, and it seems the logging got modified. Most importantly the 'Browser' logs did not contain any of the 'sync_reader.cc' errors, but will confirm that with more users experiencing this issue to really consider that "resolved" once they all tried it on SEB v3.8 Those entries would be at the very end and read like: LOGS FROM TEST TODAY Runtime: Browser: Client: Tried to be careful not to remove too much, and definitely covered the start of process and when it eventually terminates, but forced to censor the logs as they are not mine to share, and I don't want to risk violating privacy laws. |
|
Thanks for the extensive update. Do I understand you correctly that thus the issue still persists? Either way, we'd unfortunately need a way to reproduce the issue, otherwise there's not much we can do I'm afraid. |
|
It indeed still persist, and I believe I'm up to 7 users now (out of thousands without any issue). My next plan of attack is to take remote control and have Microsoft SysInternal Process Monitor running to keep track of any application other than SEB that is reading into the program and user-data folders that SEB uses. There has to be something interfering. Windows Safe Mode is not easy to do remote, but going to try documenting a step-by-step guide for that as well. The ESET Anti-Virus and Cisco WebEx comment made in another thread as known conflicts is something I'll dig into further as well. |
|
Great, yes that would be very helpful. Once we have a reliably reproducible issue, we can and most definitely will attempt to solve it. |
|
Totally understand the need to reproduce as it is not feasible to expect a solution otherwise. That's what I'm struggling with, because it only happens for these handful of students and nobody else. It does consistently happen for these students though, and very easy to reproduce. One question though, I went through entire process in CEF Sample App without a problem, but it was the latest version published on that day. There is a slim chance that Google fixed a bug, so could you tell me the version of CEF that SEB 3.8.0 uses? I can then at least repeat testing with the correct matching CEF Sample App version. |
|
Exactly, that is indeed possible. Please do also note that we're in the end using CefSharp, i.e. a wrapper of CEF, which may also be interfering or causing issues here. The current browser engine version is always logged in the client log, e.g. for SEB 3.7.1: |
|
This issue is stale because it has been open for 28 days with no activity. It will soon be closed automatically if there are no updates. |
github-actions
bot
added
the
stale
|
It has been tough scheduling with the students impacted as they've been exempted for the time being, so I'm forced to connect with them in their free time. Heading to OLC 2024 conference next week but will pick this up once I return to try to get the details needed. |
github-actions
bot
removed
the
stale
|
This issue is stale because it has been open for 28 days with no activity. It will soon be closed automatically if there are no updates. |
github-actions
bot
added
the
stale
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From three different systems (it is not a consistent issue, as many report no problems), I've gathered the following:
Hoping the exit code from Runtime.log provides better insight in what I could pursuit next as possible cause.
Have not been able to reproduce it myself, which is making it difficult to provide additional information as I don't like forwarding logs from end-users.
The text was updated successfully, but these errors were encountered: