1308783 - Windows 10 hangs up to 90 seconds when Windows search service is enabled, and "Allow Windows Search to search messages" is unchecked/disabled

Status: RESOLVED INCOMPLETE

(Thunderbird :: OS Integration, defect)

Description

[tlhackque]

Thunderbird compose hangs periodically when writing a message.  (Includes reply.)

The hang is total - the cursor stops blinking, moving the mouse over UI elements doesn't change them.  No TB window (main or compose) will accept focus or allow itself to be dragged.  The hang has been timed at up to 90 seconds.

The hang seems to happen after an automatic or manual save to drafts.

After the hang, some type-ahead is entered, but some is lost.

As others have reported (different variants), this started with Windows 10.  I am running the Anniversary update (patched thru today), but these hangs occurred with W10 prior release.  Prior to that, I ran W7 Ultimate - no issues.

I have tried the usual suggestions - turn off firewall/Anti-Virus, TB safe mode, Windows Safe mode, delete .msf files, rebuild global search index - to no effect.  I have also tried moving the Drafts folder to a local folder from IMAP - no effect.  Neither does disabling power management.

Running TB in windows 7 compatibility mode does not help.

BUT, I now have a reproducer and some more diagnostic information.

I do NOT have "Allow Windows Search to search messages" checked.

I DO have TB's Global search and Indexer enabled.

Reproducer:
  Open a new e-mail.  Put anything in the Subject, and type random garbage into the message box.  After a line or two, press ^S to save the message, and as soon as the dialog box goes away, resume typing.  After a few words - how many varies - TB will hang as described.

When the hang stops, type some more, press ^S and the hang will repeat.

If you wait for an auto-save (Mine is set for 5 minutes), this will also occur more often than not.

Open the Services panel and Stop the Windows Search service.
The hang will immediately end.  And the process described will no longer reproduce.

Start Windows search again.  The process will again reproduce.

Given that, Open an explorer folder and set "view hidden files".

Open Indexing Options.  Note that AppData IS excluded.  But select 'Users' anyway.  Click 'Modify', then 'Users' in the summary.  Work your way down to AppData {locallow, local, roaming} and to the Thunderbird directory of each.  Uncheck the boxes and close.  This explicitly adds the Thunderbird directories to the Exclusion list.  Restart the Windows Search service.

This does NOT make the hangs stop.

Bottom line:  There appears to be an interaction between TB and the Windows Indexer, even when both TB and the Indexer are configured to ignore each-other.

This interaction freezes the GUI thread of TB - all TB windows.

Other applications are NOT hung.

This does not appear to be due to the usual suspects: anti-virus, db corruption, etc.  It reproduces or not depending on whether Windows Search  is running.

Comment 1

[Wayne Mery (:wsmwk)]

Unfortunately you have friends https://mzl.la/2doAD6n

Are your thunderbird profile and accounts stored in their default location?  If not, where exactly did you put them?

And now big is windows.edb in C:\ProgramData\Microsoft\Search\Data\Applications\Windows ?

Comment 2

[tlhackque]

Thanks for the quick note.

I know I'm not the first, but no one else seems to have gotten to a reproducer.  I see "unconfirmed" and "Invalid" and snake oil :-)  The others have startup issues (I don't), work in safe mode (I don't), are blamed on AV (doesn't seem to be the case here), have search integration enabled (I don't), have high CPU (I don't) ... So after reviewing all of those bugs and trying the suggestions, I decided to open a separate bug.

Yes, default location.  Specifically: 

C:\Users\timothe\AppData\Roaming\Thunderbird\Profiles\h4daj8zo.default
C:\Users\timothe\AppData\Local\Thunderbird\Profiles\h4daj8zo.default

LocalLow has nothing.

C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb is 1,652,555,776 bytes

Note that Windows Search is supposed to be ignoring TB, so I'm not sure why Windows.edb would matter.

FWIW, C is a 2TB drive with about 860GB free.  (The machine has a second (almost empty) 2TB drive.)

Comment 3

[tlhackque]

It gets curiouser.  I disabled Windows search service and (as usual) left TB open overnight.

With TB idle (only the main window open), every once in a while the GUI is frozen.  That is, moving the mouse over the list of messages has no effect.  (Normally it would highlight each message.) And clicking on any tab also has no effect.  This clears after a long pause - probably the same 60-90 seconds, but I  don't catch the beginning.

