Download it now!
Bug 52276 - .odt or .fodt file causes Windows Explorer (Windows 7) to crash and restart
Summary: .odt or .fodt file causes Windows Explorer (Windows 7) to crash and restart
Status: RESOLVED DUPLICATE of bug 52078
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.6.0.1 rc
Hardware: Other Windows (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-19 17:51 UTC by Roman Eisele
Modified: 2012-07-20 06:57 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Eisele 2012-07-19 17:51:31 UTC
It is very likely that the following is either not reproducible or NOTOURBUG. Nevertheless I have to report it, because there is at least a minimal chance that this is a bug in LibreOffice; and if it is our bug, it is an important one. So I report it, and ask our Windows expert (I'm no one) to investigate if this is really a LibreOffice issue or not reproducible or just NOTOURBUG. Thank you!

I just installed LibreOffice 3.6.0.1 (= RC 1) on a laptop with Windows 7 Professional which I borrowed from a friend. There was no LibreOffice (or OOo or AOO) installed on this machine before, but MS Office Professional 2010. Installation of LibO and of the German helppack worked fine. Then I started LibreOffice, changed only the most important application settings (options), and created a new Writer file with a single line of text in the default style. I saved this file first in .odt format and then in .fodt format, both on the desktop, named "Test.odt" and "Test.fodt".

After quitting LibreOffice (which made Windows Explorer come to the front) the horror started: Windows Explorer was quit and restarted again and again, every time showing only the same generic alert ("Windows Explorer has encountered an error and must restart" or so). Even restarting the complete machine did not have any effect: as soon as the desktop became visible, the Explorer restart loop began again.

When I logged in as admin, the Explorer worked again (because the files where not visible on the admin desktop); but as soon as I navigated with Explorer to the main user's "Desktop" folder, opened it and clicked once (!) on one of the files (I forgot on which one first, sorry!) to select it, Windows Explorer crashed again with the same message.

This indicates that the problem must have involved one (or both?) of my "Test.odt" and "Test.fodt" files. This is affirmed by the following: after deleting both files from the desktop via a complicated "telepathic" action, the problem went away for good. Which one of the two files was the reason I can not tell. I can just say that for the .odt file the Win Explorer showed the correct (LibreOffice .odt) icon, and for the .fodt the Explorer showed a preview, which was correct, too (a blank page with a single line of text).

Now I know that this looks like NOTOURBUG -- I would think that one or both of the files exhibited a bug somewhere deep in Windows Explorer. But I don't know enough about Windows to judge this issue. Are there any file viewer extensions or so which LibreOffice installs on Windows? Then the bug could be somewhere in that extensions. Or is it possible that this is a conflict about registered file types (as said above, MS Office Professional 2010 is installed on the machine)?

I'm sorry that I can't do any additional testing, because this was not *my* machine and I can't do critical things on it :-( So I ask our Windows experts to investigate this. However, do NOT save any test files on the desktop, because this will (if you can reproduce the issue) cause the same horrific and endless Explorer restart loop; save the files into a folder/directory somewhere, and delete them (if necessary) by terminal commands ("cd ..." to the directory in question, then "dir", then "del ...").
Comment 1 David Tardon 2012-07-20 06:57:53 UTC

*** This bug has been marked as a duplicate of bug 52078 ***