SL2 Crashing repeatedly

Sep 29, 2017

Today I've been working on a relatively small (14 slides) SL2 file.  I've recorded narration, added cue points and adjusted animation timings. Several slides have multiple layers, but nothing fancy. The file is on my hard drive and has never been moved from my hard drive.  Thus far it has crashed about 8 times with no rhyme or reason for the crash and no consistency of action taken just before the crash.  I have restarted the computer in hope that there was an update lurking behind the scenes that needed to complete, but this didn't solve the problem. Fortunately I'm saving frequently, but it is a bother! Anyone else having this issue?

38 Replies
Leslie McKerchie

Hi Joyce!

That would be frustrating. Let's see if we can help you out with this.

If you are only experiencing an issue with this project, you may want to import the slides into a new file to see if that alleviates the issue.

If you are having these problems across your files or just with your software in general, I'd advise a repair.

Just let me know if you need anything further :)

Joyce Hensen

I wish I could say that the problem stayed gone when I moved to a different file.  However, after I recorded narration into a new course, the crashing began again. I have to remember to save after every single change so that WHEN it crashes, I don't lose my work.  Any suggestions?  I'm using the same equipment I have always used.

Jimmi Thøgersen

We've had the same issue for the past 4 weeks, on (at least) 5 different PC's.

Joyce (and George), if you're able to have a look at the Windows event log, it would help a lot. Here's how (link to more visual guide below):

1. Go to the "Event Viewer" in Windows (it should show up if you search for it in the Start menu).

2. In the left panel ("tree"), expand "Windows Logs" and select "Applications".

3. A lot of events in applications and Windows itself are listed here, so we need to filter it: In the right hand panel ("Actions") click "Filter Current Log..."

4. Put a checkmark in "Error" (we just want to see those, not warnings or information) and open the "Event sources" dropdown. Select ".NET Runtime". Then click "OK". You'll now get a list of errors in the middle panel - some will be Storyline, some might be other programs that use the ".NET Framework".

4. Select each row in the list of errors and look in the first line of the text that appears in the "General" tab. If it's Storyline, it will say "Application: Storyline.exe".

5. Below, it will say (in lots of technical speak) what exactly happened (sometimes, like in our case, less exactly...). If it's the same crashes we've been experiencing, it will say something about "Access Violation" and "C0000005".

I've added a more visual guide here: https://imgur.com/a/xDL42

If it's the same crashes as we are experiencing, we've been troubleshooting and monitoring this a lot, and found that it's likely to be caused by the latest security update to FlashPlayer (released around September 13) - it's actually the FlashPlayer that's embedded in Storyline 2 (for previewing etc.) that crashes - bringing Storyline down with it - not Storyline itself. We've (just today) tried uninstalling that update, hoping it will fix the issue.

Jimmi Thøgersen

Thanks for the confirmation, Joyce - we've sent a detailed crash log and offered a complete memory dump from a crash to Articulate support (the Storyline developers may be able to find some details about what's happening in those).

An "Access Violation" crash may happen for all kinds of reasons - however, for various technical reasons (basically, the way Storyline is programmed), access violations are very unlikely to happen in Storyline itself, but may happen in some third party parts its using - like FlashPlayer or the part that encodes videos.

Because of the timing - that we're all experiencing these random crashes these past few weeks - it's likely it's the same issue. I haven't seen Storyline crash with "Access Violation" errors in the past.

IT is probably already aware of how to roll back a Windows update (but they may be hesitant to do it, since it's a security update). But the way we did it was to remove the update from Windows, then used a tool from Microsoft to hide that particular update in the future (otherwise, Windows will ask you to restart, and immediately reinstall the update). https://support.microsoft.com/en-us/help/3073930/how-to-temporarily-prevent-a-driver-update-from-reinstalling-in-window (although it says "driver update", the same tool can be used to hide the FlashPlayer update).

Again, since we only tried this today, I can't promise it actually helps. :-)

Crystal Horn

Thanks for the helpful input, Jimmi. I found your case, and it looks like Victor offered this information:

This Adobe article that mentions a new audio output tab that's been added to the Flash Player Settings in the Flash update:

https://forums.adobe.com/thread/2384471

While its new feature was geared towards selecting audio output that could be different from the computer's default playback device, it is also likely that under certain environmental conditions, it can cause the Flash Player to run out of memory. Since Storyline 2 relies heavily on Flash Player, this in turn could cause random crashes - as seen on the logs you've shared.

Right now, we're monitoring this behavior to determine if an update is necessary on our end. Thanks to everyone for letting us know how it's impacting you!

Jimmi Thøgersen

I'm not sure I would call it system specific - so far I've heard from:

  • a few of our customers at different companies
  • every single one of our internal Storyline developers still using version 2

... having this issue. I have yet to find a Storyline 2 user who hasn't encountered these crashes more or less frequently the past month.

The only thing that's different is when and how often it happens. Which is to be expected, since it happens in background jobs in Storyline, not as a result of user interaction. The FlashPlayer update isn't a voluntary update - everyone will get it, unless they specifically block it.

Disclaimer: The following isn't a proven fix, but so far we haven't had any of these issues since implementing this workaround - which is, as mentioned above, to roll back FlashPlayer for Internet Explorer to a version earlier than 27.0.0.130, released September 12 (KB 4038806). This is more involved than rolling back FlashPlayer for other browsers (where you can simply use Adobe's installers), since FlashPlayer is part of the official Windows updates from Microsoft.

Adobe has released an update to 27.0.0.159, but this hasn't been pushed by Microsoft as a Windows Update yet. Nothing in the release notes for .159 indicates that it would fix the problem. If it doesn't, when it arrives the above workaround will likely stop working, since there's now another update that would need to be blocked.

Needless to say, blocking security updates shouldn't be taken lightly. The only proper solution that I can see here is for Articulate to work with Adobe on finding the issue.

This discussion is closed. You can start a new discussion or contact Articulate Support.