Closed Bug 265172 Opened 20 years ago Closed 18 years ago

Hang and 100% CPU usage sometimes during restore/resume from sleep/standby/hibernate - update your flash player

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: rg, Assigned: bugzilla)

References

Details

(Keywords: hang, perf, Whiteboard: fixed by Flash Player 9.0.2 http://www.adobe.com/products/flashplayer/public_beta/)

Attachments

(1 file)

comon
264.00 KB, application/x-msdownload
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

The basic scenario is that I am using a laptop which I move frequently but
almost never shutdown.  I go on and off wired and wireless networks several
times per day.  Perhaps 25%-50% of the time, Firefox pegs the CPU when I am
restoring from sleep mode.  This makes the wake-up take forever.  

It seems to be related to the fact that there's no network available; yesterday
CPU usage spiked right after I disabled my wireless card.  (Which I always do
using the plug/play icons in the taskbar.)

Firefox usually returns to normal behavior after a few minutes, although
sometimes it can take up to 15-20 minutes.

Admittedly, I haven't got a 100% reproducible scenanrio here.  But it happens to
me several times a week, and is very frustrating.


Reproducible: Didn't try
Steps to Reproduce:
1. See above.
2.
3.
Severity: normal → major
Keywords: perf
I also have this same problem when recovering from a suspended system.  I use
Thuderbird 0.7.2 as well as Netscape 7.1.   Whenever one of them enters this
state, they both do.   Ie they each peg at 50% CPU.  I have tried letting them
run for an hour or so, but they never return to normal CPU levels.   It doesn't
appear to happen if I suspend for an hour or so.  But if I suspend over night
and then it will happen about 25% of the time.

Thuderbird:
version 0.7.2 (20040707)

Netscape:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Netscape/7.1 (ax)

My platform is a Japanese XP Home edition SP0 with all non-SP patches up to date.

Other than this issue, I love both of these products.  Keep up the great work guys.

Cheers,
Leif
I can reproduce this problem consistently on both 

Windows 2000 used at home: Firefox/1.0 

Windows XP used at work: Mozilla/5.0 Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0

I'll have to update this comment from home to give details of the precise binary
on my Win 2000 box.

The scenario to recreate the problem is as follows:
I hibernate the system with Firefox running (the number of tabs open is
irrelevant).  Upon restore, the cpu is pegged at 100% consistently.  

On Windows 2000, the system will "come back" after 15-20 minutes as reported in
the original report.  On my Windows XP laptop the system comes back in about 2
minutes.  BUT, my Win 2000 system is an old Pentium-II 300 MHz with 128 MB RAM,
while my XP system is a Pentium-M 1.6 GHz with 512 MB RAM.  I don't know if this
is an issue or not.

My solution has been to close Firefox before hibernating.  The problem will
never appear upon restore.  

At home I have a cable modem always connected and on.  The same at work, where I
have a constant 100-Base T network connection.  




(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3)
Gecko/20040913 Firefox/0.10.1
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3)
Gecko/20040913 Firefox/0.10.1
> 
> The basic scenario is that I am using a laptop which I move frequently but
> almost never shutdown.  I go on and off wired and wireless networks several
> times per day.  Perhaps 25%-50% of the time, Firefox pegs the CPU when I am
> restoring from sleep mode.  This makes the wake-up take forever.  
> 
> It seems to be related to the fact that there's no network available; yesterday
> CPU usage spiked right after I disabled my wireless card.  (Which I always do
> using the plug/play icons in the taskbar.)
> 
> Firefox usually returns to normal behavior after a few minutes, although
> sometimes it can take up to 15-20 minutes.
> 
> Admittedly, I haven't got a 100% reproducible scenanrio here.  But it happens to
> me several times a week, and is very frustrating.
> 
> 
> Reproducible: Didn't try
> Steps to Reproduce:
> 1. See above.
> 2.
> 3.


As mentioned on Mozillazine, here are reproducible ways of making the problem
show up.  It has to do with the clock difference between when the machine is
hibernated, and when it wakes up.  

Steps to Reproduce:

1. Start Firefox
2. Go to a site with flash, eg www.jibjab.com
3. Hibernate your computer.
4. Upon power-up, go to BIOS before windows resume begins 
5. Set time forward by 1 day or more
6. Save bios changes and let startup continue

Actual Results
--------------
The machine takes many minutes to come out of hibernate.  Firefox's CPU usage is
at 100% (or 50% when Thunderbird is also running).  The longer you set your
clock forward, the longer it takes for the machine to come out of hibernate.

Expected Results
----------------
The machine takes the 20 seconds or so to come out of hibernate.

Note that without Firefox running or with Firefox on "about:blank", wake up is
instantaneous regardless of the amount of time the clock is moved forward. 
Flash pages in Internet Explorer also don't affect the time the computer takes
to come out of hibernate.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have also experienced this as well. Closing all the tabs do not help - I have
to close and reopen Firefox in order to regain my CPU. I have never waited for
it to fix itself.

Bruce
This is almost certainly some sort of tick/clock-catchup gone haywire -- perhaps
where Firefox thinks it owes Flash all ticks for the amount of time since last
check, even if that amount of time is hours instead of milliseconds. Thus it's
probably also an easy fix: if I think I owe more than X ticks, just deliver
fewer. (I don't think it's exclusively a Flash problem because it doesn't occur
in IE.)
I installed Microsoft Bootvis (a boot analyzer) to try to see what's going
wrong.  I tried to test two sets of things.

Programs Running
----------------
1. Nothing running
2. Only Firefox running with page at about:blank
3. Only Firefox running with page at www.tsn.ca (has flash on the page)

How long Hibernating
--------------------
1. Restore immediatly
2. Restore immediatly, but change the BIOS clock by 1 complete day

Thus I ran Bootvis under 6 scenarios

Scenarios
---------
1. Firefox not running, restore immediatly
2. Firefox not running, restore after changing clock
3. Firefox running with about:blank, restore immediatly
4. Firefox running with about:blank, restore after changing clock
5. Firefox running with www.tsn.ca, restore immediatly
6. Firefox running with www.tsn.ca, restore after changing clock