Task manager shows TB up to about 15% - of an i7 950 (4 cores, 8 threads, ~3GHz).  So that's one CPU.

It looks as though there's more than one cause.  Or perhaps the root cause affects the Search service which then cascades to TB?  The previous behavior seemed too reproducible to be coincidental.

Watching TB with Task manager during the last episode, I saw the private working set steadily climbing from 793.4K to 895.8K.  It then dropped back to 880.7K and at that point CPU dropped to 0 and TB became responsive.

So something(s) consumed about 100MB of memory, then released it.  Could the hang be garbage collection?

The error console has no entries around the time of the event.

A subsequent event 780K ish (didn't catch beginning), climbed to ~804K, dropped down to 794K and became responsive.  So this time only ~25K...

There is plenty of physical memory available - about 7 of 18 GB is in use.

Are symbols available for released versions of TB?  I could attach to the process with Visual Studio and try to get a handle on where the computes are going...  I know nothing about TB internals, but I ought to be able to collect some stack traces.

I would like to get to the bottom of this... It's very painful.

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to tlhackque from comment #3)
> ...
> Are symbols available for released versions of TB?  I could attach to the
> process with Visual Studio and try to get a handle on where the computes are
> going...  I know nothing about TB internals, but I ought to be able to
> collect some stack traces.
> 
> I would like to get to the bottom of this... It's very painful.

See https://developer.mozilla.org/en-US/docs/Mozilla/How_to_get_a_stacktrace_with_WinDbg#Start_debugging 
As documented at https://developer.mozilla.org/en-US/docs/Mozilla/Using_the_Mozilla_source_server I suggest you use a nightly build so you can use the source server. 

In both documents, substitute "thunderbird" for "firefox" in but directory names and urls

Comment 5

[Wayne Mery (:wsmwk)]

p.s. I think it's great that you are putting in effort to get to the bottom of this. To that end, Although the size of your Windows.edb does not seem excessive, I suggest that you do not delete Windows.edb (and let it rebuild) until you have a better sense of what is happening.

Below are a collection of articles about windows.edb
http://www.howtogeek.com/howto/windows-vista/speed-up-or-disable-windows-search-indexing-in-vista/
http://www.online-tech-tips.com/computer-tips/simple-ways-to-increase-your-computers-performace-turn-off-indexing-on-your-local-drives/
http://winaero.com/blog/fix-windows-search-fills-your-hard-drive-with-a-large-edb-file/
https://www.google.com/search?q=KB2836988&num=20&safe=off&biw=1115&bih=668&source=lnt&tbs=qdr:y&sa=X&ved=0ahUKEwjSj-Dgns7PAhXGqB4KHTQNClkQpwUIFQ
https://support.microsoft.com/en-us/kb/2836988
http://www.aidanfinn.com/?p=14540
https://social.technet.microsoft.com/Forums/en-US/1ff5a6a8-e984-45ab-b8e2-4d3f25c52ef1/the-windowsedb-file-grows-very-large-in-windows-2012-r2-standard?forum=winserver8setup
http://www.networksteve.com/windows/topic.php/The_Windows.edb_file_grows_very_large_in_Windows_8.1._perm_solut/?TopicId=75367&Posts=0
https://www.google.com/search?q=%22Windows.edb%22+size&num=20&safe=off&biw=1115&bih=668&source=lnt&tbs=cdr%3A1%2Ccd_min%3A3%2F1%2F2016%2Ccd_max%3A&tbm=
https://support.microsoft.com/en-us/kb/2838018
http://winaero.com/blog/fix-windows-search-fills-your-hard-drive-with-a-large-edb-file/
https://www.experts-exchange.com/questions/28965858/Defrag-Index-EDB-Windows-Server-2012-R2.html
http://lowendguru.com/2016/03/windows-edb-file-big-fix/
https://social.technet.microsoft.com/Forums/en-US/eb90d103-ee67-4d09-8ee3-e86fb559d943/the-windowsedb-file-grows-very-large-in-windows-81?forum=w8itprogeneral

Comment 6

[tlhackque]

Some progress.  Part of what I see can be blamed on CardBook - but not the hangs with plugins disabled.

[Pain can be a great motivator.]

This work was done with Windows search disabled to simplify the problem.

I use VS Community 2015, not windbg, but despite the source server page comment, it was happy to load symbols & sources from Mozilla. So I'm sticking with 45.3.0 rather than introduce another variable.

First attempt:  I attached to TB while hung.  We're deep inside the JS JIT.  It's not obvious how to map from the call arguments to the JS text.  Clues?

I stepped back out, but eventually hit an ACCVIO - which may be a debugger artifact.  I don't see these normally.

I setup again, and got to a hang after a while.  FWIW, TB is using a lot less memory after being restarted... ~300-400K vs. 700 - 900. Perhaps it will grow.

I was able to find enough data by walking back the stack to determine that a stream was being setup to read vcf files.  That points to CardBook.

I use CardBook, synced to a Synology NAS running OwnCloud (also with Inverse SOGo Connector for calendar), about 450 contacts.  If I sync manually, the GUI hangs for about 5 seconds.  So there's something different about whatever it does in the background.  Normally I never do a manual sync... Of course, the automatic sync has no business being on the main thread.

I did observe that when I disabled just those two plugins, I didn't see a hang in a couple of hours of experimenting.

Re-enabling, I have seen a couple of 5-10 second hangs, so I've contacted the CardBook maintainer and asked him to help.  I suspect his automatic sync needs to run on its own thread...

However, there's still the matter of the longer hangs, which I've seen in this configuration (plugins enabled, search disabled.)  They appear to happen around the time of a save (auto or manual), so perhaps there's some resource contention/race that causes both to take longer. 

And as originally reported, I've seen the very long hangs with Plugins disabled and Windows search enabled.

I'll try to get some data from that configuration next.

Comment 7

[tlhackque]

One interesting thing about the hangs so far: break always seems to stop in a descendant of:

>	xul.dll!nsOSHelperAppService::GetByExtension(const nsString & aFileExt, const char * aTypeHint) Line 550	C++

Apparently, this is an expensive operation; perhaps it became so in Windows 10.

Digging further:

https://dxr.mozilla.org/mozilla-beta/source/uriloader/exthandler/win/nsOSHelperAppService.cpp looks like the source.

It seems to me that it should always be returning the same data, modulo any changes to the registry.

Perhaps it would be a good idea to implement a cache of results.  You can set a watch on the registry keys to invalidate the cache.  Or just ignore the issue - how often are MIME type assignments going to change?  Restarting TB wouldn't be the end of the world in that case...

I note that a different path is taken is for Vista+ that calls 'QueryCurrentDefault' -  which I haven't tracked down.  But that's where the time seems to be going.

http://undoc.airesoft.co.uk/ shows that QuerySourceCreateFromKey is accessing the registry.

As an experiment, a build of xul.dll that simply returned a constant answer for 'vcf' from 'GetTypeFromExtension' would be interesting...

Here's a typical stack trace:

 	AcLayers.dll!6f26f4cc()	Unknown
 	[Frames below may be incorrect and/or missing, no symbols loaded for AcLayers.dll]	
 	AcLayers.dll!6f2700ea()	Unknown
 	AcLayers.dll!6f26d7d1()	Unknown
 	AcLayers.dll!6f255668()	Unknown
 	SHCore.dll!_QuerySourceCreateFromKeyEx@24()	Unknown
 	shlwapi.dll!_QuerySourceCreateFromKey@20()	Unknown
 	shell32.dll!743c2d66()	Unknown
 	shell32.dll!7440a067()	Unknown
 	shell32.dll!7443438a()	Unknown
 	AcLayers.dll!6f255668()	Unknown
 	KernelBase.dll!75e11804()	Unknown
 	SHCore.dll!_QuerySourceCreateFromKeyEx@24()	Unknown
 	shlwapi.dll!_QuerySourceCreateFromKey@20()	Unknown
 	shell32.dll!744340c6()	Unknown
 	shell32.dll!74433f20()	Unknown
 	KernelBase.dll!75e11804()	Unknown
 	shell32.dll!744d8a84()	Unknown
 	KernelBase.dll!75e11804()	Unknown
 	shell32.dll!7445d221()	Unknown
>	xul.dll!nsOSHelperAppService::GetByExtension(const nsString & aFileExt, const char * aTypeHint) Line 550	C++
 	xul.dll!nsOSHelperAppService::GetMIMEInfoFromOS(const nsACString_internal & aMIMEType, const nsACString_internal & aFileExt, bool * aFound) Line 642	C++
 	xul.dll!nsExternalHelperAppService::GetTypeFromExtension(const nsACString_internal & aFileExt, nsACString_internal & aContentType) Line 2756	C++
 	xul.dll!nsExternalHelperAppService::GetTypeFromFile(nsIFile * aFile, nsACString_internal & aContentType) Line 2890	C++
 	xul.dll!nsFileChannel::MakeFileInputStream(nsIFile * file, nsCOMPtr<nsIInputStream> & stream, nsCString & contentType, bool async) Line 333	C++
 	xul.dll!nsFileChannel::OpenContentStream(bool async, nsIInputStream * * result, nsIChannel * * channel) Line 404	C++
 	xul.dll!nsBaseChannel::BeginPumpingData() Line 235	C++
 	xul.dll!nsBaseChannel::AsyncOpen(nsIStreamListener * listener, nsISupports * ctxt) Line 668	C++
 	xul.dll!NS_InvokeByIndex(nsISupports * that, unsigned int methodIndex, unsigned int paramCount, nsXPTCVariant * params) Line 71	C++
 	xul.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx, XPCWrappedNative::CallMode mode) Line 1381	C++
 	xul.dll!XPC_WN_CallMethod(JSContext * cx, unsigned int argc, JS::Value * vp) Line 1115	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 444	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const JS::Value & fval, unsigned int argc, const JS::Value * argv, JS::MutableHandle<JS::Value> rval) Line 496	C++
 	xul.dll!js::jit::DoCallFallback(JSContext * cx, js::jit::BaselineFrame * frame, js::jit::ICCall_Fallback * stub_, unsigned int argc, JS::Value * vp, JS::MutableHandle<JS::Value> res) Line 6162	C++
 	145658b1()	Unknown
 	1becd4c8()	Unknown
 	14560968()	Unknown
 	xul.dll!EnterBaseline(JSContext * cx, js::jit::EnterJitData & data) Line 148	C++
 	xul.dll!js::jit::EnterBaselineMethod(JSContext * cx, js::RunState & state) Line 184	C++
 	xul.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 381	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 465	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const JS::Value & fval, unsigned int argc, const JS::Value * argv, JS::MutableHandle<JS::Value> rval) Line 496	C++
 	xul.dll!js::CrossCompartmentWrapper::call(JSContext * cx, JS::Handle<JSObject *> wrapper, const JS::CallArgs & args) Line 289	C++
 	xul.dll!js::Proxy::call(JSContext * cx, JS::Handle<JSObject *> proxy, const JS::CallArgs & args) Line 391	C++
 	xul.dll!js::proxy_Call(JSContext * cx, unsigned int argc, JS::Value * vp) Line 683	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 432	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const JS::Value & fval, unsigned int argc, const JS::Value * argv, JS::MutableHandle<JS::Value> rval) Line 496	C++
 	xul.dll!js::jit::DoCallFallback(JSContext * cx, js::jit::BaselineFrame * frame, js::jit::ICCall_Fallback * stub_, unsigned int argc, JS::Value * vp, JS::MutableHandle<JS::Value> res) Line 6162	C++
 	145658b1()	Unknown
 	1becc1a8()	Unknown
 	1626f4ae()	Unknown
 	16ff3f08()	Unknown

