-->> Shark's website <<--

Shark's Help Forum

Search
  Create an account  
dllhost.exe (32bit) hangs

#1
Hello,

Some time ago I updated K-Lite codec pack and with it it bundles the new Icaros version (3.2.0). But it makes my setup freeze when I try to generate thumbnails on a network drive from a (I guess) 32bit process.

Basically:
* When I load files from Explorer (64bit) on a local folder, everything goes well.
* When I load files from XYPlorer (32bit) on a local folder, everything goes well.
* When I load files from Explorer (64bit) on a network folder, everything goes well.
* When I load files from XYPlorer (32bit) on a network folder, I can see a process dllhost.exe that hangs and uses quite a lot of CPU. Killing the process makes the thumbnails appear and generate the next ones to freeze again.


This video shows what happens. From a 32bit XYPlorer, thumbnails generates as I kill the hanging process over and over. In explorer (64bit) it generates them fine.

[Image: mrCj2nx.png]
I mention this 32/64 bit because in the processes it seems to behave differently. When it loads from Explorer it seems to use C:\Windows\System32\dllhost.exe. But when it's from XYPlorer it uses C:\Windows\SysWOW64\dllhost.exe.

Version 3.1.1 b2 of Icaros that was bundled with K-Lite 15.1.6 doesn't have this issue and every thumbnail loads file from 32/64bits on local/network drives.
Reply

#2
(04-17-2021, 05:16 AM)RakSrinaNa Wrote: I mention this 32/64 bit because in the processes it seems to behave differently. When it loads from Explorer it seems to use C:\Windows\System32\dllhost.exe. But when it's from XYPlorer it uses C:\Windows\SysWOW64\dllhost.exe.

This is normal and expected behavior. "SysWOW64" is a directory used by Windows to provide compatibility for 32-bit applications - despite the name. System32 contains the 64-bit versions, and SysWOW64 contains the 32-bit files. So a 32-bit application would naturally invoke libraries from the SysWOW folder, and your guess that the issue is related to that seems to be right. Dllhost is used by Windows to process code from libraries (Dlls). In this case, it seems to refer to the Windows thumbnail generation and caching. The process will also be there in every case your computer uses Icaros, but the normal behavior would be that the thumbnail is generated and Dllhost moves on to the next file, all happening without a freeze and without you noticing something.

To me it looks like it's an issue with Icaros when employed by 32-bit applications. This can only be addressed by the developer. However, it is strange that only network locations are affected. Furthermore, I am suprised that the thumbnails all end up as black boxes (in Explorer too), which looks like a failure to me.

What I really don't get is - these are MP4 files, right? Windows has built-in MP4 thumbnailing support for MP4 files since Windows 7. I use Icaros for MP4, too, because it generates much better thumbnails (ie no black boxes). Check in Icaros Config whether mp4 is among the list of extensions you use Icaros for. If it is, try to remove it for the time being and let Windows generate its own thumbnails - that should work. If mp4 is not on the list, then this is not an Icaros issue, because Icaros isn't involved in the thumbnail creation of these files.

Finally, and I don't want this to sound patronizing, I would advise you to not use K-Lite. It can mess up your system by installing bloat and unneccessary filters. Most 3rd-party media players contain up-to-date codecs; and recent Windows versions will support almost all formats out of the box. I use LAVfilters to close any "gaps" and my PC plays everything. I cannot completely rule out that the issue was caused by the codec pack, because you upgraded Icaros as part of that.

I would test it on my own, but I have no network drives.

P.S. In the registry, the MP4 thumbnail handler is registered under HKEY_CLASSES_ROOT\.mp4\ShellEx\{BB2E617C-0920-11d1-9A0B-00C04FC2D6C1} and HKEY_CLASSES_ROOT\.mp4\ShellEx\{e357fccd-a995-4576-b01f-234630154e96}. The default handler is {9DBD2C50-62AD-11d0-B806-00C04FD706EC} (in both entries), and the Icaros handler is {c5aec3ec-e812-4677-a9a7-4fee1f9aa000}.
Reply

#3
Quote:Furthermore, I am suprised that the thumbnails all end up as black boxes (in Explorer too), which looks like a failure to me.


This is normal. I intentionally took a video with a black thumbnail.


Quote:What I really don't get is - these are MP4 files, right? Windows has built-in MP4 thumbnailing support for MP4 files since Windows 7.


Yeah MP4 are supported by windows, but it seems that not all encoding are. h264 would be fine, but I'm not sure h265/hevc is supported.


Quote:If it is, try to remove it for the time being and let Windows generate its own thumbnails


Removing the mp4 thumbnail handler or icaros fully both makes it not hanging. Though there's thumbnails for h265 videos that are missing.

If I install just icaros without klite I don't have the h265 videos thumbnails either. (Maybe it was because it was klite that provided things for that codec? )
Reply

#4
I tried with just Icaros 3.2.0 + LAVfilters and the issue is still present.
Reply

#5
Icaros 3.1.0 + LavFilters works fine. So to me it really seems to be a change made in Icaros between 3.1.1 b2 & 3.2.0.
Reply

#6
I'm having the same issue when using Xyplorer with Icaros. It started happening for me when I updated Icaros with my K-Lite codec pack and I believe I went from 3.2.0 b1 -> 3.2.0. However it was not just happening with network folders for me. It was happening within my local folders, just not with every thumbnail. It would generate some of them and then crash. Reverting back to 3.2.0 b2 fixed the problem for me.

I've noticed Xyplorer has these options in the config file:

Code:
; Tweak: make no thumbs: ext.ext
NoThumb=
; Tweak: no 64-bit thumbnails
Thumbs64Skip=0
; Tweak: 64-bit thumbnails
Thumbs64Ext=afphoto.afdesign.afpub.sldasm.slddrw.sldprt

; Tweak: disable WOW64 redirection on 64-bit platforms (NOT recommended with file operations!)
WOW64DisableRedirection=0
Maybe these can be tweaked to stop the problem? I might look into it.
Reply

#7
Hi RakSrinaNa,

Your report was incredibly helpful in tracking down and fixing this bug. Thank you for all the info and testing!
Please try the latest build (3.2.1), it should be fixed now. :)
Reply

#8
(05-20-2021, 12:15 PM)Xanashi Wrote: Hi RakSrinaNa,

Your report was incredibly helpful in tracking down and fixing this bug. Thank you for all the info and testing!
Please try the latest build (3.2.1), it should be fixed now. Smile

I didn't test it extensively but so far it was able to generate ~1k files without hanging (where it'd easily stop before 10 previously). 

So yeah seems to be fixed, yay.

Thank you !
Reply





Users browsing this thread:
1 Guest(s)