Course crashing in Internet Explorer after ~45 minutes, memory leak issue?

[nickr58952884]

Hi all. I have an hour long course which works fine in every browser but Internet Explorer. It's fine for the first 40 minutes of the course, but once it starts approaching 50 minutes it begins behaving erratically, failing to load slide background images and ultimately crashing. Working with a fellow Captivate developer we believe it to be a memory leak issue.

This crash is not happening at a specific slide or event. Examining memory in Resource Monitor the IE tab running the course builds Commit and Working Set continually, only occasionally releasing a little bit of memory. Once it hits 1,500,000 KB the tab crashes and automatically reloads, starting the course from the beginning. This has been consistently observed with testing. It is not a slide, event, or amount of time – it crashes when Working Set hits 1,500,000 KB.

For this product we create a version for web-based deployment and a version for LMS use. For the web-based version, if TOC is enabled it will resume where it left off. For the LMS version, the built-in bookmarking works fine as users take the course (if they take 20 minutes of the course, leave, then come back it resumes properly.) However, if an IE user takes the course and at no point leaves and re-enters the course it will crash between 40 and 50 minutes in, and when the browser reloads the course it does so from the beginning of the course. I believe that, upon reload, the browser isn't checking the LMS for resume data, it just reloads the tab and puts new resume data into the LMS from the beginning of the course, overwriting the user's previous progress.

The course is 176 slides. It is responsive. Most have brief narration, a handful have video (none more than a few minutes.) I have done a similar course annually for several years and this is the first year I have used Captivate 2019 (used CP17 last year, CP7 all years prior) and this is the first that has had this particular issue.

We have been working on various workarounds for this but I would love to find a way to avoid this crash! I do recommend users use Chrome (and specifically ask them to avoid Internet Explorer) but it's not feasible for all of my potential users to use something else (different computer skill levels, some entity policies locking users in to IE, etc.) I appreciate any insight you all might have, you all are such an amazing resource and the guidance you provide through this community and your individual blogs and videos have saved my hide numerous times over the years!

[GilMichelini]

We are running into a similar issue. You pointed out the most obivous solution in moving them away from IE. A solution we found worked was breaking the course into smaller chunks. Is that a possible solution?

[nickr58952884]

We do have an iteration of this for LMS managers that are able to set up a curriculum for their users and require the sections to be done in order (otherwise its status granting a Continuing Legal Education credit for attorneys would be in jeopardy) but not all LMS managers want to/are able to do this. For entities that are only able to deploy the hour long course and have users locked in to IE who are running into this issue en masse my course of action has been to recommend not using IE, and if they must use IE exit the course every 15 minutes or so and come back. Putting the onus on the users to take extraordinary steps to manage their own experience feels like an admission of failure on my part. I am really hoping to regain control over my product's UX.

How long is your course?

Does it contain video?

Is it heavy with photo backgrounds for slides?

Is it crashing around the 45 minute mark?

I have been curious if a course with no video or less images would still bloat the Commit/Working Set memory less to the extent that it would crash 3/4 of the way through but creating another hour long course for such an experiment (and dropping 45 minutes a pop to test this hypothesis) is really not something I can pursue at this time.

[sabre123]

I'll spare you my bagging of IE, but have you tried using IE's DevTools to see if you can determine if an error gets thrown when it crashes? If not, I would suggest you open the Console and run it until it crashes and see if an error shows up there. It may help your troubleshooting endeavors.

[RodWard]

I'd also be interested in looking into which specific version of IE you are using.  I'm assuming it would of course be IE11 because nobody in their right mind would be trying to run major IE versions before that now.  But even within IE11 there were several versions.  So are you certain your IE versions have all available updates?

[nickr58952884]

Hi Rod, long time listener, first time caller, I appreciate all you do in this community! Yes, my testing and my collegues' testing have all been on fully updated versions of IE. This issue has been encountered by many, many other users (this product has been live since February) but I can't say how updated their browsers are. I have tested it with various levels of emulation, at the browser level and by editing my HTML output to force emulation, and it always crashes (even when emulating Edge, which itself does not crash playing back this content.) 

[RodWard]

Can I ask: To which version of SCORM are you publishing this course?  If it is SCORM 1.2, have you tried experimenting with publishing to SCORM 2004 to see if you get any better results?

I am not confident this is significant but I am asking because SCORM 1.2 is known to have very low memory space allocated to Resume Data.  This limitation was fixed in SCORM 2004.  A large module of the size you are discussing here would easily exceed the SCORM 1.2 memory limit.  In theory this should mean all browsers would be affected the same, but perhaps the later browsers like Edge and Chrome are not quite as sensitive to the issue and don't crash when they hit the problem.

However, since you indicate you are experiencing this same issue on projects published to HTML5 without SCORM, I'm not confident my hunch will be of much use.

I still think your best (and quickest solution) to resolve this issue is just to break up the module into smaller chunks.  If there is a hard limitation within IE, and you have no option except to support IE, then it's a hard limitation on how you build your course whichever way you look at it.

[nickr58952884]

I haven't tested SCORM 2004, but as you noted I do encounter the same issue publishing to HTML5 without SCORM. Thanks for your feedback.

[nickr58952884]

I agree that IE is not ideal. Of users of my web-based product only roughly 7% are still using it (I can't get those sort of stats for the LMS users, which are more likely to be locked into specific browsers due to IT policies.) I have monitored the DevTools in IE. The errors given at time of crash (again, once Commit and Working Memory hit that critical 1,500,000 KB size) are 

1. Not enough memory resources are available to complete this operation.
2. The GPU device instance has been suspended. Use GetDeviceRemovedReason to determine the appropriate action.

I will also point out that allocating additional memory to IE isn't helpful (not that that's something I could suggest to users to avoid the issue.) Also, for completeness' sake I will mention that emulating a different IE version at the browser level doesn't help, nor does changing the HTML output to force emulation, even to Edge (which itself doesn't crash as IE does.)

[Jacob Hokland]

Could be one of the security fixes in IE. Try one of the first versions of IE 11 and export your project to SCORM 2004 2th version and let me know the result.