Comment 8

[tlhackque]

Updates.

Some of the hangs were due to the CardBook plugin's periodic sync.  I've worked with the developer to improve it's sync performance; it's much improved.  For now, I've turned it off to get at the other issues.  This eliminated hangs for several days.

I turned Windows Search back on, and hangs resumed, even in TB safe mode.  They have increased in frequency since the most recent Windoze update (KB3199209), which may or may not be coincidental.  I've intentionally stayed with TB 45.3.0 to avoid introducing yet another variable.

Breaking during the hang has resulted in the two tracebacks below, the first more frequently than the second.  There's a loose correlation with sending or saving a draft message.  The main thread appears to be deleting a file - I assume something used for the draft.  It's stuck in ntdll.dll!_NtSetInformationFile@20, called from delete file. 

The sum total of this routine is a system service call, which I assume is marking the file for deletion:
_NtSetInformationFile@20:
77BCDE70  mov         eax,27h  
77BCDE75  mov         edx,offset _Wow64SystemServiceCall@0 (77BE2330h)  
77BCDE7A  call        edx  
77BCDE7C  ret         14h  
77BCDE7F  nop  

I don't see any indication that this call should block in MSDN...but it must lock the file handle in the process.

The caller is nsMessageComposeAndSend's destructor.

Could there be a deadlock with one of the other threads that's broken by a long timer?

