ExperimentEcs Registry Key Causing All O365 Apps to Crash on Open after First Use

This one had me really stumped. One morning after Office updated, I found that all of my apps were crashing immediately on start. (I'm running Version 1803, Build 9120.2015 Click-to-Run on Windows 7 Enterprise 64-bit.) So I followed all the usual steps:

1. Restart the computer.
2. Restart the computer with all startup programs and all non-Microsoft services disabled.
3. Perform a Quick Repair.
4. Perform a Full Online Repair.
5. Uninstall and Reinstall Office.
6. Use the Office Removal Tool to completely get rid of all Office files and settings, then reinstall.

That last step finally did the trick, and my apps would start again. But each one would start only once. I could run Word once, Excel once, Access once, etc., and they would continue working properly as long as I had the program open. But closing and reopening the program, or starting a second instance of the executable, would cause the crash again and each time thereafter. Once again, the only way to solve the problem was the Office Removal Tool and a full reinstall. I even tried going back and forth between 32-bit and 64-bit versions.

Since the error message on screen doesn't say much of any use, I went into Event Viewer to get the details.

Faulting application name: OUTLOOK.EXE, version: 16.0.9120.2015, time stamp: 0x5a90cb36

Faulting module name: KERNELBASE.dll, version: 6.1.7601.24000, time stamp: 0x5a4996d4

Exception code: 0xc0000005

Fault offset: 0x0000deb5

Faulting process id: 0x5958

Faulting application start time: 0x01d3b24df77bd676

Faulting application path: C:\Program Files (x86)\Microsoft Office\root\Office16\OUTLOOK.EXE

Faulting module path: C:\WINDOWS\syswow64\KERNELBASE.dll

Report Id: 35e7f55d-1e41-11e8-a14b-4ceb42e7f0b7

The faulting application would vary according to what I just tried to start, but it was always in the KERNELBASE.dll module (either system32 or syswow64 depending on which version of Office I installed), and always exception code 0xc0000005 (Access violation). Apparently it was trying to hit an invalid memory address.

So I kind of hit a wall there and was getting ready to reimage my hard drive, but it occurred to me that something must be happening during the first run of each application that was triggering the problem, because each app would open successfully once. The issue must either be a change to a file or a change to the registry. So I used RegShot to take a snapshot of my registry immediately before and immediately after launching an app for the first time, then ran a comparison to spot the differences.

Most of the activity appeared to be in these keys:

HKEY_USERS(my SID)\Software\Microsoft\Office\16.0\Common\ExperimentEcs(app name)\Flights

There were 415 distinct values in those "Flights" keys, which would take me all day using trial-and-error, so I exported each of them and used Excel to analyze which values were present in all of the core apps but not Lync/Skype (which was unaffected). That narrowed it down to 18. So I started deleting them one at a time and trying to start the associated app after each. The very last one did the trick:

HKEY_USERS(my SID)\Software\Microsoft\Office\16.0\Common\ExperimentEcs(app name)\Flights\ofw3mzikwqfso51

After a little more repetition to confirm, I verified that deleting this value or setting its data to "false" (instead of the previous value of "true") would resolve the issue.

The challenge is that Office keeps changing it back to "true" on an intermittent basis, which breaks my programs again, but at least I know how to work around it now without removing/reinstalling.

I have looked all over the Internet and can't find anything like this or even a description of what these keys are for. So my questions are:

1. What does the ExperimentEcs section of the Office registry (and more specifically this ofw3mzikwqfso51 value) do?
2. Is this related to Office Insider's not-ready-for-primetime features or something else?
3. Why are these values so cryptically named?
4. Is there something I can do to make the "true" value data not cause access violations when apps are launched?
5. Failing that, is there any way to make Office stop changing this registry value? (Preferably more elegant than writing a .reg script and putting a scheduled task on it.)

Thanks!

Mark