I will attach the saved Boot analyzing files to this bug.  The information about
what drivers were loaded and how long they took can be seen by opening the files
in Bootvis and viewing the Summaries.

Basically what I saw, was that under all scenarios except for 6, things were
normal (almost all of the drivers that were loaded were the same, and they took
approximately the same time).

Under scenario 6, however, ACPI.sys (the Advanced Configuration and Power
Interface), which did not appear for other scenarios, appears for more than 60
seconds.  All other drivers also take much longer to load, and I think this is
because Firefox was at 100% CPU utlization. (Firefox is at 100% CPU utilization
after the system has completley started)
The traces for the 6 Scenarios can be found here

http://www.eecg.utoronto.ca/~nazizi/traces.zip

(the files were too big to attach)
This bug is still a problem as of this very moment, and it has been for years.
It's not just Firefox, either--it also applies to the Mozilla Suite, version
1.7.11. Any idea when it's going to be fixed? My laptop seems to be overheating
every 10 minutes thanks to mozilla.exe...
Bugs https://bugzilla.mozilla.org/show_bug.cgi?id=251111 and
https://bugzilla.mozilla.org/show_bug.cgi?id=305330 may be the same or related.

I experience the problem when there is a Flash plugin involved. My laptop then
takes forever to come out of sleep mode. Sometimes I can provoke it to snap out
of it by unplugging USB mouse or just tapping on the trackpad.

Firefox used to sit at 100% after coming back from sleep mode, but with recent
builds of Deer Park, it seems to behave. Even so, the sleep mode hang is still
there.
*** Bug 305330 has been marked as a duplicate of this bug. ***
It seems to me there are two problems/bugs involved, which may have separate
origins:

1] After running for some time Firefox/Mozilla causes CPU usage to rise to and
remain at 100%. The application and the rest of the computer can still be used,
but it is slow. This can only be cured by killing the application completely.
Reproducibility unknown.

2] Firefox/Mozilla cause a long delay during the hibernation wake-up sequence.
During this delay the computer is completely unusable. When the wait is over,
computer and application can be used normally. Reproducibility, see Navid's
useful comments #3, #6 and #7.

Both problems occur independantly of eachother. I have suffered both for a long
time when using the Mozilla suite and I can ensure that they can be most
annoying. It would be great if someone could fix these!
> 2] Firefox/Mozilla cause a long delay during the hibernation wake-up sequence.
> During this delay the computer is completely unusable. When the wait is over,
> computer and application can be used normally. Reproducibility, see Navid's
> useful comments #3, #6 and #7.
> 
> Both problems occur independantly of eachother. I have suffered both for a long
> time when using the Mozilla suite and I can ensure that they can be most
> annoying. It would be great if someone could fix these!

I don't know about your first problem, but I see #2 EVERY MORNING when I resume my laptop after suspending at night.  This is unbelievably irritating, to the point where IE is looking favorable.

Someone, please, fix this!

Paul
This may be related to bug 290963 and bug 311810.
I can report that my Firefox 1.5 (Build 2005111116) does often have 95% CPU after resuming from suspend mode.
I've had this on two different laptops, both running Windows XP. One was a Compaq Evo N800v, and my current laptop is a Lenovo Thinkpad X41 Tablet. Before a standby or hibernate everything is working properly, when resuming Firefox 1.5.0.1 (and earlier versions) consume 100% CPU, making the resuming process take about 5 minutes. If I kill and restart Firefox everything works again. It happens about 50% of the time, and it usually (but not always) happens when I've been using Firefox hard: lots of tabs, flash animations, opening of PDF's, etc.

I have reverted to shutting Firefox down before going into standby, fortunately the extension Sessionsaver makes that a lot easier to handle.
The way I experience this problem:

1) Open morning news sites.
2) Open all interesting stories in tabs (total of about 15 tabs open now)
3) Close lid (causes standby)
4) Some time later (30 min), open lid.
5) Windows XP resume process takes FOREVER.  Anywhere from 5 minutes to >15 (so I just do a hard power-off and reboot, losing all data in other programs)
6) If I do wait patiently through the glacial resume, I find Firefox at 99-100% CPU utilization.
7) All Firefox winows must be completely closed and firefox.exe must disappear before a new Firefox instance will use 0% CPU at idle.

This happens every day at least if I am not careful. I have gotten in the habit of saving all open tabs to bookmarks and exiting all Firefox windows before standby.  I suspect pages with Flash need to have been loaded to cause the problem.

I think bug 313846 and bug 303972 are duplicates of this one, and bug 290963 and bug 311810 appear related if not duplicate--I see a similar issue with thunderbird.exe occasionally.

I am happy to do additional diagnostics if someone will recommend them to me.
Links to forum posts at mozillaZine complaining of this issue. Most people resort to IE or blocking flash content.  Seems to apply to resuming from either suspend or hibernate.

Firefox:
http://forums.mozillazine.org/viewtopic.php?t=239338
http://forums.mozillazine.org/viewtopic.php?t=333231
http://forums.mozillazine.org/viewtopic.php?t=344360
http://forums.mozillazine.org/viewtopic.php?t=342044
http://forums.mozillazine.org/viewtopic.php?t=309902
http://forums.mozillazine.org/viewtopic.php?t=228928
http://forums.mozillazine.org/viewtopic.php?t=351768
http://forums.mozillazine.org/viewtopic.php?t=365101


Thunderbird:
http://forums.mozillazine.org/viewtopic.php?t=349516
http://forums.mozillazine.org/viewtopic.php?t=259999

My FF version string:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

My Flash version:
    File name: NPSWF32.dll
    Shockwave Flash 8.0 r22
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1)
Gecko/20060111 Firefox/1.5.0.1

I have the habit to keep several Tabs and Windows opened. 
Often when I resumed the laptop from hyberantion Firefox reach 100% CPU.
Even closing some Tabs or Windows Firefox keep 100% CPU.
The only way to resume from this situation is to close all Firefox windows.

Reproducible: Sometimes

