Bug Hunting Session
Bug 52078 - shlxthdl_x64.dll/shlxthdl.dll causes Windows Explorer to CRASH repeatedly when Flat ODF file is in view
Summary: shlxthdl_x64.dll/shlxthdl.dll causes Windows Explorer to CRASH repeatedly whe...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.6.0.1 rc
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Andras Timar
URL:
Whiteboard: BSA target:3.7.0 target:3.6.1
Keywords: regression
: 52276 54181 (view as bug list)
Depends on:
Blocks: Desktop-Integration mab3.6
  Show dependency treegraph
 
Reported: 2012-07-14 10:06 UTC by Thomas Bigler
Modified: 2019-05-22 04:10 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
ZIP file, containing depends dump for shlxthdl_x64.dll (492.27 KB, application/x-7z-compressed)
2012-07-25 13:40 UTC, Roman Eisele
Details
Version 3.6 crashes. Version 4.0.1.2 doesn't (7.60 KB, application/zip)
2013-03-17 07:08 UTC, Jon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Bigler 2012-07-14 10:06:11 UTC
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
Comment 1 David Tardon 2012-07-16 05:04:14 UTC
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).
Comment 2 Thomas Bigler 2012-07-17 23:24:15 UTC
(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.
Comment 3 David Tardon 2012-07-20 06:57:53 UTC
*** Bug 52276 has been marked as a duplicate of this bug. ***
Comment 4 Roman Eisele 2012-07-20 07:23:35 UTC
NEW because of duplicate (and because the question from comment #1 was answered in comment #2, so NEEDINFO is obsolete).
Comment 5 Roman Eisele 2012-07-20 08:05:51 UTC
(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!)
Comment 6 Roman Eisele 2012-07-21 17:14:52 UTC
Keyword 'regression' added because of comment #2.
Comment 7 David Tardon 2012-07-23 11:50:31 UTC
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?
Comment 8 Roman Eisele 2012-07-24 08:12:53 UTC
(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!
Comment 9 Roman Eisele 2012-07-25 13:40:18 UTC
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!
Comment 10 Thomas Bigler 2012-07-26 20:05:35 UTC
(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 :)
Comment 11 Thomas Bigler 2012-07-31 16:38:22 UTC
(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...
Comment 12 Roman Eisele 2012-08-01 08:03:50 UTC
(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 ...
Comment 13 Harald Kliems 2012-08-08 17:39:02 UTC
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.
Comment 14 Harald Kliems 2012-08-08 18:01:43 UTC
A restart did not solve the problem. The REGSVR32 / u shlxthdl.dll workaround did, however, work.
Comment 15 Lee Elia 2012-08-09 13:55:38 UTC
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!
Comment 16 Roman Eisele 2012-08-09 14:14:29 UTC
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.
Comment 17 Lee Elia 2012-08-09 19:03:59 UTC
I reinstalled 3.6.0.4 and finally was able to do the regsrvr hack and I can confirm it worked for me too.
Comment 18 Bryan Karlan 2012-08-10 02:59:17 UTC
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?
Comment 19 David Tardon 2012-08-10 06:28:28 UTC
(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.
Comment 20 David Tardon 2012-08-10 07:33:18 UTC
Andras discovered that the library in 3.6 does not export GetVersionInfo.
Comment 21 David Tardon 2012-08-10 07:46:25 UTC
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 :-)
Comment 22 senjaya 2012-08-11 03:54:56 UTC
--->  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.
Comment 23 Roman Eisele 2012-08-11 16:11:16 UTC
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?
Comment 24 Topper 2012-08-14 12:04:22 UTC
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)
Comment 25 Andras Timar 2012-08-14 19:22:23 UTC
(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.
Comment 26 Not Assigned 2012-08-14 20:05:59 UTC
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
Comment 27 Not Assigned 2012-08-15 05:43:07 UTC
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.
Comment 28 Not Assigned 2012-08-15 08:29:58 UTC
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.
Comment 29 Andras Timar 2012-08-15 10:50:06 UTC
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.
Comment 30 Roman Eisele 2012-08-16 08:49:28 UTC
@ 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 ...
Comment 31 João Paulo 2012-08-20 19:36:24 UTC
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.
Comment 32 acappella 2012-09-06 07:34:48 UTC
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...
Comment 33 Andras Timar 2012-09-06 07:56:14 UTC
(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".
Comment 34 Andras Timar 2012-09-17 16:03:03 UTC
*** Bug 54181 has been marked as a duplicate of this bug. ***
Comment 35 George Peppas 2012-09-18 10:55:51 UTC
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.
Comment 36 sebastien.ramage 2012-10-05 10:16:47 UTC

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 ?
Comment 37 eric f 2012-11-29 14:45:47 UTC
- 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
Comment 38 Michael Meeks 2012-12-10 11:00:20 UTC
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 !
Comment 39 d.zanni 2013-01-30 09:06:22 UTC
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
Comment 40 Jon 2013-03-17 07:08:38 UTC
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.
Comment 41 Michael Meeks 2013-03-18 09:39:52 UTC
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 ?
Comment 42 Michael Meeks 2013-05-16 13:35:41 UTC
Fridrich - I'd love to get this closed; particularly if it's something easy to identify that we can back-port to -3-6 ... :-)
Comment 43 tommy27 2013-07-30 20:14:33 UTC
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.
Comment 44 tommy27 2013-08-03 07:51:23 UTC
(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.