Problem description: shlxthdl_x64.dll causes explorer.exe to crash, if any *.fodt document in view. Steps to reproduce: 1. Save a foobar.fodt file (OpenDocument Text /Flat XML) 2. View foobar.fodt containing folder in Explorer 3. Right click on fodt-file -> crash Current behavior: Explorer-Crash Expected behavior: Normal File Preview/Info Workaround: REGSVR32 /u shlxthdl_x64.dll (32-bit ShellExt is OK) Platform (if different from the browser): Win 7 Pro x64
Did it work with 3.5? If yes, it is probably collateral damage caused by gbuild migration (even if I cannot imagine why it would only affect the x64 variant).
(In reply to comment #1) > Did it work with 3.5? If yes, it is probably collateral damage caused by gbuild > migration (even if I cannot imagine why it would only affect the x64 variant). Yes, it worked with 3.5 (just verified, same machine & conditions). But you were right about the x64, actually the problem's the "shlxthdl.dll" (my wife's got a W7 x86-system) - it crashes the same way with 3.6. My guess: shlxthdl_x64.dll is just a wrapper, correct? I could fix it the same way: REGSVR32 /u shlxthdl.dll I hope this will help - I love LO! Thanks for your great work.
*** Bug 52276 has been marked as a duplicate of this bug. ***
NEW because of duplicate (and because the question from comment #1 was answered in comment #2, so NEEDINFO is obsolete).
(Expanded the Summary to make it easier to find this report -- I could not find it yesterday, so thanks to David Tardon for marking my report as a duplicate of this one!)
Keyword 'regression' added because of comment #2.
Is anyone able to get a stack trace of the crash? Or at least check shlxthdl.dll and ooofilt.dll by depends.exe (http://www.dependencywalker.com/) to ascertain there are no missing dependencies?
(In reply to comment #7) > Is anyone able to get a stack trace of the crash? Or at least check > shlxthdl.dll and ooofilt.dll by depends.exe (http://www.dependencywalker.com/) > to ascertain there are no missing dependencies? For me this is difficult (or impossible), because (as said in bug 52276) I don’t own the computer on which I have experienced the problem. And in addition, I have little knowledge about Windows stuff (long-time Mac user). @ Thomas Bigler : Could you help? From your posts I infer that you have much more Windows experience ... Thank you very much!
Created attachment 64674 [details] ZIP file, containing depends dump for shlxthdl_x64.dll (In reply to comment #7) > Is anyone able to get a stack trace of the crash? Or at least check > shlxthdl.dll and ooofilt.dll by depends.exe (http://www.dependencywalker.com/) > to ascertain there are no missing dependencies? Thomas Bigler was so nice to create a "depends dump" for shlxthdl_x64.dll which I attach to this bug report (thank you very much, Thomas!). If we understand the dump correctly, the bad boys are MSVCR90.DLL IESHIMS.DLL -- but please analyse the dump yourself. Hope it helps!
(In reply to comment #9) > Created attachment 64674 [details] > ZIP file, containing depends dump for shlxthdl_x64.dll > > (In reply to comment #7) > > Is anyone able to get a stack trace of the crash? Or at least check > > shlxthdl.dll and ooofilt.dll by depends.exe (http://www.dependencywalker.com/) > > to ascertain there are no missing dependencies? > > Thomas Bigler was so nice to create a "depends dump" for shlxthdl_x64.dll which > I attach to this bug report (thank you very much, Thomas!). If we understand > the dump correctly, the bad boys are > MSVCR90.DLL > IESHIMS.DLL > -- but please analyse the dump yourself. Hope it helps! Just tested the new Version 3.6.0.2+ (Build ID: 01576a7). Still crashes Explorer with FODT :( but no more crashes with ODT :)
(In reply to comment #10) > (In reply to comment #9) > > Created attachment 64674 [details] > > ZIP file, containing depends dump for shlxthdl_x64.dll > > > > (In reply to comment #7) > > > Is anyone able to get a stack trace of the crash? Or at least check > > > shlxthdl.dll and ooofilt.dll by depends.exe (http://www.dependencywalker.com/) > > > to ascertain there are no missing dependencies? > > > > Thomas Bigler was so nice to create a "depends dump" for shlxthdl_x64.dll which > > I attach to this bug report (thank you very much, Thomas!). If we understand > > the dump correctly, the bad boys are > > MSVCR90.DLL > > IESHIMS.DLL > > -- but please analyse the dump yourself. Hope it helps! > > > Just tested the new Version 3.6.0.2+ (Build ID: 01576a7). Still crashes > Explorer with FODT :( but no more crashes with ODT :) The same with Version 3.6.0.4 (Build ID: 932b512) - I'll just stay with ODT and won't use FODT anymore...
(In reply to comment #11) > I'll just stay with ODT and won't use FODT anymore... A good workaround, but not sufficient in all cases ;-) (Even for the diagnosis of some bugs (e.g. bug 52028), it can be necessary to save .odt files as .fodt files. Also some special document management applications/workflows will work better with .fodt than with .odt. Finally, working with .fodt files can save you a lot of time under some circumstances, e.g. when converting some text files from XML/SGML/*ML format, or when doing a lot of formatting changes via RegEx.) Therefore we still need a fix for this bug ...
I'm not sure if this is the same or a related bug: I just downloaded and installed LibreOffice 3.6 on Windows 7. Once the installation finished, explorer.exe started crashing. I get a "Windows Explorer has stopped working" message and the details say: Problem signature: Problem Event Name: APPCRASH Application Name: explorer.exe Application Version: 6.1.7601.17514 Application Timestamp: 4ce796f3 Fault Module Name: shlxthdl.dll Fault Module Version: 3.6.0.104 Fault Module Timestamp: 5013a4a5 Exception Code: c0000005 Exception Offset: 00011407 OS Version: 6.1.7601.2.1.0.256.1 Locale ID: 1033 Additional Information 1: a7aa Additional Information 2: a7aa91f17ea749d42a4de3b390fa5b3d Additional Information 3: a7aa Additional Information 4: a7aa91f17ea749d42a4de3b390fa5b3d When I click "Restart the program," explorer crashes again immediately. I haven't tried rebooting the system yet -- will do so now.
A restart did not solve the problem. The REGSVR32 / u shlxthdl.dll workaround did, however, work.
I am seeing this in 3.6.0.4 after installation (with or without active x) when I pinned LibreOffice to the start menu in Windows 7 x64 (intel core i7-860, 4GB ram). I tried the regsrvr workaround but windows says the file shlxthdl_x64.dll cannot be loaded, and when I do a find on the system for it (mingw find /c/ -name shlxthdl_64.dll -print), the file does not appear to be present. The only way to fix the problem on my box is to shutdown (explorer repeatedly crashes), power up, log in as a different (admin) user, uninstall at control panel, and log into my original user account. I tried reinstalling 3.6.0.4 (without active x) and it worked again until I tried pinning LO to the start menu again. For the time being I have reverted to 3.5.5. Apologies if this is not the correct location for the comment, please advise and I will repost elsewhere. Cheers!
If I understand comment #12 et seqq. correctly, this kind of crash does not happen only when .fodt files are in view, but also in other situations; therefore simplified summary.
I reinstalled 3.6.0.4 and finally was able to do the regsrvr hack and I can confirm it worked for me too.
I had 3.6 crash repeatedly no matter what the circumstances. It destroys Windows Explorer and makes the computer completely unusable. I have to restore windows to the pre install in order to use it again, so no hack is possible. I have restored it to 3.5 and no problem and reinstalled it and again it crashes non stop. I see you have a hack for this problem, but I won't bother with that. I assume this will be fixed on the next build?
(In reply to comment #18) > I had 3.6 crash repeatedly no matter what the circumstances. It destroys > Windows Explorer and makes the computer completely unusable. I have to restore > windows to the pre install in order to use it again, so no hack is possible. I > have restored it to 3.5 and no problem and reinstalled it and again it crashes > non stop. To any future commenters to this bug (or any other bug): please refrain from adding "me too"-style comments that do not add any new information. They only clutter the bug history. I see you have a hack for this problem, but I won't bother with > that. Suit yourself. > I assume this will be fixed on the next build? No. It will be fixed after someone has found what causes the problem. Your comment has not contributed the tiniest bit to that goal.
Andras discovered that the library in 3.6 does not export GetVersionInfo.
That should actually not make any difference, because that function is specific to our dmake build system, not a part of COM API as I mistakenly thought. But I am going to provide a patch anyway, on the odd chance it is the problem :-)
---> REGSVR32 / u shlxthdl.dll got " the module shlxtdhdl.dll failed to load , the spesified module could not be found" still explorer stop working, error. cannot open file. the only ways to disable the error is set the view into list, not the icon. and just set it, "never show thumnail" could help this problem. but really annoying cauze you couldnt set your hapilly environment work. hopefully this bugs getting fix soon.
Please do not change the status from ASSIGNED to NEEDINFO without reason; we are all happy that this bug is assigned (at least for now), so why change the status back to NEEDINFO?
Here too have a problem after new install of LO 3.6 @Win7 Pro 32bit The hack with regsrv32 is unsuccessful: [Content] The module "shlxthdl.dll" failed to load. Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files. The specified module could not be found. Problem solved with ShellExtView from NirSoft and disabled extension LibreOffice Tumbnail Viewer (C:\Program Files\LibreOffice 3.6\program\shlxthdl)
(In reply to comment #20) > Andras discovered that the library in 3.6 does not export GetVersionInfo. That was a dead-end, but now I know what the problem is. Fridrich rewrote zip file handling in shell extension in order to avoid the need of minizip. I did not check how it worked in 3.5, but now shell extension tries to find a zip structure even in Flat ODF files, and fails miserably. 3.5 does not crash, but it does not show Flat ODF properties either. As a quick fix, we can disable shell extension for Flat ODF files (scp2). Later we may need to extend shell extension to handle Flat ODF, too. Sorry David for misleading you, it was not your fault after all.
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=68909d3d25da0fe350319dfc82ca5b8fe9f38dc8 fdo#52078 do not register shell extensions for Flat ODF
Andras Timar committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5c740bd0aece50c62fa5c2d1d9382398ec6a2eb9&g=libreoffice-3-6 fdo#52078 do not register shell extensions for Flat ODF It will be available in LibreOffice 3.6.2.
Andras Timar committed a patch related to this issue. It has been pushed to "libreoffice-3-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9c57e1542ef743cb6ce8fe79b05fe8552e946375&g=libreoffice-3-6-1 fdo#52078 do not register shell extensions for Flat ODF It will be available already in LibreOffice 3.6.1.
I submitted two follow-up bugs: Bug 53533 - shlxthdl_x64.dll/shlxthdl.dll causes Windows Explorer to CRASH when corrupted ODF file is in view Bug 53534 - shlxthdl_x64.dll/shlxthdl.dll cannot handle Flat ODF (enhancement) I close this one, because the original problem (crash on .fodt) has been resolved.
@ Andras: Thank you very much for all your investigation into this nasty issue and for fixing it! Your fix will save many users from moments of despair ...
I wrote a workaround as a Command Prompt script (a .cmd file): ----- For %%I In ( fodg fods fodt ) Do Reg.exe Delete HKLM\Software\Classes\.%%I\ShellEx\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1} /ve /f 2> Nul ----- This command erases the reference to the faulty DLL and stops any crash from ocurring. But it would be best if the DLL was corrected to not crash when it finds a corrupt file or a file it doesn't understand.
I think the issue is not solved yet, but as I have limited knowledge in comparison to most people in here I won't reopen it on my own... I just downloaded and installed LO 3.6.1 on Windows 7 (64bit) today and what I got was a loop of this "Windows explorer stopped working" thingy. According to the details of the error message there is still a problem with shlxthdl_x64.dll It doesn't have anything to do with .fodt because I only have .odt and furthermore the probem persists after several restarts (without an Explorer window being open) - I could only solve it by going back to the system restore point which was created before the installation of LO 3.6.1. (which was the last programme installed before the error occured). As it has been mentioned before as a possible source of problems - I also have LO pinned to the windows taskbar...
(In reply to comment #32) > It doesn't have anything to do with .fodt because I only have .odt OK, that's it. Then it is a different bug. This bug is about crash on flat ODF. That has been fixed, your bug probably has not. Your resolution "WONTFIX" is not appropriate. This bug is "FIXED", and we would never mark a crasher as "WONTFIX".
*** Bug 54181 has been marked as a duplicate of this bug. ***
I had the same problem. I just downloaded and installed version 3.6.1.2 on Windows XP SP3, disabling the installation of the addon for the Microsoft Explorer, and the problem was solved.
Is it really fixed ? I have the same problem with LO 3.6.2 on Windows XP SP3 How do you disable the addon installation ?
- this bug is not related to x86-86 (happened on x86 windows) or Seven only (on XP too) - it's not for flat files only, it crashes the explorer for "normale" ods and odt as well - it was **not** fixed in 3.6.1 maybe it is another bug, but the most relevant one was flagged as duplicate of this one, so I comment here instead. To temporary fix this: - go to software management (don't know the right name in English, I don't have access to windows in English), where you can remove software - For LibreOffice, --select uninstall, and install OpenOffice instead-- (just joking...), select **modify**, NOT uninstall :) - in the LibreOffice installer, you can repair, modify etc., just select "modify" again. - there is a list of LO components, just unselect "windows explorer addon" (the closest option relative to this, I don't know how it's labelled in English) Now you can select again your ODF files from explorer.exe
Seems pretty hideous - Fridrich; was it your zip changes to this that changed things here ? can you chase ? eric: is this for -any- .odf file ? can you reproduce it with a single blank .odt document saved by LibreOffice in a directory ? if not - we'd need a document that causes the failure attached: clearly we can't easily reproduce it here. Thanks !
I have the same problem on a windows 7 64bit. The file that create the crash is not a document but a broken link to a normal odt file
Created attachment 76636 [details] Version 3.6 crashes. Version 4.0.1.2 doesn't Using v3.6, Windows Explorer crashes upon seeing the folder containing a v3.6 .fodt file. Don't even need to enter the folder to crash. Using v4.0.1.2, Windows Explorer DOES NOT crash even when renaming (or otherwise Explorer-manipulating said file). However, v4.0.1.2 cannot open the v3.6 .fodt file. Using v4.0.1.2, a v4.0.1.2 .fodt file can be opened. Also tested with non-blank .fodt replete with formatting. This issue should probably remain opened until future versions of Writer can automatically corrected previous versions of .fodt files.
Jon - great to know that 4.0 doesn't crash the Windows Explorer anymore thumbnailing / extracting meta-data from a .fodt. Fridrich - does that give us anything to go on that we could back-port to -3-6 ?
Fridrich - I'd love to get this closed; particularly if it's something easy to identify that we can back-port to -3-6 ... :-)
I proposo to close this bug report since the 3.6.x branch is no longer supported and the 4.0.x branch doesn't crash anymore.
(In reply to comment #40) > Created attachment 76636 [details] > Version 3.6 crashes. Version 4.0.1.2 doesn't 3.6.x is no longer supported and in current branches the crash is not present. so marking as FIXED. > Using v4.0.1.2, Windows Explorer DOES NOT crash even when renaming (or > otherwise Explorer-manipulating said file). However, v4.0.1.2 cannot open > the v3.6 .fodt file. I opened with no issues the "Blank_Document_v3.6.fodt" file you uploaded using LibO 4.0.4 on Win7 64bit > This issue should probably remain opened until future versions of Writer can > automatically corrected previous versions of .fodt files. as said before, it seems working now with more recent 4.0.x releases. if you still experience issues open a new bug report with test file.