MSVCRT.dll faults during file searches

File Explorer has been crashing while doing "content:" searches on my [local solid-state] disk.  I navigate to the folder of interest in file explorer and then type the likes of "content:typedef" in file explorer's search box.  Searches progress for a while, possibly display some filename results, and then the window vanishes.  Crashes seem independent of the text being sought or the search expression as a whole.

It does seem to be related to the folder being searched, however.  Using the above content search expression on "C:\Program Files (x86)" eventually displays results and does not crash.  Searches of "C:\Program Files", "C:\Windows", and the one I was trying to search: "C:\Users\xxxx\AppData\Local" all "poof" the Explorer window after a few minutes.

A "dir /S" command reveals my AppData\Local has 19674 File(s) of a total 2,137,937,256 bytes.  The largest single file is a 130 MB zip file.  I have been trying to identify something unique to the folder trees that fail versus those that succeed, and so far the only thing I can see is that the trees that fail all have at least one file with the "I" (capital letter between 'H' and 'J') attribute, i.e. 'dir /S /A:I' does not find any such files in C:\Program Files (x86), but finds some in all the other folders identified above.  Could be coincidence.

Potentially relevant, yesterday I told Windows I wanted the entire disk indexed for future content searches, settings I had not previously used.  [I realize what this does and does not do, but it is a recent configuration change.]   However, having said that, nothing an end-user does should cause an access violation fault in something as fundamental as this runtime library when called by something as fundamental as the Windows file explorer.

Additionally relevant, I have Cortana as "squelched" or "quiesced" as permitted by the licensing.  I'm told there is some integration between her and searching that may aggravate the situation, but again, this supported end-user customization should not be able to crash fundamental parts of the system.

I searched the entire disk for instances of MSVCRT.dll, and all are identical version and size as the one cited in the Event log shown below.

Sample Event Viewer display:

Faulting application name: explorer.exe, version: 10.0.17134.165, time stamp: 0x4031a9f8

Faulting module name: msvcrt.dll, version: 7.0.17134.1, time stamp: 0x5cbba6fd

Exception code: 0xc0000005

Fault offset: 0x000000000007440f

Faulting process id: 0x2adc

Faulting application start time: 0x01d497a6b5ccda55

Faulting application path: C:\WINDOWS\explorer.exe

Faulting module path: C:\WINDOWS\System32\msvcrt.dll

Report Id: d816e634-4457-44b1-951b-22c6155f4a50

Faulting package full name:

Faulting package-relative application ID:

The fault offsets for additional failure occurrences are not the same, but are fairly close together:

0x0000000000074360, and 0x0000000000074500

Yesterday, a restart incorporated Windows Defender definition update 1.283.910.0.   I don't think this is in any way related to the search problem, but it is in fact something recently updated in the configuration.

December 12 was the next most recent software installation or update. I installed the cumulative Windows 10 update KB4471324. For sure, I recall no file content searches that crashed in the intervening days, but its also true that I don't recall searching my AppData\Local (or any of the other folders cited above) during that period either..

HP Laptop running Intel(R) Core(TM) I5-82500U CPU @1.8GHz  with 12.0 GB RAM.