Drafts and sent messages are on IMAP server - local LAN.  It's dovecot 2.2.25.

There are 76 threads active.  I think it's too much to post details here.  I took a minidump (3), which I can provide off-line.

These are worker threads:

 	ntdll.dll!_NtRequestWaitReplyPort@12()	Unknown
 	dwmapi.dll!CPortClient::SendComplexSyncRequestWow64(unsigned long,void const *,short,void *,short,long *)	Unknown
 	dwmapi.dll!CApiPortClient::SendRequest()	Unknown
 	dwmapi.dll!DwmFlush()	Unknown
>	xul.dll!D3DVsyncSource::D3DVsyncDisplay::VBlankLoop() Line 2919	C++
 	xul.dll!MessageLoop::RunTask(Task * task) Line 365	C++
 	xul.dll!MessageLoop::DeferOrRunPendingTask(const MessageLoop::PendingTask & pending_task) Line 375	C++
 	xul.dll!MessageLoop::DoWork() Line 459	C++
 	xul.dll!base::MessagePumpDefault::Run(base::MessagePump::Delegate * delegate) Line 35	C++
 	xul.dll!MessageLoop::RunHandler() Line 228	C++
 	xul.dll!MessageLoop::Run() Line 202	C++
 	xul.dll!base::Thread::ThreadMain() Line 175	C++
 	xul.dll!ThreadEntry(void * arg) Line 256	C++
 	ntdll.dll!__RtlUserThreadStart()	Unknown
 	ntdll.dll!__RtlUserThreadStart@8()	Unknown




 	ntdll.dll!_NtWaitForSingleObject@12()	Unknown
 	KernelBase.dll!_WaitForSingleObjectEx@12()	Unknown
 	KernelBase.dll!_WaitForSingleObject@8()	Unknown
