Expected behaviour: detect and silently correct for an upgrade from Java 6.x to Java 7.x
Actual Behaviour: fail to detect the change; crash without warning or explanation on all subsequent startups.



A couple of days ago LO started crashing hard every time it was opened, in any module: the Windows event log showed

Faulting application name: soffice.bin, version: 3.5.4.2, time stamp: 0x4fbc7fd1
Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace5b9
Exception code: 0xc0000417
Fault offset: 0x0002e9f4
Faulting process id: 0x1754
Faulting application start time: 0x01cd5a1a811603aa
Faulting application path: C:\Program Files\LibreOffice 3.5\program\soffice.bin
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll
Report Id: 656fdd56-c671-11e1-b9ee-001fd09f75e0

This happened every single time I tried to open it, wuth any file or in any module, running 32 bit Windows 7, home edition, completely patched. 

Poking around on Google revealed the cause. If Oracle Java on Windows has been updated to version 7 (as happens automatically), Libre Office 'loses' the installation. The file 
C:\Users\{username}\AppData\Roaming\LibreOffice\3\user\config\javasettings_Windows_x86.xml

is not updated with the result that the program crashes hard and without explanation every single time you try to open it. 

The workaround is to rename the user directory, and start LO up again. At this point it reconstructs the user directory with a correct link to the new Java installation in javasettings...xml. That can then be copied over to the old user directory and then the whole lot recopied back, preserving the original settings. But it is grotesque to expect normal users to do this.