Did some further testing. Here are a few tips to reproduce:

Bug only happens, if you search in a big folder (for example your drive top directory) and when it is still searching when you click "Cancel" (and when there are no results yet).
Bug does not depend on the document, even happens in empty file.

Hello ich01,

Thank you for reporting the bug.
I can't reproduce it in

Versión: 5.3.0.3
Id. de compilación: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
Subpr. de CPU: 1; Versión de SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; 
Configuración regional: es-ES (es_ES); Calc: group

on Win 7 x86

Maybe it'll help if I add a step-by-step description of how to reproduce:

1. Open a new Document in LibreOffice Writer
2. Click "Insert" > "Image" (filepicker opens)
3. Go to the top directory of your hard drive (or a similar big folder that takes long enough to search)
4. Type some text in the search box in the top right corner (maybe something random, crash happens only when no items get displayed and it is still searching).
5. Click cancel while it is still looking for files and hasn't found something yet, otherwise crash won't happen.
(6.) (It looks like the cursor moves a bit to the right, like a TAB, but I'm not sure about that)

--> Crash

If you still can't reproduce, maybe your version/OS is not affected(?), I'm on Windows 10 using the version I selected above in the bug report.

Application and System Info:
Build:  0312e1a284a7d50ca85a365c316c7abbf20a4d22
CPU-Threads: 6; BS-Version: Windows 6.2; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group

Created attachment 131658 [details]
Backtrace of crash with 5.4

Version: 5.4.0.0.alpha0+
Build ID: a5c947579253a7f4e784004e18929af5ab22fa28
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-03-02_01:57:01
Locale: fi-FI (fi_FI); Calc: group

120efaec 65d32aa0 10599858 10599870 120efb18 explorerframe!CFirstPageResults::RunBackgroundEnumeration+0xf5
120efb28 75546bb8 0ff95b78 00000000 104cd4f0 explorerframe!CFirstPageTask::InternalResumeRT
120efb44 778be82c 7476ce4b 00000000 00000000 windows_storage!CShellTaskScheduler::_MT_QueueTaskInPriorityOrder+0x3b
120efb64 75547816 10599858 0a2b3680 104cd4f0 ntdll!NtQueryInformationThread+0xc
120efbb4 7765cff2 75546740 09f26510 120efbd8 windows_storage!CShellTask::TT_Run+0x49

Looks like internal / Microsoft Windows symbols; not code that we produce. Of course - possibly we corrupt memory so that this happens. Any chance of trying the same thing under 'DrMemory' ? so we can get a trace ? It looks like destroying the file dialog doesn't clean up its running background threads.

Can you reproduce this in some other application like notepad ?

Created attachment 131758 [details]
Drmemory trace

This is what I got..

(In reply to Michael Meeks from comment #5)
> Can you reproduce this in some other application like notepad ?

Tried with Notepad - Open dialog. No crash.

Thanks for the drmemory trace - but it looks very short =) It is necessary to rename 'soffice.bin' to 'soffice_real.exe' and run drmemory on that I suspect to get a good drmemory trace: did you do that ? =)

The trace looks like for the soffice.exe factory wrapper.

Thanks !

(In reply to Michael Meeks from comment #8)
> Thanks for the drmemory trace - but it looks very short =) It is necessary
> to rename 'soffice.bin' to 'soffice_real.exe' and run drmemory on that I
> suspect to get a good drmemory trace: did you do that ? =)
> 
> The trace looks like for the soffice.exe factory wrapper.

I did it according to the instructions, which no not mention the necessity: https://wiki.documentfoundation.org/Development/How_to_debug#Searching_for_a_memory_corruption_on_Windows_using_DrMemory

I will try again.

Created attachment 132103 [details]
Drmemory false positives

Now it said 0 errors, but lots of false positives, so I'm attaching a txt file with them.

Version: 5.4.0.0.alpha0+
Build ID: a5c947579253a7f4e784004e18929af5ab22fa28
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-03-02_01:57:01
Locale: fi-FI (fi_FI); Calc: group

On Win10 + master sources updated today, I don't reproduce this.

Any update with a recent LO version?