>	nss3.dll!_PR_MD_WAIT_CV(_MDCVar * cv, _MDLock * lock, unsigned int timeout) Line 250	C
 	nss3.dll!_PR_WaitCondVar(PRThread * thread, PRCondVar * cvar, PRLock * lock, unsigned int timeout) Line 172	C
 	nss3.dll!PR_WaitCondVar(PRCondVar * cvar, unsigned int timeout) Line 525	C
 	xul.dll!mozilla::CondVar::Wait(unsigned int aInterval) Line 80	C++
 	xul.dll!TimerThread::Run() Line 566	C++
 	xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Line 972	C++
 	xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Line 297	C++
 	xul.dll!mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate * aDelegate) Line 355	C++
 	xul.dll!MessageLoop::RunHandler() Line 228	C++
 	xul.dll!MessageLoop::Run() Line 202	C++
 	xul.dll!nsThread::ThreadFunc(void * aArg) Line 378	C++
 	nss3.dll!_PR_NativeRunThread(void * arg) Line 419	C
 	nss3.dll!pr_root(void * arg) Line 95	C
 	msvcr120.dll!_callthreadstartex() Line 376	C
 	msvcr120.dll!_threadstartex(void * ptd) Line 354	C
 	kernel32.dll!@BaseThreadInitThunk@12()	Unknown
 	ntdll.dll!__RtlUserThreadStart()	Unknown
 	ntdll.dll!__RtlUserThreadStart@8()	Unknown

After a save draft, here's the main thread, which always seems to be stuck here:

 	ntdll.dll!_NtSetInformationFile@20()	Unknown
 	KernelBase.dll!_DeleteFileW@4()	Unknown
 	AcLayers.dll!NS_WRPMitigation::APIHook_DeleteFileW(unsigned short const *)	Unknown
>	xul.dll!nsLocalFile::Remove(bool aRecursive) Line 2385	C++
 	xul.dll!nsMsgComposeAndSend::~nsMsgComposeAndSend() Line 324	C++
 	xul.dll!nsMsgComposeAndSend::`scalar deleting destructor'(unsigned int)	C++
 	xul.dll!nsMsgComposeAndSend::Release() Line 257	C++
 	xul.dll!CopyListener::~CopyListener() Line 49	C++
 	xul.dll!CopyListener::`scalar deleting destructor'(unsigned int)	C++
 	xul.dll!mozilla::net::CacheStorage::Release() Line 24	C++
 	xul.dll!nsImapMailCopyState::~nsImapMailCopyState() Line 8265	C++
 	xul.dll!nsImapMailCopyState::`scalar deleting destructor'(unsigned int)	C++
 	xul.dll!mozilla::net::LookupArgument::Release() Line 124	C++
 	xul.dll!nsImapUrl::~nsImapUrl() Line 79	C++
 	xul.dll!nsImapUrl::`scalar deleting destructor'(unsigned int)	C++
 	xul.dll!nsMsgMailNewsUrl::Release() Line 57	C++
 	xul.dll!nsPop3URL::Release() Line 24	C++
 	xul.dll!nsImapMockChannel::~nsImapMockChannel() Line 8772	C++
 	xul.dll!nsImapMockChannel::`scalar deleting destructor'(unsigned int)	C++
 	xul.dll!nsImapMockChannel::Release() Line 8751	C++
 	xul.dll!mozilla::dom::workers::WorkerPrivate::SyncLoopInfo::`scalar deleting destructor'(unsigned int)	C++
 	xul.dll!nsTArray_Impl<nsCOMPtr<mozIVisitInfo>,nsTArrayInfallibleAllocator>::DestructRange(unsigned int aStart, unsigned int aCount) Line 2009	C++
 	xul.dll!nsTArray_Impl<nsCOMPtr<nsIDocShellTreeItem>,nsTArrayInfallibleAllocator>::RemoveElementsAt(unsigned int aStart, unsigned int aCount) Line 1655	C++
 	xul.dll!mozilla::dom::DeferredFinalizerImpl<nsISupports>::DeferredFinalize(unsigned int aSlice, void * aData) Line 2900	C++
 	xul.dll!mozilla::IncrementalFinalizeRunnable::ReleaseNow(bool aLimited) Line 1210	C++
 	xul.dll!mozilla::CycleCollectedJSRuntime::FinalizeDeferredThings(mozilla::CycleCollectedJSRuntime::DeferredFinalizeType aType) Line 1284	C++
 	xul.dll!mozilla::CycleCollectedJSRuntime::OnGC(JSGCStatus aStatus) Line 1323	C++
 	xul.dll!mozilla::CycleCollectedJSRuntime::GCCallback(JSRuntime * aRuntime, JSGCStatus aStatus, void * aData) Line 717	C++
 	xul.dll!js::gc::GCRuntime::gcCycle(bool nonincrementalByAPI, js::SliceBudget & budget, JS::gcreason::Reason reason) Line 6299	C++
 	xul.dll!js::gc::GCRuntime::collect(bool nonincrementalByAPI, js::SliceBudget budget, JS::gcreason::Reason reason) Line 6387	C++
 	xul.dll!js::gc::GCRuntime::gc(JSGCInvocationKind gckind, JS::gcreason::Reason reason) Line 6443	C++
 	xul.dll!JS::GCForReason(JSRuntime * rt, JSGCInvocationKind gckind, JS::gcreason::Reason reason) Line 7341	C++
 	xul.dll!nsXPCComponents_Utils::ForceGC() Line 2553	C++
 	xul.dll!NS_InvokeByIndex(nsISupports * that, unsigned int methodIndex, unsigned int paramCount, nsXPTCVariant * params) Line 71	C++
 	xul.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx, XPCWrappedNative::CallMode mode) Line 1381	C++
 	xul.dll!XPC_WN_CallMethod(JSContext * cx, unsigned int argc, JS::Value * vp) Line 1115	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 444	C++
 	xul.dll!Interpret(JSContext * cx, js::RunState & state) Line 2766	C++
 	xul.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 391	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 465	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const JS::Value & fval, unsigned int argc, const JS::Value * argv, JS::MutableHandle<JS::Value> rval) Line 496	C++
 	xul.dll!js::CrossCompartmentWrapper::call(JSContext * cx, JS::Handle<JSObject *> wrapper, const JS::CallArgs & args) Line 289	C++
 	xul.dll!js::Proxy::call(JSContext * cx, JS::Handle<JSObject *> proxy, const JS::CallArgs & args) Line 391	C++
 	xul.dll!js::proxy_Call(JSContext * cx, unsigned int argc, JS::Value * vp) Line 683	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 432	C++
 	xul.dll!Interpret(JSContext * cx, js::RunState & state) Line 2766	C++
 	xul.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 391	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 465	C++
 	xul.dll!Interpret(JSContext * cx, js::RunState & state) Line 2766	C++
 	xul.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 391	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 465	C++
 	xul.dll!js::fun_apply(JSContext * cx, unsigned int argc, JS::Value * vp) Line 1264	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 444	C++
 	xul.dll!Interpret(JSContext * cx, js::RunState & state) Line 2766	C++
 	xul.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 391	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 465	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const JS::Value & fval, unsigned int argc, const JS::Value * argv, JS::MutableHandle<JS::Value> rval) Line 496	C++
 	xul.dll!js::CrossCompartmentWrapper::call(JSContext * cx, JS::Handle<JSObject *> wrapper, const JS::CallArgs & args) Line 289	C++
 	xul.dll!js::Proxy::call(JSContext * cx, JS::Handle<JSObject *> proxy, const JS::CallArgs & args) Line 391	C++
 	xul.dll!js::proxy_Call(JSContext * cx, unsigned int argc, JS::Value * vp) Line 683	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 432	C++
 	xul.dll!Interpret(JSContext * cx, js::RunState & state) Line 2766	C++
 	xul.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 391	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 465	C++
 	xul.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const JS::Value & fval, unsigned int argc, const JS::Value * argv, JS::MutableHandle<JS::Value> rval) Line 496	C++
 	xul.dll!JS_CallFunctionValue(JSContext * cx, JS::Handle<JSObject *> obj, JS::Handle<JS::Value> fval, const JS::HandleValueArray & args, JS::MutableHandle<JS::Value> rval) Line 2790	C++
 	xul.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper, unsigned short methodIndex, const XPTMethodDescriptor * info_, nsXPTCMiniVariant * nativeParams) Line 1222	C++
 	xul.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex, const XPTMethodDescriptor * info, nsXPTCMiniVariant * params) Line 603	C++
 	xul.dll!PrepareAndDispatch(nsXPTCStubBase * self, unsigned int methodIndex, unsigned int * args, unsigned int * stackBytesToPop) Line 85	C++
 	xul.dll!SharedStub() Line 113	C++
 	xul.dll!mozilla::storage::`anonymous namespace'::CompletionNotifier::Run() Line 147	C++
 	xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Line 972	C++
 	xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Line 297	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate) Line 95	C++
 	xul.dll!MessageLoop::RunHandler() Line 228	C++
 	xul.dll!MessageLoop::Run() Line 202	C++
 	xul.dll!nsBaseAppShell::Run() Line 158	C++
 	xul.dll!nsAppShell::Run() Line 259	C++
 	xul.dll!nsAppStartup::Run() Line 282	C++
 	xul.dll!XREMain::XRE_mainRun() Line 4285	C++
 	xul.dll!NS_InitXPCOM2(nsIServiceManager * * aResult, nsIFile * aBinDirectory, nsIDirectoryServiceProvider * aAppFileLocationProvider) Line 776	C++
 	xul.dll!ScopedXPCOMStartup::Initialize() Line 1550	C++

Comment 9

[Wayne Mery (:wsmwk)]

tlhackque, does the issue happen with a current nightly build from https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/ ?
And if so please get a performance profile - start with https://developer.mozilla.org/en-US/docs/Tools/Remote_Debugging/Thunderbird and in Firefox click "performance", then "start recording performance", then "stop", then "safe"

Comment 10

[Wayne Mery (:wsmwk)]

As noted in 1249056, there is also Bug 1283908 - After updating from win7 to win10, Thunderbird is not responding for 1-2 minutes after sending mail when Windows service "Windows Search" is running (win10)

Comment 11

[Wayne Mery (:wsmwk)]

tlhackque,

bug 1262517 comment 21 states "I observed that freeze occurs when Thunderbird is creating %TEMP%\nsemail-*.eml file."

Is that also true in your case?

Comment 12

[Wayne Mery (:wsmwk)]

Reporter seems to be gone.
But occasional reports still come via support, listed at https://wiki.mozilla.org/Thunderbird:Testing:Memory_Usage_Problems

Comment 13

[Wayne Mery (:wsmwk)]

If you still see this when using version 102, please create a performance profile using the procedure at https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance