Does the Flash Player (Win7 / IE 9+) cache content outside of the browser?

Question

I have encountered a technical issue using Flash (CC) content in Captivate 7.  I am distributing the content to a customer with approximately 1000 Windows PC's running IE 9 +.  Some of these computers have no issue but a small number experience a problem which prevents them from downloading content after an undetermined point.  There is no apparent pattern to identify either a fault in the content or a fault in the workstation build.
The problem looks like this:
The user is able to access the content - sometimes several courses, sometimes only one.
At some point during a course -it will stop playing (failing to load the next page).
The user can close the course and reload - but is always stops in the same place it originally failed.
The user can load previously accessed courses and these work without issue.
The user is unable to load any new courses (previously un-accessed) - resulting in a blank page.
No application events are logged when this occurs so there is little to examine when it occurs.  We have anecdotal evidence that the issue can sometimes be resolved by clearing the browser cache - but not always.  Also - we have unconfirmed reports that the problem can "resolve itself" after several weeks.
From my perspective it looks like one of the following scenarios is causing the problem:
The Flash Player is caching content in a location other than the browser cache and reaches a limit.  The cache is not overwriting content so then fails to download any new content.
The Flash Player experiences a problem which prevents it from downloading content (corrupt files, registry issue, or policy restriction).
We have several other customers who access this content at different sites - and none have reported this specific issue, so we are confident that the delivery mechanism is sound.  The customers workstations are generally new machines with plenty of capacity, and they have a 200 Mb leased line connection to the Internet.  The customer has assured us they do not use a caching proxy server on site, nor any bandwidth optimisation tools so in theory, the client connection is direct to the Internet.  Additionally - the fact that this issue affects isolated workstations suggests the problem lies at the endpoint - not in the transmission path.
Has anyone encountered this type of issue before - or does anyone have any knowledge of Flash Player caching operations?
Regards

Answer 1

IE will roll cache like any other browser. Keep as much as the user allows and start recycling when that gets filled. At no point will IE "fill up" on any single or multiple sites and be unable to download any more content. Downloading is all a browser does and Flash is not excluded from that unlimited party. However if you never remove content properly and continue to download endless content, you could encounter RAM issues. You don't have unlimited RAM so you may be hitting a wall. But as long as you're disposing any content you loaded that you no longer need, that isn't an issue.
You're going to need to install some custom logging if you really want to debug a clients client. The most popular thing a Flash application will do is fail silently and lock up because you did not provide any failsafe measures for various common issues. From common crossdomain policy issues to flaky connections failing in the middle of a download, you need to handle all these situations and act appropriately. If any content is failing to load in Flash you can be sure if you try {} catch () {} you'll be given a top level chance to send out a log notice to yourself. That's of course assuming you have the standard IOErrorEvent, SecurityErrorEvent, etc already in place to also log.
If you had access to the offending machines then opening the developer tools in IE and using the network manager would be the easiest way to see what's going on. If you click to load more content and see no network request, the requesting itself has an issue (could be a million reasons). If you see the request go out then you'll either see it fail in the middle or complete. If it fails you should have code to handle that. If it completes and the app still locks up, you probably have ABC that isn't playing nicely and should be "caught" and logged.
There's just no one way to approach this. Only layers of error handling and logging are your best friends when it comes to debugging this kind of thing.
Personally I've seen clients boast they have XMbit lines and their network is otherwise perfect, when it had old grade (100mbit) eth cables and the little things that schools and large companies tend to overlook in the long run. It's easy to replace a faulty switch or eth card but in-wall cable, not so often.