(In reply to Julien Nabet from comment #11)
> On Win10 + master sources updated today, I don't reproduce this.
> 
> Any update with a recent LO version?

Still repro with steps from comment 3. Build is from 25 April (for some reason the date is not shown in About anymore).

Version: 6.3.0.0.alpha0+
Build ID: 951282a27a9dd4c64fc206fcbdd805b4cb602816
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: fi-FI (fi_FI); UI-Language: en-US
Calc: threaded

Just for the record, I made another test with master sources updated today, I tried with openGL enabled then disabled, no repro in both cases.

Also, I use Win10, version 1709 (16299.1331), it's not my machine so can't update myself.

Still crashing with steps in comment 3

Version: 6.4.0.0.alpha0+ (x64)
Build ID: bda1d88f2bfa21202725ab9c567b3cccba3c1f0b
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-09-15_04:18:20
Locale: fi-FI (fi_FI); UI-Language: en-US
Calc: threaded

still reproducible with:

Version: 6.4.0.0.alpha1+ (x64)
Build ID: a79640b30ae08087224931bac832bb2d5c9c542a
CPU threads: 12; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded


Win10 x64 1903 Build 18362.449

even AOO 4.1.5 will crash, but no crash with other programs e.g. Firefox, Acrobat Reader etc.

will crash in ExplorerFrame.dll:

Version: 6.4.0.0.alpha1+ (x64)
Build ID: 5ae8f2f07815443716b3066706b4f193fe61f7c9
CPU threads: 12; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: CL

Name der fehlerhaften Anwendung: soffice.bin, Version: 6.4.0.0, Zeitstempel: 0x5dc5a036
Name des fehlerhaften Moduls: explorerframe.dll_unloaded, Version: 10.0.18362.418, Zeitstempel: 0x619c47cc
Ausnahmecode: 0xc0000005
Fehleroffset: 0x000000000014e107
ID des fehlerhaften Prozesses: 0x3d9c
Startzeit der fehlerhaften Anwendung: 0x01d597c71216de9b
Pfad der fehlerhaften Anwendung: D:\sources\libo-core\instdir\program\soffice.bin
Pfad des fehlerhaften Moduls: explorerframe.dll
Berichtskennung: 0958566f-f282-4d4f-ae54-bb94c79885b1
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist: 

crash happens after returning from:

filedlghelper.cxx:

ErrCode FileOpenDialog_Impl( weld::Window* pParent,
                             sal_Int16 nDialogType,
                             FileDialogFlags nFlags,
                             std::vector<OUString>& rpURLList,
                             OUString& rFilter,
                             std::unique_ptr<SfxItemSet>& rpSet,
                             const OUString* pPath,
                             sal_Int16 nDialog,
                             const OUString& rStandardDir,
                             const css::uno::Sequence< OUString >& rBlackList )
{
    [...]

    nRet = pDialog->Execute(rpURLList, rpSet, rFilter, aPath);
    DBG_ASSERT( rFilter.indexOf(": ") == -1, "Old filter name used!");

    if (rpSet && nFlags & FileDialogFlags::SignPDF)
        rpSet->Put(SfxBoolItem(SID_DOC_READONLY, true));
 *** CRASH ***
    return nRet;
}

The problem seems to be unloading of ExplorerFrame.dll in CoUninitialize() in the AsyncRequests thread, while still running the code from it (executing CFirstPageResults::RunBackgroundEnumeration - see comment 5).

However, simply removing CoUninitialize() from VistaFilePickerImpl::after() doesn't help, possibly because it still gets called automatically when the thread terminates (?).

Hope this would help.

(In reply to Mike Kaganski from comment #17)
> The problem seems to be unloading of ExplorerFrame.dll in CoUninitialize()
> in the AsyncRequests thread, while still running the code from it (executing
> CFirstPageResults::RunBackgroundEnumeration - see comment 5).
> 
> However, simply removing CoUninitialize() from VistaFilePickerImpl::after()
> doesn't help, possibly because it still gets called automatically when the
> thread terminates (?).
>...

It makes me think about this log I got when just launching an LO module (Writer/Calc/Impress/...) (Win10 with master sources updated today):
warn:extensions.olebridge:17940:13228:extensions/source/ole/olethread.cxx:41: CoInitializeEx failed (expectedly): Impossible de modifier le mode thread une fois qu’il a été fixé. (= Impossible to change thread mode once it has been defined)
warn:extensions.olebridge:17940:13228:extensions/source/ole/olethread.cxx:61:   Thread is in a main single-threaded apartment.

Searching "CoInitializeEx" gives:
https://opengrok.libreoffice.org/search?project=core&full=CoInitializeEx&defs=&refs=&path=&hist=&type=&si=full
some code use: "COINIT_MULTITHREADED"
other parts use: "COINIT_APARTMENTTHREADED"

(In reply to Julien Nabet from comment #18)
> It makes me think about this log I got when just launching an LO module
> (Writer/Calc/Impress/...) (Win10 with master sources updated today):
> warn:extensions.olebridge:17940:13228:extensions/source/ole/olethread.cxx:41:
> CoInitializeEx failed (expectedly): Impossible de modifier le mode thread
> une fois qu’il a été fixé. (= Impossible to change thread mode once it has
> been defined)
> warn:extensions.olebridge:17940:13228:extensions/source/ole/olethread.cxx:61:
> Thread is in a main single-threaded apartment.
> 
> Searching "CoInitializeEx" gives:
> https://opengrok.libreoffice.org/
> search?project=core&full=CoInitializeEx&defs=&refs=&path=&hist=&type=&si=full
> some code use: "COINIT_MULTITHREADED"
> other parts use: "COINIT_APARTMENTTHREADED"

The warning is likely innocent; and the two modes are expected. Mostly we need COINIT_MULTITHREADED; but in case of AsyncRequests thread, we need COINIT_APARTMENTTHREADED (because it's UI thread). That is set in VistaFilePickerImpl::before - see comments there. So that thread has an specific mode; possibly that's why DLLs loaded from it are released when it's uninitialized ... the question is how to terminate the dialog properly = terminate secondary (tertiary) thread with the windows.storage.dll processing.

https://crashreport.libreoffice.org/stats/crash_details/05123435-cb9f-43e5-99ac-454232eefee4
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: c5b911b23f45ba86100c2eadc747b27c8744a96d
CPU threads: 4; OS: Windows 10.0 Build 21296; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: CL

Triyng to open a file, with one already open

Matt K committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1c1226709c6be39c5462f5e6e1262ca630b30b34

tdf#106282 Change Windows File Dialog to run on the main thread

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.