Bug 53420 - Windows Explorer freezes when a LibreOffice document is selected through a network share
Summary: Windows Explorer freezes when a LibreOffice document is selected through a ne...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.6.1.2 release
Hardware: x86 (IA32) Windows (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard: target:3.6.2
Keywords: regression
Depends on:
Blocks:
 
Reported: 2012-08-12 20:03 UTC by AntonioGM
Modified: 2013-04-21 17:29 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description AntonioGM 2012-08-12 20:03:29 UTC 
After updating to LibreOffice 3.6, when I select an ODS document from Windows Explorer through a network share, that window freezes for about 30 seconds. Once the window unfreezes, I cannot move or rename the document because it has been kept opened.

This doesn't happen when selecting a file not associated with LO, as Word documents (associated to MSO) or folders. It also doesn't happen on local files.

That problem dissapears after executing: REGSVR32 /u shlxthdl.dll
Comment 1 MarkL 2012-08-16 12:39:24 UTC 
I can confirm this issue.

When I reinstalled 3.6 and choose customer install and select Explorer Shell Integration NOT INSTALLED, the problem disappeared.

Win XP SP3
Novell Netware Server
Comment 2 João Paulo 2012-08-20 19:31:46 UTC 
(In reply to comment #1)
> I can confirm this issue.
> 
> When I reinstalled 3.6 and choose customer install and select Explorer Shell
> Integration NOT INSTALLED, the problem disappeared.
> 
> Win XP SP3
> Novell Netware Server

I also can confirm it:

The problem is the shell thumbnail extractor (shlxthdl.dll), which doesn't
recognize the Flat ODT files (.fodg, .fods, .fodt).

Windows Explorer, when listing folder contents, queries
"HKEY_LOCAL_MACHINE\SOFTWARE\Classes\<extension>" for each file extension it
finds and, if exists the subkey
"<extension>\shellex\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}", it queries the
default value.

In the case of the Flat ODT files, this value has
"{3B092F0C-7696-40E3-A80F-68D74DA84210}" written in it, which relates to
"HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{3B092F0C-7696-40E3-A80F-68D74DA84210}\InprocServer32",
which in turn shows the path to "shlxthdl.dll".

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 3 Slava 2012-08-21 09:07:07 UTC 
Just to mention: I experience explorer freezes on all libre office files, even local ones. Version 3.6.0.4.
The shellex for odt file extension are:
{087B3AE3-E237-4467-B8DB-5A38AB959AC9}
{3B092F0C-7696-40E3-A80F-68D74DA84210}
Both point to shlxthdl.dll from libreoffice install.

Few stack traces from freeezing explorer:

MSVCR90.dll!_read_nolock+0x203
MSVCR90.dll!_read+0xc0
MSVCR90.dll!_filbuf+0x7d
MSVCR90.dll!_fread_nolock_s+0x167
MSVCR90.dll!fread_s+0x75
MSVCR90.dll!fread+0x18
shlxthdl.dll!DllCanUnloadNow+0xa08d
shlxthdl.dll!DllCanUnloadNow+0x7260
shlxthdl.dll!DllCanUnloadNow+0x7326
shlxthdl.dll!DllCanUnloadNow+0x7719
shlxthdl.dll!DllCanUnloadNow+0x776b
shlxthdl.dll!DllCanUnloadNow+0x7938
shlxthdl.dll!DllCanUnloadNow+0x11a2
SHELL32.dll!CThumbnail::_BitmapFromIDList+0xe3



MSVCR90.dll!_read_nolock+0x203
MSVCR90.dll!_read+0xc0
MSVCR90.dll!_filbuf+0x7d
MSVCR90.dll!_fread_nolock_s+0x167
MSVCR90.dll!fread_s+0x75
MSVCR90.dll!fread+0x18
shlxthdl.dll!DllCanUnloadNow+0xa08d
shlxthdl.dll!DllCanUnloadNow+0x7260
shlxthdl.dll!DllCanUnloadNow+0x7326
shlxthdl.dll!DllCanUnloadNow+0x7719
shlxthdl.dll!DllCanUnloadNow+0x776b
shlxthdl.dll!DllCanUnloadNow+0x7938
shlxthdl.dll!DllCanUnloadNow+0x11a2
SHELL32.dll!CThumbnail::_BitmapFromIDList+0xe3

It seems shlxthdl.dll spends way too much time analysing the file, just to display an icon in explorer list view!

File monitor confirms the suspicion:
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2330 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2331 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2332 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2333 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2334 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2335 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2336 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2337 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2338 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2339 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2340 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2341 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2342 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2343 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2344 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2345 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2346 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2347 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2348 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2349 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2350 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2351 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2352 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2353 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2354 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2355 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2356 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2357 Length: 512	
11:03:19	explorer.exe:1896	READ	C:\DOKUME~1\V6218~1.SYS\EIGENE~1\tmp.odp	SUCCESS	Offset: 2358 Length: 512	

The whole file is read byte after byte and that not once.

I do not know bug guidelines here but usually regression have to have highest priority assigned. Especially when explorer shell extension is installed by default.
Comment 4 Alex Thurgood 2012-08-21 15:20:17 UTC 
*** Bug 53592 has been marked as a duplicate of this bug. ***
Comment 5 jkonecny 2012-09-06 20:51:21 UTC 
This persists in 3.6.1.2.
Comment 6 Fridrich Strba 2012-09-13 13:18:26 UTC 
This is fixed in 3.6.2 RC1