Skip to main content
amyjocoleman
Participating Frequently
May 6, 2015
Question

Error #2046

  • May 6, 2015
  • 16 replies
  • 50806 views

We are receiving Error #2046 when loading the flash component (delivered as a.SWF) for one of our products. We may have a problem with the certificate that was used to sign the component.  While we work on fixing the certificate, is there any way to avoid the error by making a change on the browser?

This topic has been closed for replies.

16 replies

Participant
July 7, 2015

Some of the products in our catalogue have the swz files bundled in SCORM packages intended to reside behind a firewall on an LMS. Updating the 4.1 Flex framework swz files sloved the problem with these products when hosted on the web, but the SCORM 1.2 zips still fail to launch in ADL test suite. (A client requirement.) We have tried all suggestions in this thread without success. Any idea why the updated frameworks are failing?

chris.campbell
Community Manager
Community Manager
July 7, 2015

What version of ADL/AIR is being used when you get this error code?

Participant
July 9, 2015

-  Sorry. The ADL I refer to is Advanced Distributed Learning TestSuite1.2.7 specifically for testing SCORM 1.2 conformant zip packages.

Participant
June 14, 2015

We ran into this very same issue today, although its an AIR app that is currently deployed to the field, making updates more problematic.

We run a mixed AIR/Java app, and the Java side launches the AIR app. When some of our products restarted in the field, the AIR app failed to load.  Looking at the trace log, it was getting the same Error #2046 The loaded file did not have a valid signature. That search led me here.  We're using Flex 4.5.1 and according Chris Campbell, 4.5.1 has valid expiration dates. We even looked our our local .swz files and compared. They also show the 2025/2026 dates. However, the app still failed to launch w/ the same error. Using strace on Linux, we could tell it was getting to the framework.swz and then stopping. So we're not sure if there is something else in those swz files that has dates.  We did some testing by setting the local clock back and was able to get it to fail or work based on the date (I think between June 12 and June 13). 

Our fix was to just bite the bullet and statically link in the framework SWC files.  I'm still a little perplexed why the app was failing to load the RSLs when the expiration dates should be valid, but it was.

- John O

chris.campbell
Community Manager
Community Manager
June 16, 2015

Hi John,

I suspect you ran into a slightly different permutation of this issue.  If you're using AIR, are you using HTMLLoader and loading swf content into the AIR application?  Is this app using a shared runtime?

The issue over the weekend (on Jun 13 01:01:42 2015 GMT to be exact) was due to an older version of Flash Player (10.x) having it's 10 year root certificate expire.  We updated Flash Player back in 2011 with a new 15 year cert, but it sounds like your app might not have access to this...

Chris

Participant
June 16, 2015

Our AIR app is using Flex 4.5.1 and runtime-shared-library-path (specified in our Ant build using mxmlc).  We are using local copies of the framework .swz files.  Switching it over to not use the RSLs seemed to fix our issue, but we'd rather use the RSLs.

Do you think the issue is the Flash Player in the SDK itself?  If so, how could we check this and/or fix the issue?

Thanks for any advice.

Participant
June 3, 2015

Hi,

We have resolved this issue for affected customers on Chrome & IE thanks to the helpful details however, users with Chromebooks are still reporting the problem. Please could someone advise what to do beyond simply clearing the browser cache for Chromebook as I do not have access to one of these devices? How / Where do I clear the swz from the local cache?

Many thanks!

michael_blanco
Participant
May 14, 2015

I haven't made any of the changes to the .swz files and some desktop clients are able to log in and some can't.  I'm reluctant to make any changes, because some are reporting getting error #2304 after making the changes.  Any advice is appreciated.

May 8, 2015

Hi as an end user this has caused me a lot of problems on an embedded machine GUI.  I tried deleting the cache on all my browsers and flash but the problem still persisted until I changed my PC date to a random date in 2014 then cleared the cache and flash again.  Once done the next time you open the browser and attempt to log on to the device everything downloads as normal   This is obviously just a work around until the fixed server files can be updated with a firmware update which is done by the GUI interface in my case.  Built-in obsolecence brilliant.

Hope this gets you out of trouble too.

Participant
May 7, 2015

Hi,

