545783 - BSOD triggered when accessing Inbox or Other Folders

Status: RESOLVED INVALID

(MailNews Core :: Database, defect)

Description

[Lee]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1

TB Crashes taking out entire system with BSOD or complete system non-responsiveness after attempting to access the messages in the Inbox (or any other folder).
My Inbox has some 8000 messages in it.
On some occasions (before attempting to access inbox obviously) status bar shows "Determining which messages to index" continually with progress bar in 'indeterminate state' i.e. green bar just scrolling around.
After accessing inbox status bar states that TB is indexing some messages, the total number of messages keeps climbing, although it looks like TB triggers the BSOD / system lockup when it gets to the end of the indexing.
Appreciate that a BSOD is hardware or Kernel driver related - but only TB triggers this behaviour - no other applications or software are blundering into this.  Also my system is service packed to the eyeballs, all drivers etc are up to date.

Reproducible: Always

Steps to Reproduce:
Setup. Use Inbox with a large number of messages in it (at least 8,000).  Ensure that at least 1% are unread.  Total number of messages across all folders should exceed 25,000.
1. Start in Safe mode (or regular, your choice)
2. Attempt to delete or move (to other folders) large numbers of the messages, including some of the unread ones.  Trigger the folder compression.
3. (Maybe) shut down TB before it has finished the folder compression, and reopen it.  Objective is to get the mail store to a fragmented state.
4. With mail store somewhat fragile now try accessing the Inbox as per Step 2.  After a certain time period (few minutes progressively getting worse to a few seconds) TB will trigger the problem.
Actual Results:  
BSOD or System lockup.

Expected Results:  
Completed the compression and/or indexing and returned.

No Crash ID, no crash log whatsoever.  It seems that whatever TB is doing to trigger the problem it just blunders into it.

Comment 1

[Tyler Downer [He/Him]]

Well, TB can't cause a BSOD, so this has to be something else on your system that doesn't like thunderbird and is crashing. Try disabling your firewall, anti-virus, get all the latest updates for windows, update your graphics card, etc.

Comment 2

[Lee]

(In reply to comment #1)
> Well, TB can't cause a BSOD, so this has to be something else on your system
> that doesn't like thunderbird and is crashing. Try disabling your firewall,
> anti-virus, get all the latest updates for windows, update your graphics card,
> etc.
With all due respect Tyler - NEXT TIME TRY READING THE BUG REPORT - As I stated I already know that TB can't be the actual 'ultimate cause' but TB is definitely 'triggering' the BSOD and it is ONLY TB that is doing this.
Further, my system has every service pack and every driver updated - AS STATED.

This event is caused by my engaging in specific (and very normal) behaviour with TB, it is not random.  In other words TB is doing something wrong and not dealing with a serious error situation properly (probably disk related), not the other way around.  TB is not the 'ultimate cause' but it is defintely the one and only trigger on my system.

Try setting up 50,000+ messages with at least 12,000 in one folder alone.  Of those messages have at least 5% with attachments of varying size between a few kB to a few MB.  In other words repeat what I described above and see how TB behaves.  If you really want to push it take TB up to 100,000 messages.

Comment 3

[Tyler Downer [He/Him]]

Lee, calm down. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html.
I was just pointing that out for the record. Have you tried disabling your firewall and/or anti-virus (firewalls have caused this before).

Comment 4

[Lee]

Sorry Tyler - but please remember that etiquette goes both ways - like actually reading the bug report before firing off a 'standard' text.
And yes I have already tried using TB with my AV packages turned off (running Avira and Threatfire).
There appear to be at least two and possibly three things that TB is doing simultaneously that lead to it triggering the BSOD.
1. Indexing messages (or determining messages to index).
2. Possibly(probably) compressing folders.
3. Activities related to displaying a message selected by the user in a given folder (i.e. my activity).

In my use of TB I get large numbers of email messages a day (usually a few hundred) that I quickly review and usually delete more than 99% of them - They are automated alerts from various systems.  This means that my inbox and other folders are getting compressed often throughout the day.
It seems that my activity of simply working with actual messages initiates some sort of vicious cycle that eventually (and currently fairly quickly) leads to TB engaging in activity that triggers the BSOD.  I have some event in my systems event log that imply this is disk related.  So perhaps it is to do with TB not handling disk contention issues properly as it is indexing and compressing.

Comment 5

[Tyler Downer [He/Him]]

Lee, please settle down and don't take stuff personally alright?

when you said safe mode, do you mean thunderbird safe mode or windows safe mode?

Comment 6

[Lee]

Hi Tyler
(In reply to comment #5)
> Lee, please settle down and don't take stuff personally alright?
I'm a Kiwi, we don't take stuff personally - but we do talk bluntly.  My apologies if you find the tone too direct.

> when you said safe mode, do you mean thunderbird safe mode or windows safe
> mode?
Thunderbird Safe mode.

Comment 7

[Nathan Tuggy (:tuggyne)]

Can you check Thunderbird's memory usage in Task Manager when this happens? (Right-click on the taskbar, choose Task Manager, Processes tab, search for Thunderbird.exe; you'll probably also need to add Memory: Commit Size to the column display by choosing View -> Select Columns….)

Also, what are the BSOD details? You'll probably need to check the Event Log for details; by default Windows doesn't leave the blue screen up long enough to see much. To do this, open the Start menu and type eventvwr.msc into the Search box, then press Enter; expand the Windows Logs node in the left pane, and choose System. Once in there, look for recent log entries marked Error or Critical and having something to do with a blue screen, kernel error, or similar -- if you can pinpoint the exact time and look only at entries around that time, it will save you hassle. (I wish I could be more specific, but the computer I have right now hasn't had any blue screens within the last six months or more.)

BTW, Lee, it's not everyone that has nearly this many emails; this is a good opportunity to examine Thunderbird's behavior with this particular stress load. Hopefully we can get to the bottom of it efficiently.

Comment 8

[Wayne Mery (:wsmwk)]

if this is triggered by TB in safe mode, it may correlate to backend or database.

what's the *file* size of your largest folder in your profile?

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

I am sorry to hear about the crashes.  This sounds like Thunderbird is giving the system a comprehensive workout and that is triggering the crash.

I would suggest you use a tool like memtest86+ (http://www.memtest.org/) to verify that your memory is good, and if that fails (since the load could also involve thermal issues and what not) move on to a burn-in test problem.

Unless you move your profile to a completely separate system (not even the hard disk should be the same) and are able to reproduce the problem, I do not think we can begin to consider that Thunderbird is involved in the problem.

This is fundamentally a support issue and I see that this already is a getsatisfaction issue which is the proper venue.  As such, I am marking this bug invalid.

Having said that, support/QA peeps, while your efforts to support system crashes are noble and to be commended, it is probably not an efficient use of time.  I would suggest that we have a page on our SUMO instance that points people at tools like memtest+ and some burn-in tests or other resources they can use to attempt to diagnose their hardware problems.  I would otherwise limit support/QA focus to analyzing patterns if large numbers of BSODs are reported with some obvious correlation.  Ideally there would be so many people with the problem that they can even find out what they have in common without much hand-holding.  Only once it's clear there's some underlying issue that affects a lot of users and that there is some mitigation Thunderbird can document/alert the user to their system problems/work around them should a bug get filed.

Comment 10

[Lee]

(In reply to comment #7)
> Can you check Thunderbird's memory usage in Task Manager when this happens?
> (Right-click on the taskbar, choose Task Manager, Processes tab, search for
> Thunderbird.exe; you'll probably also need to add Memory: Commit Size to the
> column display by choosing View -> Select Columns….)
Hi Nathan,

At the moment TB is taking the system down too fast for me to get an accurate handle on memory consumption - It was high, but not as high as Firefox ;-)

> Also, what are the BSOD details? You'll probably need to check the Event Log
> for details; by default Windows doesn't leave the blue screen up long enough to
> see much. To do this, open the Start menu and type eventvwr.msc into the Search
> box, then press Enter; expand the Windows Logs node in the left pane, and
> choose System. Once in there, look for recent log entries marked Error or
> Critical and having something to do with a blue screen, kernel error, or
> similar -- if you can pinpoint the exact time and look only at entries around
> that time, it will save you hassle. (I wish I could be more specific, but the
> computer I have right now hasn't had any blue screens within the last six
> months or more.)
I poked around through the eventviewer already.  All I was able to determine is what I commented on above.  There was a series of ATAPI (IDE driver failures).  However, according to a later system event (after I had restarted my laptop) these occurred after my system had nominally gone down - I don't know how that works as I haven't written a driver for any windows software since Windows NT.

> 
> BTW, Lee, it's not everyone that has nearly this many emails; this is a good
> opportunity to examine Thunderbird's behavior with this particular stress load.
> Hopefully we can get to the bottom of it efficiently.
I hope so to.  My apologies to Tyler above, I was a little harsh on him, but it is a common misconception that only hardware or bad drivers cause BSODs and that replacing hardware or updating drivers will magically fix them.  In programming we often have to work around the bugs of others, reducing the stress on a system to its minimum is always a good idea.  I fear that my use of Thunderbird isn't helping in this area.

Comment 11

[Lee]

(In reply to comment #8)
> if this is triggered by TB in safe mode, it may correlate to backend or
> database.
> 
> what's the *file* size of your largest folder in your profile?
The largest *folder* (Inbox) has a file size of 623Mb.
The largest actual (on-disk) folder is Archives at 1.1Gb.
The global-messages-db.sqlite file has a size of 233Mb.

All up that profile is 2.8Gb.

Comment 12

[Lee]

(In reply to comment #9)
> I am sorry to hear about the crashes.  This sounds like Thunderbird is giving
> the system a comprehensive workout and that is triggering the crash.
> 
> I would suggest you use a tool like memtest86+ (http://www.memtest.org/) to
> verify that your memory is good, and if that fails (since the load could also
> involve thermal issues and what not) move on to a burn-in test problem.
I'll give it a go.  I have tried some other system testing tools, but not that particular one.  And yes this system does run hot (more correctly I push it very hard).

> Unless you move your profile to a completely separate system (not even the hard
> disk should be the same) and are able to reproduce the problem, I do not think
> we can begin to consider that Thunderbird is involved in the problem.
I'll try this.  However, when writing for a large number of platforms (such as you do) we don't always get the good fortune to have a system where bugs in hardware and drivers stay well hidden.  I hope I've been sufficiently clear that Thunderbird is definitely *involved* in the problem.  However, I agree that TB is not the ultimate cause.

> This is fundamentally a support issue and I see that this already is a
> getsatisfaction issue which is the proper venue.  As such, I am marking this
> bug invalid.
I would have thought that "WorksForMe" was the more correct answer ;-)

> Having said that, support/QA peeps, while your efforts to support system
> crashes are noble and to be commended, it is probably not an efficient use of
> time.  I would suggest that we have a page on our SUMO instance that points
> people at tools like memtest+ and some burn-in tests or other resources they
> can use to attempt to diagnose their hardware problems.  I would otherwise
> limit support/QA focus to analyzing patterns if large numbers of BSODs are
> reported with some obvious correlation.  Ideally there would be so many people
> with the problem that they can even find out what they have in common without
> much hand-holding.  Only once it's clear there's some underlying issue that
> affects a lot of users and that there is some mitigation Thunderbird can
> document/alert the user to their system problems/work around them should a bug
> get filed.
Unfortunately if I'm at the extreme end of Thunderbird users then there's never going to be "a lot of users" with such a problem - My circumstances would represent a valuable test case though (boundary condition).  Having said that I'll still run the hardware tests (and others) to eliminate what hardware issues that I can.
I do have a background in programming (if you count 20+ years), and especially with systems that must work with large volumes of data.  With having watched this fault many times over now, I am left with the distinct impression that Thunderbird is "not playing nicely with the others" and that this is the contributing factor that pushes my laptop over the edge into BSOD.  It 'fits the pattern'.

Comment 13

[Wayne Mery (:wsmwk)]

(In reply to comment #12)
> > This is fundamentally a support issue and I see that this already is a
> > getsatisfaction issue which is the proper venue.  As such, I am marking this
> > bug invalid.
> I would have thought that "WorksForMe" was the more correct answer ;-)

WorksForMe implies/means the issue was related to something previously wrong in thunderbird, i.e. the problem has gone away or is not reproducible.

Comment 14

[timeless]

BSOD's aren't are fault <period>. If you want to chase your problem, you should follow these instructions from microsoft to enable saving a memory.dmp:

http://support.microsoft.com/kb/235496

You can then use windbg (file>open crash report) after your system blue-screen's:
https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg

If you need further assistance with your crash, you can ask for help from our support team:
http://support.mozilla.com/chat

please understand that our bug tracker is not the correct destination for BSODs, and as such, you will not receive a warm welcome. I'm sorry if you feel you were mistreated.