Steps to Reproduce:
1.Open some pages Firefox Windows.
2.Open some pages in different Tabs. 
3.Hyberante the laptop.
4. REsume from the hybernation status.

Actual Results:  
Firefox reach 100% CPU.

Expected Results:  
Continue to work properly.

Please find here a screen shoot of one of the Firefox window, process explorer
(sysinternals) that is showing firefox threads detail.

http://img50.imageshack.us/img50/2882/firefox1004th.png

Note: I had to switch the Firefox process priority to "Below Normal" to use the
PC.

*** Bug 328122 has been marked as a duplicate of this bug. ***
NOTE:
I tryed config.trim_on_minimize = false but it does NOT solve the BUG.
Very tediuos situation... is anybody working to solve it?
I am think to switch back to IE or Opera.
*** Bug 310401 has been marked as a duplicate of this bug. ***
*** Bug 299203 has been marked as a duplicate of this bug. ***
*** Bug 311810 has been marked as a duplicate of this bug. ***
*** Bug 313846 has been marked as a duplicate of this bug. ***
*** Bug 303972 has been marked as a duplicate of this bug. ***
The patch for bug 179056 might also fix this.
Can anyone confirm?
To confirm (and to repost some info in Bug 311810):
- This happened on my Dell Inspiron (I no longer have this machine)
- This happens on my current laptop (Asus based; home-built)
- 100% CPU is used (sometimes, I'd say that 20-30% is probably quite accurate)
on resume from both sleep (suspend to RAM) and hibernate (suspend to disk)
- I'm using: ff1.5, tbird1.5 it still hapens with both of these (It happened in
the 1.0x series, too)
- This affects ALL mozilla-based software (as far as I can tell): I've seen my
CPU split 4 ways (~25% each): 1/4 FF, 1/4 TBird, 1/4 Sunbird, 1/4 Komodo

The last one is particularly interesting. There's no flash in Komodo, guaranteed.

I'm on Windows XP Pro.

S
> - I'm using: ff1.5, tbird1.5 it still hapens with both of these (It happened in
the 1.0x series, too)
Could you please test using latest nightly?
It SEEMS that the last version has not the problem:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060302 Firefox/1.5.0.1

Although it takes ages to restore from the Hybernation.

Regards,
       Cris
I am sorry. The problem is still there.
However this version takes more time to restore the system from the hybernation.

Regards,
  Cris
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060302
> Firefox/1.5.0.1
Sorry, your report does not very help.
The problem will be only fixed on trunk (Fx3) or 1.8 branch (Fx2).
Can anyone test on *latest trunk* nightly?
Tomorrow I will do it.
Can you just specify the exact link where I should download the version?
Is it this one: 
ftp://ftp.mozilla.org/.1/mozilla/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-1.6a1.en-US.win32.zip

?

I downloaded version version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060306 Firefox/1.5.0.2

Till now is working fine. It was able to resume from Hybernation twice in few minutes and the CPU is not at 100%.
Because it is an alpha.
I asked which one I have to try. 
The nightly directory is very busy and it is not easy to understand which one I should try.
I wanted to check if 1.5.0.2 solved the problem.
However verson 1.5.0.2 has the same problem.
It seems that only some sites trigger the problem.

Today I will try 1.6a1.
I unzip Firefox 1.6a1 in the Program Files folder. It crashed at the startup.
I am sorry.
Attached file comon — 
actchuli 1 read stupid so dont depend on me
Comment on attachment 214785 [details]
comon

what a bugger
I have a related problem with Firefox 1.5 when exiting of hibernate mode on Windows.
I reported crashes using the Talkback Agent (look for my e-mail : dolmen bigfoot com):
- yesterday: Firefox crashed when restoring the system after hibernate during an hour. After that every attempt to start Firefox failed: I got a friefox.exe process running (about 13 Mb), but no window. Killing it and restarting did not work. I had to reboot Windows.
- today: after hibernate Firefox was working without problem (no apparent slowdown as reported by others) and I could continue to browse the page for minutes. However Firefox crashed at the time I clicked on a link to another page. After that Firefox crashed at every startup (-> different from yesterday). I reported this third crash with the Talkback Agent.

Please tell me if you prefer I open separate bugs for the 'hibernate crash' and the 'startup crash'.

