Steps: 1) Install Windows x64 build 2) Clear the user profile if one already exists 3) Open LibreOffice 4) Crash The crash doesnt happen a second time around. Version: 5.1.1.1 (x64) Build ID: c43cb650e9c145b181321ea547d38296db70f36e CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; Locale: en-US (en_US) I tried to capture the backtrace, but this is all i got. CommandLine: E:\LibreOffice\5.1x64\program\soffice.exe Symbol search path is: CACHE*C:\symbols;SRV*http://dev-builds.libreoffice.org/daily/master/Win-x86@39/symbols;SRV*http://dev-downloads.libreoffice.org/symstore/symbols;SRV*http://msdl.microsoft.com/download/symbols Executable search path is: ModLoad: 00000001`3fa90000 00000001`3faa2000 soffice.exe ModLoad: 00000000`77b90000 00000000`77d39000 ntdll.dll ModLoad: 00000000`77970000 00000000`77a8f000 C:\Windows\system32\kernel32.dll ModLoad: 000007fe`fdb70000 000007fe`fdbdc000 C:\Windows\system32\KERNELBASE.dll ModLoad: 000007fe`ff620000 000007fe`ff6fb000 C:\Windows\system32\ADVAPI32.dll ModLoad: 000007fe`fded0000 000007fe`fdf6f000 C:\Windows\system32\msvcrt.dll ModLoad: 000007fe`ff080000 000007fe`ff09f000 C:\Windows\SYSTEM32\sechost.dll ModLoad: 000007fe`ff280000 000007fe`ff3ad000 C:\Windows\system32\RPCRT4.dll ModLoad: 000007fe`fe040000 000007fe`fedc8000 C:\Windows\system32\SHELL32.dll ModLoad: 000007fe`fee00000 000007fe`fee71000 C:\Windows\system32\SHLWAPI.dll ModLoad: 000007fe`ff5b0000 000007fe`ff617000 C:\Windows\system32\GDI32.dll ModLoad: 00000000`77a90000 00000000`77b8a000 C:\Windows\system32\USER32.dll ModLoad: 000007fe`fde60000 000007fe`fde6e000 C:\Windows\system32\LPK.dll ModLoad: 000007fe`fdf70000 000007fe`fe039000 C:\Windows\system32\USP10.dll ModLoad: 000007fe`fa890000 000007fe`fa97f000 C:\Windows\system32\MSVCR120.dll (ed0.ee0): Break instruction exception - code 80000003 (first chance) ntdll!LdrpDoDebuggerBreak+0x30: 00000000`77c3cb70 cc int 3 0:000> g ModLoad: 000007fe`fedd0000 000007fe`fedfe000 C:\Windows\system32\IMM32.DLL ModLoad: 000007fe`ff400000 000007fe`ff509000 C:\Windows\system32\MSCTF.dll ModLoad: 000007fe`fd800000 000007fe`fd857000 C:\Windows\system32\apphelp.dll ntdll!ZwTerminateProcess+0xa: 00000000`77be157a c3 ret 0:000> !analyze -v Last event: ed0.ee0: Exit process 0:ed0, code 0 debugger time: Thu Mar 3 02:05:47.364 2016 (UTC + 4:00)
What happens if you force OpenGL and restart? Does it crash then too? If yes - it's the well known first-time OpenGL crash. (If the system doesn't have proper GL support and it crashes, then OpenGL is disabled for the next time.)
(In reply to Maxim Monastirsky from comment #1) > What happens if you force OpenGL and restart? Does it crash then too? If yes > - it's the well known first-time OpenGL crash. (If the system doesn't have > proper GL support and it crashes, then OpenGL is disabled for the next time.) Yes it does crash. But why does this crash only happen on x64 build, as it doesnt happen when i use a x86 build with no profile.
Can you give C:\Users\User\AppData\Roaming\LibreOffice dev\4\cache\opengl_device.log
(In reply to Maxim Monastirsky from comment #1) > If yes - it's the well known first-time OpenGL crash. Is there a bug report for this issue?
Created attachment 123764 [details] opengl_device.log (In reply to Buovjaga from comment #3) > Can you give C:\Users\User\AppData\Roaming\LibreOffice > dev\4\cache\opengl_device.log Here you go. My graphics card only supports OpenGL 1.4, which is to low to render the UI.
(In reply to Yousuf (Jay) Philips from comment #0) > I tried to capture the backtrace, but this is all i got. > > CommandLine: E:\LibreOffice\5.1x64\program\soffice.exe ... > ntdll!ZwTerminateProcess+0xa: > 00000000`77be157a c3 ret > 0:000> !analyze -v > Last event: ed0.ee0: Exit process 0:ed0, code 0 > debugger time: Thu Mar 3 02:05:47.364 2016 (UTC + 4:00) It looks like you attached to soffice.exe, but you should actually attach to soffice.bin. Could you try this? (In reply to Yousuf (Jay) Philips from comment #4) > Is there a bug report for this issue? Can't find it right now, but I remember I saw it mentioned somewhere.
Created attachment 123780 [details] windbg (In reply to Maxim Monastirsky from comment #6) > It looks like you attached to soffice.exe, but you should actually attach to > soffice.bin. Could you try this? Here's another try.
Created attachment 123781 [details] windbg2 i assume this backtrace is better.
I'm getting this in 5.1.3.2. Not sure if it's the same crash, but it occurs under the exact same circumstances as reported here: in x64 build with deleted profile. Even then it doesn't occur every time, but it's been happening regularly.
@Meeks: Can you check my backtrace for this first startup crash for windows x64?
Hi Jay - so - you sure this is a crash ? ultimately your GL device looks like it should be black-listed so there should be no GL in-use. When we do the first-ever start; on some platforms it is expected that the first run installs and initializes extensions and then the main binary exits with a given return code and should be re-started by the wrapper =) [ at least this used to be the case left & right ]. Whether that happens via ZwTerminateProcess I forget =) perhaps not - but ... then again - this trace: https://bug-attachments.documentfoundation.org/attachment.cgi?id=123781 does indeed show some GL crash / badness. Can you confirm you generated that trace with this device: https://bug-attachments.documentfoundation.org/attachment.cgi?id=123764 because at least my master blacklist has: <blacklist> <entry os="all" vendor="intel" compare="less" version="10.18.14.4264"> <device id="all"/> </entry> Which should knock out your intel 8.15.10.1930 driver ... very strange. Thanks !
(In reply to Michael Meeks from comment #11) > Hi Jay - so - you sure this is a crash ? ultimately your GL device looks > like it should be black-listed so there should be no GL in-use. Hi Michael, yes sure. > When we do the first-ever start; on some platforms it is expected that the > first run installs and initializes extensions and then the main binary exits > with a given return code and should be re-started by the wrapper =) [ at > least this used to be the case left & right ]. > > Whether that happens via ZwTerminateProcess I forget =) perhaps not - but > ... then again - this trace: > > https://bug-attachments.documentfoundation.org/attachment.cgi?id=123781 > > does indeed show some GL crash / badness. Can you confirm you generated that > trace with this device: > > https://bug-attachments.documentfoundation.org/attachment.cgi?id=123764 Yes i only run windows 7 on my laptop, which is where this crash report came from. > because at least my master blacklist has: > > <blacklist> > <entry os="all" vendor="intel" compare="less" > version="10.18.14.4264"> > <device id="all"/> > </entry> > > Which should knock out your intel 8.15.10.1930 driver ... very strange. Yes this is quite strange to me as this same thing doesnt happen on the x86 build.
I might be encountering a slightly different version of this issue in master, but can't say for sure. Nevertheless, I opened bug 100487 on that, any hints are welcome.
Is it better thanks to this? https://cgit.freedesktop.org/libreoffice/core/commit/?id=c9b2af045acc92c8665a8523407f530cc691d5bf + <entry os="7" vendor="intel"> + <device id="all"/> + </entry> See tdf#101138
Intel/GL - their windows / GL driver quality is something awful before that date I suspect. It is also quite possible/probable that the 64bit drivers are worse than the 32bit ones ;-) Having said that - as Julien says - if you're running Windows 7 + Intel - the driver should be black-listed by - commit 97fb2a8a43f11dba7c3e82380589b2334d09865a Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> Date: Tue Jul 26 16:21:13 2016 +0900 tdf#101138 opengl: blacklist intel drivers for Win 7 So is this still an issue in a recent 5.1.x ? I'd hope not -> marking fixed. Please re-open if you can reproduce with a recent 5.1.x Thanks !