<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Crash in: mergedlo.dll / on close" href="https://bugs.documentfoundation.org/show_bug.cgi?id=142022#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Crash in: mergedlo.dll / on close" href="https://bugs.documentfoundation.org/show_bug.cgi?id=142022">bug 142022</a> from <a class="email" href="mailto:vstuart.foote@utsa.edu" title="V Stuart Foote <vstuart.foote@utsa.edu>"> V Stuart Foote</a> <pre>(In reply to Nico from <a href="show_bug.cgi?id=142022#c11">comment #11</a>) > Not checked by default... > Checked, and same crash. > > Gave a try, after deleting my LO profile, I checked it (along with Skia > which came back)... and also failing :/ OK those were all the simple steps, next would be to obtain a back trace. It will work better against the 7.1 builds compared to against master/7.2 because the symbols are fully published for the release builds, but it is involved to get set up. Steps are here: <a href="https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg">https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg</a> It is a hassle but it would really help to isolate the component causing the crashes on your system. Unfortunately the generic !analyze -v (or !analyze -f) command will often not resolve, and you have to use a "~* kp" to list the stack with symbols for all the threads to tease out the call(s) causing the crash. A local WinDbg run can do a more complete stack trace than what is submitted by the automated mini-dump based crash reporting mechanism, which you have already reported against the generic mergedlo.dll. The whole WinDbg tool can be a challenge.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>