As this is a crash case I suggest to set the severity to critical.
Bug 330632 is probably about the same issue.
Could someone verify that jpeg_free_large (https://bugzilla.mozilla.org/attachment.cgi?id=215197) is also involved in this bug?

Process Explorer is available here: http://www.sysinternals.com/Utilities/ProcessExplorer.html
hotbot: Sometimes when the CPU is 100% jpeg_free_large is the module that is consuming the CPU.

I saw that if you enable the "Work Offline" the CPU becomes normal and go back to 100% when you disable it.

In this moment it's 100%.
Process Explorer give me 4 active threads: 2 are msvcrt.dll!endthreadex+0x3a, one is firefox.exe and another is WINMM.dll!timeGetSystemTime+0x44.

This issue is really bothering me. 
If you need more data let me know. 

This bug is still NEW and has never been change to "Accept bug (change status to ASSIGNED)"
Is anyone trying to solve it? 
Do you know when and in which version it will be solved ?

Regards
I guess that there are more one bugs in the code that are causing the 100% CPU after restoring the PC from an hybernation.

What surprise me is that anybody among the developers is not taking care to write what it could be, trying to solve it, or saying when it will be analized and solved.

Bugs like this one in a production version drive away users from Firefox.


FYI, while I experienced exactly this problem on my old computer (XP, Firefox 1.0) with both 100% CPU usage and slow restores from hibernation, on my new system (XP64, Firefox 1.5 [never had 1.0 installed, started with a new profile]) I've only thus far experienced the latter.

Once the system has actually booted, everything is fine and I'm not getting 100% CPU.  But sometimes it's literally taking half an hour to start up out of hibernation.  And it's most definitely something in Firefox (or associated plugins) -- if I close Firefox and hibernate, I get near-instant startup.  If I reopen Firefox (reloading my previous session) and hibernate, boom, long startup times again.  If I reset my Firefox session and hibernate, it'll usually behave ok, but at some unidentified point in the future (perhaps once I've loaded sufficient pages, or certain types of page content) it all goes to pot again.

My current version is Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1.
I am running XP Home SP2 with all updates, and the current releases of Firefox and Thunderbird.  I tried Firefox 1.6a1 and it still has the problem. 

This problem seems to be some interaction between the network connection (wired or wireless) and running Firefox along with another program that automatically accesses the network at startup.  

With Firefox open on a site with Flash content, and either Thunderbird open with option turned on to check for new messages on startup, or Outlook open with option turned on to send immediately when connected, the system will lock up when resuming from standby or hibernate.  

- Any one of these three by themselves work fine.  
- Works ok if you disable the network connection before going to standby or hibernate.
- You can have all three open if you disable Flash content (using Flashblock) or only open a site that does not have Flash.  
- You can use a site with Flash if the mail options listed above are turned off. It will work ok for a short disuption but will take a few minutes to resume from overnight.  
- Seems to work better if you do not use DHCP.

I suspect that the operating system is telling applications that the network interface is ready before it has established an IP address.  I don't have the tools to prove this.  When I look at the system event log, there is a Tcpip entry that the network adapter has been started, followed by a DHCP entry that it was not able to renew the network address. Outlook also reports connection errors after startup, indicating it tried to use the network before it was ready.  Could Firefox be getting stuck in a loop that ties up the CPU until the network connection is really available?
I was working for a week with my laptop putting it in hybernation status when I don't use it.

I am working with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060316 Firefox/1.5.0.2

Till now it has not the problem of 100% CPU when it resumes from hybernation.

Problems:
1 - FF still takes few minutes to recover.
2 - Memory has reached 917.604KB. I noticed that it still growing few KB at the time. There are memory leaks
I was working for a week with my laptop putting it in hybernation status when I don't use it.

I am working with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060316 Firefox/1.5.0.2

Till now it has not the problem of 100% CPU when it resumes from hybernation.

Problems:
1 - FF still takes few minutes to recover.
2 - Memory has reached 917.604KB. I noticed that it still growing few KB at the time. There are memory leaks

Regarding FF still takes few minutes to recover. I read somewhere else that it is cause by swapping pages from disk to memory.
However it's strange because when the PC is recovering from the hybernation the led of the HD is off most of the time.

Hope that it will help.

After 8 day the problem came out. 100% CPU in Version 1.5.0.2.
Memory reached 1.6Gb.

I downloaded the 1.5.0.2 of today. I hope it will work!
Last 1.5.0.2 has the problem.

I found interesting the description of bug 325384. It is about SeaMonkey but it is probably related with the long time to recover from standby.

In Comment #25 Masatoshi Kimura (emk) says:

>The patch for bug 179056 might also fix this.
>Can anyone confirm?

Has version 1.5.0.2 this patch ?
(In reply to comment #47)
> Has version 1.5.0.2 this patch ?
No, I'm planning to make it when someone confirmed with 1.8 branch or trunk.
Note that my patch may not solve the problem about networks (see comment #42). So I didn't marked bug 290963 as a dup.
Hi Masatoshi,
Thank you for your quick answer.

I don't understand exactly how the version numbers work here at mozilla.

However I tried 1.6a1 and it crashed at startup. 1.6 had also problem with MAF plug-in that seems not to be compatible.

Could you try to patch the last 1.5.0.2 and write here the link where I can download it. I will be happy to test you patch for some weeks. Probably other people will be happy to test it.

Regarding the network problem I have a dial-up connection. I am not sure I can test that problem. 

Is this bug related with bug 325384 ?

Thank you again for your work in the open-source community.
*** Bug 206341 has been marked as a duplicate of this bug. ***
Cris, can you test the Bon Echo release (it's firefox 2.0 alpha1) http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/bonecho/alpha1/

It should have the patch from bug 179056. Also, try with a new profile. That means no extensions.


Thank you Marius.
Unfortunately I don't have time to test FF full time. But I like FF and I would be glad to test while I am using it for other tasks.

I really need to have the Mozilla Archive Format, and (till now) Session Saver plugins installed. I also use FasterFox and Magpie.

If you know how make them work on alpha 2.0 and how can I easily backup and upgrade my profile (I have a some saved passwords) I can try version 2.0.

Otherwise I will be happy to test the patch of this bug on version 1.5.0.2.
How long does it that to apply the patch to version 1.5.0.2 (or 1.5.0.1)?
Congratulations, the Bon Echo alpha1 release fixes the issues that I observed in comment #42. My system no longer locks up when resuming from standby or hibernate.  

However the original problem as described in comment #3 is still present.  The system will be slow to resume after extended periods in standby or hibernate (they both appear to behave about the same).  The delay is almost directly dependent on the hibernate time (about 10 seconds of delay per hour, less for more than 20 hours).  I verified this using the steps in comment #3, advancing the time by hours instead of days.  This happens whether I use a new profile (no extensions) or my normal profile (with extensions).

The Bon Echo release has a new problem where a few minutes after resuming from hibernate, it will sometimes suddenly exit on its own.  It then runs fine after I restart it.  I have not figured out the specific conditions for this yet.

I can confirm that Firefox takes longer and longer to come out of standby (on WinXP Pro SP2) as you increase the amount of time it is in standby.  Sometimes this is accompanied by Firefox running at 100% cpu utilization (requiring a restart of FF to fix), but usually not.

When I used to use Opera I observed this same behavior (taking a long time to come out of standby).  IE does not do this.
Ditto.  Without Firefox running, resume from hibernation takes about 30 seconds on my machine.  With it running, and hibernated for about 3/4 of a day, resuming takes about six minutes.  After hibernating for three or four days, resuming takes half an hour.

It's entirely possible that this is a bug in the Flash plugin, or some other related plugin, rather than directly in Firefox (IE and Firefox use different plugins, don't they?)  But even if that's the case, still the *perception* is that it's a Firefox-specific problem, and I think it's in the developers' best interest to track it down and get it sorted out :)
jpeg_free_large freeze used to happen to me all the time - in fact, every time Firefox freezes on me, the jpeg_free_large thread shows 100% CPU, as often as I checked.

Meanwhile, especially since Firefox 1.5, those freeze has been less frequent, although not gone. In last last few days I've experienced some of those freezes in with some thread pages of a forum website. Interestingly, the pages that cause jpeg_free_large freeze also tend to cause IE to hang, too.

I'm not aware of any particular Flash content, plus Moz and IE use different Flash plugins. My intuition is that the freeze has something to do with badly writte JavaScripts, as the software used for the forum, Dvbbs (a fairly popular Chinese forum software) is known for notoriously extensive and chaotic JavaScript usage.

So my question for now is, does jpeg_free_large has much to do with Moz's DOM?
I've made a Fx 1.5.0.2 + patch build.
http://www.oersted.co.jp/~emk/2006/04/fx1.5.0.2+179056.zip
SHA1 hash: 25eca44e483999c83860ad72f0773963961c17d0
Thank you very much.
I don't understand why it is called Deer Park and has a different icon but I have installed it. I will let you know this night I will hibernate my laptop.


Best regards.
(In reply to comment #58)
> I don't understand why it is called Deer Park and has a different icon but I
> have installed it. 
because I have no permission to use Firefox brand.
Any unofficial build should not built with --enable-official-branding unless the builder obtains a permission from Mozilla Foundation.
Other build options are the same (you can verify build options to type "about:buildconfig" into your location bar).
I tried the patched 1.5.0.2 build from comment #57 without success.  My laptop still requires approximately 2-3 extra seconds for every minute in standby to wake back up if I leave this build running.
Has anyone contacted Macromedia and asked them about it?  Like I said in comment #55, it could very well be a bug in the Flash plugin code, not the Firefox code.  Perhaps that's why it doesn't occur in IE -- because a different plugin is used in that case.  (See also comment #54, which says that Opera does the same thing as Firefox.  Does Opera use the same Flash plugin as Firefox, or is it different?)

If both browsers are showing the same behaviour (though I cannot confirm that, since I haven't used Opera enough to verify it), then the problem must lie in something that's shared by both browsers.  What else is there?  Surely they didn't snaffle some Mozilla code?
It seems the Fx 1.5.0.2 + patch build works well to prevent 100% CPU after restoring the PC from the hibernation. 
Unfortunately it still takes ages to recover from the hibernation.
I downloaded the Flash 8.5 beta plug-in and the Flashblock Firefox's extention.
I will test them next time I restart firefox.
RE: #61

I've reported this issue to Macromedia via their online form. Never got any acknowledgement.

It *could* be strictly the plugin's problem, but I suspect most of the code is identical for the IE and Mozilla plugins, suggesting seomthing specific to the Firefox interface/environment is to blame.

I'm amazed this remains uninvestigated by those in-the-know. It's trivial to reproduce (for example by rolling the BIOS clock forward before resuming from hibernation) and very frustrating for anyone with an affected notebook. 

I'd guess it has something to do with a timing loop that's trying to catch-up to wall-clock time after waking -- eg when it sees 24 hours have passed, it insists on delivering 864,000 of some 10-per-second tick event, rather than just a single catchup tick. 
It's not just notebooks, either.  I routinely hibernate my desktop system (because I don't like leaving it on, and I don't like closing everything down).  I've had to retrain myself to close Firefox before hibernating, which is aggravating (though not as aggravating as when I forget to).  Fortunately Session Saver makes this a lot less hassle, but the problem really does need to get fixed.  Where are the devs?
re: Macromedia

As I mentioned, I've seen this behaviour happen in Firefox, Thunderbird, Sunbird and Komodo (CPU split 4 ways on restore).

The Flash plugin might've been running in Firefox at the time, but it certainly wasn't running in Thunderbird, much less Sunbird or Komodo.

I guess it's possible that the resources are somehow shared between instances of Gecko, but to me, this indicates a problem with Gecko and not actually with the plugin. (Although I have no idea how to confirm this other than open up the other apps, sans flash and hope it happens again.)

S
(In reply to comment #65)
Did you test a patched build (without runnning Flash)?

This bug contains many different problem (Gecko's timer, Flash, network connections, etc.). Maybe we would reopen some bugs closed in comment #20 to #24 to split the each specific problem.
1) Firefox/1.5.0.2 release version resolves the issues in my comment #42.  I don't know whether this was due to the bug 179056 patch or maybe the bug 318419 patch.  I don't have any other network issues with respect to this bug.  

2) Firefox/1.5.0.2 no longer hangs the CPU usage after Windows finishes resuming from a long hibernate. 

3) Windows is still slow to resume from hibernate when using Firefox with Flash but this problem is also present in Netscape 8.1.  Firefox, Netscape, and Opera all use the same flashplayer plugin.  IE uses an ActiveX addon.  I would agree that this is a Macromedia problem.  Unfortunately, Macromedia does not respond to bug reports and does not provide a list of open bugs.  We will just have to wait and see if the report filed by Gordon has an effect (maybe someone at Mozilla can provide some pressure).

Perhaps this bug should be marked resolved (at least for Mozilla/Firefox) and any continuing issues with the CPU hanging due to changing network connections should move to bug 290963.

  
Jeff in Comment 67 suggests we close this bug, but how do we know for sure this bug is a problem with the Flash plugin?
(In reply to comment #67)
> 1) Firefox/1.5.0.2 release version resolves the issues in my comment #42.  I
> don't know whether this was due to the bug 179056 patch or maybe the bug 318419
> patch.
It's definitely the bug 318419. Bug 179056 is not landed on 1.8.0 branch.
I downloaded the Flash 8.5 beta plug-in and the Flashblock Firefox's extention.
I have tested them for 2 days.
You must consider that I am not enabling all the flash stuff I had before in the pages (Flashblock's been working fine) however I don't have the slow backup from the the hibernation anymore :)

I have only 2 thing to signal:
1 - I don't like that my Firefox is now called "Deer Park" and has a blue logo (I was used to the one with the orange fox and now I am not able to recognize the the browser as fast as I was used).
2 - I cannot sometimes use the copy and paste. They are sometimes disabled in the context menu. I've also experienced that I cannot switch from a tab to another clicking on the tab bar. This is weird and I have experienced it only on the "Fx 1.5.0.2 + patch build". I am going to switch back to official 1.5.0.2 keeping the Flash 8.5 beta plug-in and the Flashblock Firefox's extention to see what happens. 

I definetly suggest you to test Flash 8.5 beta plug-in.
Its interesting that slow return from hibernation is gone when you block Flash.  But I don't understand why do you need the latest Flash beta if you are blocking Flash?

Also, this doesn't prove that its a problem with Flash, it may be a problem with the interactions between Firefox and Flash when the clock is advanced significantly.

(In reply to comment #70)
> I downloaded the Flash 8.5 beta plug-in and the Flashblock Firefox's extention.
> I have tested them for 2 days.
> You must consider that I am not enabling all the flash stuff I had before in
> the pages (Flashblock's been working fine) however I don't have the slow backup
> from the the hibernation anymore :)
> I have only 2 thing to signal:
> 1 - I don't like that my Firefox is now called "Deer Park" and has a blue logo
> (I was used to the one with the orange fox and now I am not able to recognize
> the the browser as fast as I was used).
> 2 - I cannot sometimes use the copy and paste. They are sometimes disabled in
> the context menu. I've also experienced that I cannot switch from a tab to
> another clicking on the tab bar. This is weird and I have experienced it only
> on the "Fx 1.5.0.2 + patch build". I am going to switch back to official
> 1.5.0.2 keeping the Flash 8.5 beta plug-in and the Flashblock Firefox's
> extention to see what happens. 
> I definetly suggest you to test Flash 8.5 beta plug-in.


Probably I was not clear enough.
I am using both the Flash 8.5 beta plug-in and the Flashblock Firefox's extention.
Flashblock Firefox's extention disable the Flash content by default but you can enable clicking on the icon inside the blocked content. Before entering the hibernation I've enabled some contents but not them all.

I have not time to test Firefox extensively "just for test" but I can do while I am working on it. I think you can use what I wrote to test it. I am quite happy with the Flash 8.5 beta plug-in and the Flashblock Firefox's extention (See comment #70). I suggest to test just Flash 8.5 beta plug-in and see what happens.
I am running FF 1.5.0.2.  Today I experienced the problem where, upon coming out of standby, Firefox goes to 100% CPU utilization.  So that's not fixed yet either.
(In reply to comment #73)
* Are you running Flash Player?
* What's your network connection?
* Does my patch solve the problem?
Yes, I am running flash 7,0,19,0

The cpu jumped to 100% when I went into standby from my home wireless network then came out of standby on our corporate wired network which has a proxy server.  Firefox was configured to use the proxy server at the time (ie not "Direct connect to Internet").

I haven't tried your patch; which problem does it address (slow coming out of hibernation or 100% cpu utilization)?  Can you point me to it and I may be able to load it.

(In reply to comment #74)
> (In reply to comment #73)
> * Are you running Flash Player?
> * What's your network connection?
> * Does my patch solve the problem?
> 

1) I tried the Flash 8.5 (now 9.0) beta. It does nothing to fix the slow resume from extended hibernation.

2) I went back to FF 1.5.0.1 to retest the 100% CPU problem and found it now worked the same as Bon Echo alpha1 and FF 1.5.0.2, even after I uninstall all and just install FF 1.5.0.1.  The bug 179056 patch may be what fixed it but its uninstall is not removing all components.  The FF 1.5.0.2 release by itself may still have this problem.  Bill, try installing the patch load in comment #57.  It will still be slow to resume from hibernate, but should not hang the CPU.

3) FF 1.5.0.2, Netscape 8.1 and Opera 8.5 all behave exactly the same when hibernating while viewing a site with flash. Can someone with access to the FF code identify whether this in the Flash plugin or in the way the functions are called by FF?  I agree this bug should not be closed until it has been confirmed that the problem is not in FF. 
Just got the 100% cpu hang again, and I didn't even switch networks.  Was at home, went into standby overnight, this afternoon I came out of standby and FF was at 100%.
People, as I've noted above, I don't think this issue is Flash-only, as IE *does* have problems with the same pages.

The key question is, what is jpeg_free_large *doing* (or, what it is supposed to be doing) when it claims 100% CPU? Could anyone please take a look at that?
Hi again,
A lot of things can cause a 100% CPU (a loop in a Javascript can probably do it). This bug is about 100% CPU AFTER resuming from the Hibernation/StandBy.
I've seen Firefox stucked at 100% CPU while I was visiting a page but I don't think it is related with this problem.

I am not also sure that the jpeg module is the problem. Everytime I go in the Threads tab of the Properties of Firefox with Process Explorer the first thread is always on firefox.exe!jpeg_*+0x*. The problem is the "+ big number to be the same subroutine". Maybe the jpeg library is the only one that is exporting symbols and this is the reason why everything you see regarding firefox.exe thread is relative to this library. Maybe a developer can clarify this point.

Coming back to the "Hang and 100% CPU usage sometimes during restore" bug, I think Flash plug-in it's definetly a problem. People here says that Opera has the same problem (And Opera is using the same plug-in). I wonder if M$ is pressing Macromedia not to solve the bug in their plug-in (since the IE version has not it)...

One thing: I am using the version fx1.5.0.2+179056 by Masatoshi Kimura (See comment #57). I experienced some times that the Copy and Paste in a text box are disable. One way to renable them is to click on another tab and go back on the tab in which you wanted to use Copy and Paste. I've sometimes also experienced that I am unable to switch a tab with another. I wonder if this behaviour is a side effect of patch 179056.

Masatoshi, are you sure that you applied the patch 179056 on a clean 1.5.0.2 version without any other modifications?

Regards,
   Cris
(In reply to comment #79)
> Masatoshi, are you sure that you applied the patch 179056 on a clean 1.5.0.2
> version without any other modifications?
Yes.
Probably copy and paste problem is bug 220900. It also occurs on may official builds. I don't know why you didn't see the problem when using official build.
> may official
many official

Sorry for the typo.
Re: #78

I cannot reproduce a similar problem in IE. Specifically, I can open a dozen pages with Flash in IE6 (separate windows), hibernate, wait 1 day (or forward the clock in bios settings), and then resume from hibernate with no noticeable delays or maxed CPU.

If I open those same dozen windows in Firefox (1.5.0.2), hibernate, wait 1 day (or forward the clock via the bios), then resume from hibernate, two unique annoyances are obvious: (1) at the end of the 'Resuming Windows...' progress screen, there is a long period, sometimes minutes, where the screen is blank before the desktop (slowly) appears; (2) as soon as the desktop appears, the CPU utilization is maxed, with the firefox process showing 99% usage, for 10 minutes or even much, much longer -- during which time it is impossible to even move the mouse pointer. (I leave the task manager up before hibernating.)

It is those unique pauses -- blank-screened and when the desktop appears but is unusable -- that are of concern in the Friefox+Flash combination.

I've tried the Flash Player 8.5 beta; it was no help. 
(In reply to comment #79)
> I am not also sure that the jpeg module is the problem. Everytime I go in the
> Threads tab of the Properties of Firefox with Process Explorer the first thread
> is always on firefox.exe!jpeg_*+0x*. The problem is the "+ big number to be the
> same subroutine". Maybe the jpeg library is the only one that is exporting
> symbols and this is the reason why everything you see regarding firefox.exe
> thread is relative to this library. Maybe a developer can clarify this point.

I'm not a Firefox developer, but I'll give it a shot:
firefox.exe!somefunction+0x10000 only means "in Firefox.exe, 0x10000 bytes past the start of somefunction". This could very well be in a completely different function whose location is unknown to Process Explorer. AFAIK it has no way to tell where a function ends.
Bug 179056 is landed on 1.8.0 branch now.
It's better to use latest nightly 1.8.0 branch than my unofficial build if you can't wait until Fx 1.5.0.3 release.
hello !

after a LONG LONG search and loosing my nerves many time with this damn bug, i cam across this one today:

http://support.microsoft.com/?scid=kb%3Ben-us%3B889673&x=18&y=12

i always expected this to be a problem with the OS - not with applications.

i cannot tell for sure that this will cure your problems (don`t have enough time to test it in depth) but i think, it`s worth a try:

If you stay in hibernation for more than just some couple of minutes the hibernation resume takes ...lets say ages in win XP SP2. This is caused by the Data Execution Prevention (DEP). To make everything work normally again use one must turn this off.
You cannot do this in windows but need to apply a switch into the bootloader:
/NoExecute=AlwaysOff

My c:\boot.ini looks now like this:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /NoExecute=AlwaysOff

This cures the skype pronblem and also many others. I used the bat file trick for a while until some other service got installed that caused similar effects. Only after applying the boot time switch the resume started working normally again. Microsoft is aware of the problem already and is working on a hotfix.

will report, if i know, that this is the fix for this problem.
please let me know, if it worked for you.

regards
roland k.
systems engineer
(devzero@web.de)
(In reply to comment #85)

> If you stay in hibernation for more than just some couple of minutes the
> hibernation resume takes ...lets say ages in win XP SP2. This is caused by the
> Data Execution Prevention (DEP). To make everything work normally again use one
> must turn this off.
> You cannot do this in windows but need to apply a switch into the bootloader:
> /NoExecute=AlwaysOff

The same problem exists on SP1, where AFAIK is no DEP.
And AFAIK on regular x86 (without 64-bit CPU) DEP doesn't actually do anything anyway (because the hardware support is lacking).
Flash Blocker works wonders.  No longer do I have any problems coming out of standby, and Firefox uses far less CPU in general, since Flash is not running ads in (practically) every window any more.
I don't think Microsoft patch is related with this problem.
I use Firefox 1.5.0.3. I have no 100% freezing.
I am using Flashblock 1.5.1 and it works great.
Only when I decide to open some flash and I forgot to close the related window FF still takes ages to resume from hibernation.
Since Opera has the same problem and it use the same flash plug-in I would press Macromedia to fix this bug in the Flash Player.

Let's try to press them to fix it.
Everybody who has the problem please report it here: 
http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
and here :
http://www.adobe.com/bin/fp9betafeedback.cgi

Cris
I submitted this (it might help if we all use similar wording):

When I am running Firefox with a web page containing Flash content, then put my machine into standby, it takes a very long time to resume from standby later.  The time to resume is proportional to the time spent in standby, and can run to several minutes.

(In reply to comment #89)
> I don't think Microsoft patch is related with this problem.
> I use Firefox 1.5.0.3. I have no 100% freezing.
> I am using Flashblock 1.5.1 and it works great.
> Only when I decide to open some flash and I forgot to close the related window
> FF still takes ages to resume from hibernation.
> Since Opera has the same problem and it use the same flash plug-in I would
> press Macromedia to fix this bug in the Flash Player.
> 
> Let's try to press them to fix it.
> Everybody who has the problem please report it here: 
> http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
> and here :
> http://www.adobe.com/bin/fp9betafeedback.cgi
> 
> Cris
> 


Hey dudus, good news! This is the email I got back:

Hi Cristiano,

Thank you for your bug report.

This bug has been fixed in the most recent beta, so if you update your Flash Player to the latest beta version you should see this issue go
away:
http://labs.adobe.com/technologies/flashplayer9/

Thanks again.

- Michelle
Unfortunately, I erroneously told Cristiano in comment 91 that this bug was fixed. My apologies as I was thinking of a separate issue.

We (the Flash Player team) will investigate this bug. Thanks for bringing it to our attention.
Michelle,

Since this bug report is somewhat all over the place, I encourage you to look at Comment 91 to see what the issue, as currently defined by this group, is.

- Bill

(In reply to comment #92)
> Unfortunately, I erroneously told Cristiano in comment 91 that this bug was
> fixed. My apologies as I was thinking of a separate issue.
> 
> We (the Flash Player team) will investigate this bug. Thanks for bringing it to
> our attention.
> 


Sorry!  I meant to say comment 90, not Comment 91

(In reply to comment #93)
> Michelle,
> 
> Since this bug report is somewhat all over the place, I encourage you to look
> at Comment 91 to see what the issue, as currently defined by this group, is.
> 
> - Bill
> 
> (In reply to comment #92)
> > Unfortunately, I erroneously told Cristiano in comment 91 that this bug was
> > fixed. My apologies as I was thinking of a separate issue.
> > 
> > We (the Flash Player team) will investigate this bug. Thanks for bringing it to
> > our attention.
> > 
> 


Also, comment 6 and comment 7 refer to reproducible ways of producing the bug, and boot analyzer logs during return from hibernate
In reply to comment #95)
> Also, comment 6 and comment 7 refer to reproducible ways of producing the bug,
> and boot analyzer logs during return from hibernate
> 

We have identified the issue. The NetScape plugin on Windows uses multimedia timers to do most of its timing. Information on this can be found here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_timesetevent.asp

What it does not say here is that during a suspend/resume cycle, the multimedia timer events will be queued up, meaning we get all events which were supposed to happen since the suspend when you resume. Not good. That's the reason machines become unusable.

We have fixed this so that we respond to WM_POWERBROADCAST and shut down these timers before a suspend (BTW, suspend is called hibernate in the Windows UI).

Information on WM_POWERBROADCAST:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/power/base/wm_powerbroadcast.asp

Currently we do not get any PBT_APMSTANDBY message to handle standby. For this we have added a secondary fix which will try to kill pending clogged timers in case you should ever run into this case.

This fix could make it into the next public FlashPlayer release, I can't give promises or exact dates, since it's not up to me to make these decisions.

Thanks to all Macromedia team! Hopefully we will have the patch soon.
Could you notify here as soon as the plug-in with this patch will be downloadable on the Macromedia site (even if it is just another beta)?

Anyway... I wonder why this bug has not ever been in the IE plug-in...

Cris
(In reply to comment #97)
> Thanks to all Macromedia team! Hopefully we will have the patch soon.
> Could you notify here as soon as the plug-in with this patch will be
> downloadable on the Macromedia site (even if it is just another beta)?
> 
> Anyway... I wonder why this bug has not ever been in the IE plug-in...
> 
> Cris
> 

Cris, 

the ActiveX/IE plugin does not have this problem since it does not depend on the multimedia timer Win32 API. It uses an ActiveX specific API instead which does not have this problem during a suspend. It is in general more advanced and accurate compared to the bare Win32 APIs. More information here:

http://msdn.microsoft.com/library/default.asp?url=/workshop/browser/timer/timer.asp

These services are not available to NetScape style plugins in Windows, otherwise we would have used them.

Tinic, 

Is there the possibility of working with Mozilla so that you can receive the PBT_APMSTANDBY message to handle standby in your plugin?  Many here use standby instead of hibernate.

- Bill

(In reply to comment #98)
> (In reply to comment #97)
> > Thanks to all Macromedia team! Hopefully we will have the patch soon.
> > Could you notify here as soon as the plug-in with this patch will be
> > downloadable on the Macromedia site (even if it is just another beta)?
> > 
> > Anyway... I wonder why this bug has not ever been in the IE plug-in...
> > 
> > Cris
> > 
> 
> Cris, 
> 
> the ActiveX/IE plugin does not have this problem since it does not depend on
> the multimedia timer Win32 API. It uses an ActiveX specific API instead which
> does not have this problem during a suspend. It is in general more advanced and
> accurate compared to the bare Win32 APIs. More information here:
> 
> http://msdn.microsoft.com/library/default.asp?url=/workshop/browser/timer/timer.asp
> 
> These services are not available to NetScape style plugins in Windows,
> otherwise we would have used them.
> 


Flash Player 9.0.2 beta includes these corrections.  I installed it yesterday and no longer have any problems with slow restore.  It works for both hibernate and standby (at least when reconnecting to the same network).  

You can get it at http://www.adobe.com/products/flashplayer/public_beta/

Someone needs to verify that this fixes the problems with changing networks while in standby. If there are no other issues resuming from hibernate/standby, this bug should probably be closed. Any other 100% CPU issues should move to a different bug.
Finally they did it!
This bug is finally closed! 
I can believe it!

Finally I can say that Firefox is a better browser than Internet Explorer!
Marking FIXED per comment #100.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
In case the reference to Adobe's bug database is useful, here is a quote from the blog post about this in http://weblogs.macromedia.com/emmy/archives/2006/06/public_beta_ref.cfm:

"(171132) Bringing PC out of hibernate mode takes longer after viewing flash content in Firefox. Also reported to Firefox as https://bugzilla.mozilla.org/show_bug.cgi?id=265172"

There seem to be quite a few issues being talked about in this bug... which issue are we talking about specifically, and which is fixed?
The fix is to the issue where FireFox takes a long time to come out of standby or hibernate when web pages with Flash are displayed.  The 100% CPU hang when returning from standby or hibernate also seems, incidently, to be fixed as I have not experienced it in a long time.

(In reply to comment #104)
> There seem to be quite a few issues being talked about in this bug... which
> issue are we talking about specifically, and which is fixed?
> 


Bill - the other hang doesn't seem fixed, it's just hard to hit.

For people still seeing the problem coming back from standby/after any sort of connection interruption - bug 213637
improve summary (a good thing to do when the solution is not available from mozilla) and may as well resummarize - 

solution: get new version of flash player http://www.adobe.com/products/flashplayer/public_beta/

references:
http://msdn.microsoft.com/library/default.asp?url=/workshop/browser/timer/timer.asp
http://weblogs.macromedia.com/emmy/archives/2006/06/public_beta_ref.cfm
"(171132) Bringing PC out of hibernate mode takes longer after viewing flash
content in Firefox."
Keywords: hang
Summary: Hang and 100% CPU usage sometimes during restore → Hang and 100% CPU usage sometimes during restore/resume from sleep/standby/hibernate - update your flash player
Whiteboard: fixed by Flash Player 9.0.2 http://www.adobe.com/products/flashplayer/public_beta/
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: