Created attachment 160334 [details]
bt Windows (windbg)

Just for information, I use:
soffice.bin

After having renamed LO profile:
- First time crash (see bt)
- Second time no crash but it doesn't start and no log
- Third time: error : Unknown IO error
- Fourth time: ok

Have noticed it too

I cannot reproduce this. The backtrace suggests that your Vulkan driver locks up and the first crash is the watchdog detecting it and aborting, but even after faking this I still cannot reproduce any follow-up crash.

You can try:
- check your instdir/cache/skia.log .
- run with SAL_LOG=+INFO.vcl.skia to see if something shows up
- check values of Skia-related entries in instdir/user/registrymodifications.xcu after the first crash

Created attachment 160434 [details]
instdir\cache\skia.log

Created attachment 160435 [details]
console logs with SAL_LOG=+INFO.vcl.skia

registrymodifications.xcu contains only:
<?xml version="1.0" encoding="UTF-8"?>
<oor:items xmlns:oor="http://openoffice.org/2001/registry" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<item oor:path="/org.openoffice.Office.Common/VCL"><prop oor:name="ForceSkiaRaster" oor:op="fuse"><value>true</value></prop></item>
<item oor:path="/org.openoffice.Office.Linguistic/General"><prop oor:name="UILocale" oor:op="fuse"><value></value></prop></item>
<item oor:path="/org.openoffice.Office.Logging/Settings"><node oor:name="unopkg" oor:op="replace"><prop oor:name="LogLevel" oor:op="fuse"><value>2147483647</value></prop><prop oor:name="DefaultHandler" oor:op="fuse"><value>com.sun.star.logging.FileHandler</value></prop><node oor:name="HandlerSettings"><prop oor:name="FileURL" oor:op="fuse"><value>$(userurl)/$(loggername).log</value></prop></node><prop oor:name="DefaultFormatter" oor:op="fuse"><value>com.sun.star.logging.PlainTextFormatter</value></prop><node oor:name="FormatterSettings"></node></node></item>
<item oor:path="/org.openoffice.Setup/L10N"><prop oor:name="ooLocale" oor:op="fuse"><value>fr</value></prop></item>
<item oor:path="/org.openoffice.Setup/Office"><prop oor:name="ooSetupInstCompleted" oor:op="fuse"><value>true</value></prop></item>
</oor:items>

So ForceSkiaRaster = true (whereas I forced nothing), it's just after a reset of LO profile.

Luboš: any information I could retrieve or test I could do to help investigation?

I'm seeing the same thing. However only when resetting the user profile in safe mode to factory settings (with both checkboxes checked). 
No issue when launching after deleting the profile.. Didn't try renaming

Version: 7.0.0.0.alpha1 (x64)
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU-threads: 4; Besturingssysteem: Windows 6.3 Build 9600; UI-render: Skia/Vulkaan; VCL: win; 
Locale: nl-NL (nl_NL); UI: nl-NL
Calc: threaded

(In reply to Julien Nabet from comment #2)
> After having renamed LO profile:
> - First time crash (see bt)

 I think this is most likely a driver problem and there's not much to do about it, the watchdog already handles fine that it locks up (minus the restart done once, which could be improved by blacklisting the card/driver).

> - Second time no crash but it doesn't start and no log
> - Third time: error : Unknown IO error

 So I consider these two to be possible problems. Can you provide more information about these (backtraces, logs)?

@Stuart V
How often do you need to launch LibreOffice after factory reset (in safe mode). 
- First time -> Quits.. no crash
- Second time no crash but it doesn't start
- Third time still nothing
- Fourth time: ok

Created attachment 161004 [details]
bt on second step

I runned "make clean" then updated and built from scratch.
Now LO opens after the third launch (instead of fourth one).

1 : crash
2: nothing (I attached a bt)
3: ok

Remark: to launch LO, I use soffice.bin
To obtain this bt, I launched Windbg and used "Open executable" and chose soffice.bin.

(In reply to Telesto from comment #11)

Not having an issue. But I am noticing recently the Splash screen syncing/enabling modules & extensions cycles 4 times before fully opening to Start Center. That seems new--related?

On Windows 10 Home 64-bit en-US (1909) with Intel HD Graphics 620 with Intel ICH pgk Driver Version 27.20.100.8187

Using the 'Reset to Factory Settings' [chk Entire User Profile] and 'Apply Changes and Restart'

Results in this Skia.log:

RenderMethod: vulkan
Vendor: 0x8086
Device: 0x5916
API: 1.2.135
Driver: 0.401.4091
DeviceType: integrated
DeviceName: Intel(R) HD Graphics 620
Blacklisted: no

I'll check on a couple of older "non-Vulkan" graphics capable systems.

If, after having remove LO profile, instead of "soffice.bin", I used "swriter.exe", it aborts at first time, it opens at the second time.

Created attachment 161019 [details]
GPU details, old AMD HD 6450 no-Vulkan support nVIDIA GT 710 supported

(In reply to V Stuart Foote from comment #13)

> I'll check on a couple of older "non-Vulkan" graphics capable systems.

So with today's TB77 build of master

Version: 7.0.0.0.alpha1+ (x64)
Build ID: 4804d969bacd25ad586b3bf70d3dc8c27adb48ef
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win; 
Locale: en-US (en_US); UI: en-US
Calc: CL

No crashes Skia Vulkan or Raster.

And as earlier today, for GPUs with and without support for Skia Vulkan rendering, a Safe mode reset cycles through the splash screen sequence to Synchronize bundled extensions, and then Enable bundled extensions -4- times.

Not clear that is a Skia issue, probably not, but it is new.

Except if I missed something, information have been provided.

I'm 'pulling out'.. no issues here.
Version: 7.0.0.0.alpha1+ (x64)
Build ID: 9a7c5d38a7a43c75c0f3d2f0c725196e916d0260
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

(In reply to Julien Nabet from comment #14)
> If, after having remove LO profile, instead of "soffice.bin", I used
> "swriter.exe", it aborts at first time, it opens at the second time.

You're not supposed to call soffice.bin directly, that's an internal executable invoked by soffice.exe, swriter.exe or others. It's normal that soffice.bin sometimes exits, soffice.exe will restart it as necessary. Does the problem exist if you use soffice.exe?

(In reply to Luboš Luňák from comment #18)
> (In reply to Julien Nabet from comment #14)
> ...
> You're not supposed to call soffice.bin directly, that's an internal
> executable invoked by soffice.exe, swriter.exe or others. It's normal that
> soffice.bin sometimes exits, soffice.exe will restart it as necessary. Does
> the problem exist if you use soffice.exe?

I updated my local repo and removed LO profile, I confirm I've got same pb with soffice.exe:
- first time: error message ("abort has been called...")
- second time: ok

(In reply to Julien Nabet from comment #19)
> (In reply to Luboš Luňák from comment #18)
> > (In reply to Julien Nabet from comment #14)
> > ...
> > You're not supposed to call soffice.bin directly, that's an internal
> > executable invoked by soffice.exe, swriter.exe or others. It's normal that
> > soffice.bin sometimes exits, soffice.exe will restart it as necessary. Does
> > the problem exist if you use soffice.exe?
> 
> I updated my local repo and removed LO profile, I confirm I've got same pb
> with soffice.exe:
> - first time: error message ("abort has been called...")
> - second time: ok

That works as intended. The first time is the watchdog detecting a problem with the driver and aborting, the second time is fine with LO switched to raster. So the only thing remaining should be blacklisting the driver, which I'll do now.

Your driver appears to be very old. I suggest you update it if possible (perhaps even by using a driver directly from Intel instead of a PC-vendor-provided driver).

Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/eaacb2eca2ffcf46306f1db83e4c5da4a102e4a9

blacklist old intel driver 0.16.2 for Vulkan (tdf#132681)

It will be available in 7.1.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.

@Julien, could you please verify the issue is fixed for you in a recent build ?

On Win10 with master sources updated today, I confirm I got no error and could launch LO after having removed LO profile, with 1 try.

Thank you Luboš!

Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/db8e2fb82d875ccfb022a0fe24958bf3c4ac7d83

blacklist old intel driver 0.16.2 for Vulkan (tdf#132681)

It will be available in 7.0.0.1.

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.