I was getting the same error and after relaced swz files and cleared cache i am having error #2034.

Thank you in advance for your help.

Med.

chris.campbell
Community Manager
Community Manager
May 9, 2015

Mohamed Bassami wrote:

Hi,

I was getting the same error and after relaced swz files and cleared cache i am having error #2034.

Thank you in advance for your help.

Med.

If you haven't already, can you try restarting the system?

Participant
May 12, 2015

Hi guys,

I have meet the similar issue, after follow these steps, 1. replace all SDK swz file with the new one. 2. restart the service (in fact, I restart the machine). 3. clear client cache by use the "Delete Data" button in flash player global setting panel. reopen the safari or firefox, what I get is Error #2034.

Tamayama_keiichi
Participant
May 7, 2015

Hi Chris,

Is there a way to check the Expiration Date of the new swz-files?

Of course, I believe the Expiration date on which you've described above.

However, my customer has requested the evidence.


Best regards,


Keiichi

chris.campbell
Community Manager
Community Manager
May 9, 2015

恵一 玉山 wrote:

Hi Chris,

Is there a way to check the Expiration Date of the new swz-files?

Of course, I believe the Expiration date on which you've described above.

However, my customer has requested the evidence.


Best regards,


Keiichi

We’re investigating coming up with a more official / automated way for customers to accomplish this. 


In the meantime, here’s how I did this:


Open each SWZ file up in binary mode, scroll towards the bottom of the file, and look for a set of numbers to find the yymmdd format for the certification applied and expired date




Look at the pattern with the red box around it. The top one is the cert creation date, the bottom is the cert expiration date (in the form YYMMDD). You may see several similar patterns like this in the file, but look for the one which has an accurate description wrt. the particular RSL you’re looking at (alternatively, you can look for the closest expiration date)

amyjocoleman
Participating Frequently
May 6, 2015

To answer the question about the expiration date in the new files:  Based on what we see in the new files, the date is 1-Nov-2025.  Hopefully Adobe will confirm.

chris.campbell
Community Manager
Community Manager
May 6, 2015

Thank you to everyone that contributed to this thread.  I'm still in the process of going through all of the .swz files hosted on fpdownload.adobe.com to determine their expatriation date, but we believe they are all valid until at least 2025.  Once we finish this, we'll move to the flex sdk's still hosted on adobe and determine which are now out of date.

As noted previously, the .swz signatures supplied in the flex 4.1.0.16076 SDK's expired this morning (5/6/2015).  Customers are now being advised to point their apps (or download) the .swz files hosted on fpdownload.adobe.com.  The files hosted on fpdownload have 15 year certificates, expiring on November 1st, 2025 or later.  The exact dates for the set of files lists on this thread are:

datavisualization_4.1.0.16076.swz      November 1st, 2025

framework_4.1.0.16076.swz              November 1st, 2025

framework_4.1.0.21490.swz              July 24th, 2026

osmf_flex.4.0.0.13495.swz              November 1st, 2025

rpc_4.1.0.16076.swz                    November 1st, 2025

spark_4.1.0.16076.swz                  November 1st, 2025

sparkskins_4.1.0.16076.swz            November 1st, 2025

Thank you again for all your help and investigation.  Your comments here were able to bring our west cost folks up to speed very fast this morning.

Participant
May 7, 2015

And what about 4.6 swz ? When will we have the same issue ?

amyjocoleman
Participating Frequently
May 6, 2015

It seems that everyone has the general idea of how to resolve the problem, which is great.  We are close to rolling out instructions for the fix to our clients.  We have been on calls with Adobe over the last couple of hours and have asked them to confirm that the resolution we have been discussing here is in fact the official solution from Adobe.  We have also asked for any ideas for a solution which is a bit simpler for our clients to deploy.  So, we hope to have this info from Adobe in the next few hours and will share it with you then.  Good luck everyone.

May 6, 2015

We've replaced the files, but it seems does not work..

Participant
May 6, 2015

First. Delete All files in Chrome.

C:\Users\????????\AppData\Local\Google\Chrome\User Data\Default\Pepper Data\Shockwave Flash\CacheWritableAdobeRoot\AssetCache\?????\???.swz


May 6, 2015

Thank you for your advice, I'll take a try.