Icaros Thumbnail Provider crashing Windows Explorer COM surrogate

Running Windows 8.1 64-bit with latest K-Lite codec pack.  When using Windows Explorer (customised to Videos and set to view thumbnails) I consitently get COM Surrogate (dllhost.exe) crashing in the msvcrt.dll module when explorer scans a folder with files or sub-folders cointaining .TS (mpeg) files of 4GB or larger.  I have used ShellExView to identify two separate shell extensions that both individually cause these crashes:

1) Icaros Thumbnail Provider
2) MF MPEG Property Handler

I can disable these (using ShellExView) to avoid the COM Surrogate crashes, but of course I also lose my thumbnails and/or file propety data (e.g. video length).  

Can anybody help identify the cause (which may be common to both shell extensions) or suggest alternate ways to maintain thumbnails and media property data?

Further details of the problem and my analysis can be seen here:
http://social.technet.microsoft.com/Forums/windows/en-US/daa002fd-a833-42ce-b2cd-eeb7bcefbfef/explorer-crashing-when-generating-thumbnails-view-for-large-4gb-video-ts-files?forum=w7itproui&prof=required

PS: I have already view the FAQ Q: How to fix "COM Surrogate has stopped worked" errors on Windows Vista?

Are you sure the crashing module is named msvcrtl.dll (and not msvcrt.dll)? Because that isn't a standard DLL from Windows 8.1. Icaros also does not use that DLL.

I suspect your problem is caused by another program that is running in the background and has hooked itself into some Windows functions. It is probably an older program as well.

Download Process Explorer:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Use its search function to check which applications have a handle to the msvcrtl.dll file.

Admin wrote:Are you sure the crashing module is named msvcrtl.dll (and not msvcrt.dll)? Because that isn't a standard DLL from Windows 8.1. Icaros also does not use that DLL.

I suspect your problem is caused by another program that is running in the background and has hooked itself into some Windows functions. It is probably an older program as well.

Download Process Explorer:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Use its search function to check which applications have a handle to the msvcrtl.dll file.

Yes, it is msvcrt.dll (just a typo, which I have corrected).  As to other programs, I doubt this as I still have the problem in Safe mode.

Also, Process Explorer displays very many (72) processes using this dll, which is to be expected as it is the Visual C Run Time Library.

I don't have any problems with .ts files larger than 4GB. Neither does the developer of Icaros. So there is probably something specific about your files, assuming the rest of system is ok. Which program created those files?

Can you go into the Windows Event Viewer and copy the full crash details? For example the "Fault offset" would be interesting, that shows where inside msvcrt.dll the crash occurred.

With the Codec Tweak Tool you can disable thumbnailing for individual file extensions.

Also post a MediaInfo log for one of the files.

I assume that playback of those files works without problems?

You could also test if remuxing the files solves the crash. Then at least you know the problem is related to the files.

Here is a tool for remuxing:
http://www.videohelp.com/tools/tsMuxeR

You can disable property reading of .ts files by removing this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\.ts
(don't forget to export the key as a backup first)

Admin wrote:I don't have any problems with .ts files larger than 4GB. Neither does the developer of Icaros. So there is probably something specific about your files, assuming the rest of system is ok. Which program created those files?

Can you go into the Windows Event Viewer and copy the full crash details? For example the "Fault offset" would be interesting, that shows where inside msvcrt.dll the crash occurred.

With the Codec Tweak Tool you can disable thumbnailing for individual file extensions.

Info from Event Viewer posted below. The files were created on a PVR, copied to a USB (to decode them) and then copied via FTP to the PC.
I know I can disable the thumbnails, but this doesn't solve the problem as it is only a few of the files that cause crashes. Also, it would not solve the problem of crashes caused by the MS Property Handler.
My objective is not to avoid the crashes by disabling functionality but to avoid the crashes and maintain functionality.

Faulting application name: DllHost.exe, version: 6.3.9600.16384, time stamp: 0x5215dfc6
Faulting module name: msvcrt.dll, version: 7.0.9600.16384, time stamp: 0x5215f944
Exception code: 0xc0000005
Fault offset: 0x000000000000193f
Faulting process ID: 0x150c
Faulting application start time: 0x01cf8d7e658e1ec3
Faulting application path: C:\Windows\system32\DllHost.exe
Faulting module path: C:\Windows\system32\msvcrt.dll
Report ID: a440edea-f971-11e3-8358-a4db3096cc7c
Faulting package full name:
Faulting package-relative application

Admin wrote:You can disable property reading of .ts files by removing this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\.ts
(don't forget to export the key as a backup first)

As mentioned above, I want to avoid crashes but maintain functionality, so this would not help.

Admin wrote:Also post a MediaInfo log for one of the files.

I assume that playback of those files works without problems?

Could you be more specific as what info from MediaInfo would help as I'm not familiar with it.   The files do play OK.

Admin wrote:You could also test if remuxing the files solves the crash. Then at least you know the problem is related to the files.

Here is a tool for remuxing:
http://www.videohelp.com/tools/tsMuxeR

Progress!  
At the start of remuxing the remuxer reported some invalid tracks (which would be ignored) but completed correctly. The output report is copied below.  
The output file, although having the same run-time, has a considerably reduced file size (4,194,304 KB reduced to 3,533,081 KB). Presumably this is due to the ignored tracks.
The remuxed file plays fine and does not cause a crash, however this may be because it is now below 4GB in size.
I shall try some more file and post the results.

Network Optix tsMuxeR.  Version 2.6.12. www.networkoptix.com
Decoding MPEG-Audio stream (track 2): Bitrate: 192Kbps  Sample Rate: 48KHz  Channels: 2  Layer: 2
Decoding MPEG-Audio stream (track 3): Bitrate: 64Kbps  Sample Rate: 48KHz  Channels: 1  Layer: 2
MPEG-2 muxing fps is not set. Get fps from stream. Value: 25
Decoding MPEG2 stream (track 1): Profile: Main@8. Resolution: 704:576i. Frame rate: 25
MPEG-Audio stream (track 2): bad frame detected at position01:57:11,952. Resync stream.
Decoding MPEG-Audio stream (track 2): Bitrate: 192Kbps  Sample Rate: 48KHz  Channels: 2  Layer: 2
Processed 294217 video frames
Flushing write buffer
Mux successful complete
Muxing time: 2 min 29 sec

Warning! The file XXXX.ts has a M2TS format.

4,194,304 KB is exactly 4GB. Are all the files that size? Maybe the files are truncated or otherwise contain incomplete data at the end that somehow is causing the problem. Or did they originate from a FAT32 partition?

Would it be possible for you to provide the Icaros developer access to one of those files? He knows about this topic. You can send him an e-mail at: xanashi [at] gmail [.] com

The crash in the Microsoft components is of course something that only Microsoft can fix.

Admin wrote:4,194,304 KB is exactly 4GB. Are all the files that size? Maybe the files are truncated or otherwise contain incomplete data at the end that somehow is causing the problem. Or did they originate from a FAT32 partition?

Would it be possible for you to provide the Icaros developer access to one of those files? He knows about this topic. You can send him an e-mail at: xanashi [at] gmail [.] com

The crash in the Microsoft components is of course something that only Microsoft can fix.

Yes, they all came from a PVR via a FAT-32 USB drive, so this may well be the issue. I have remuxed all of the problem files, some worked, some didn't. I have yet to check all of the remuxed files against the originals, but all are now less that 4GB. These files did not, though, cause problems when I was running Windows 7 (32-bit) and played OK.

I will email xanashi

Update. I have checked the remuxed files. Although none now cause crashes, they have all lost audio synchronisation and are effectively useless.

FAT32 is limited to 4GB, so you should try with a NTFS formatted drive.

Is the sync different constant, or does it grow during playback? You may be able to fix it with muxing settings. For example by specifying the fps or an offset.

You can view file properties with the MediaInfo tool (included in the pack). Could be interesting to compare the original with the remuxing one.

Admin wrote:FAT32 is limited to 4GB, so you should try with a NTFS formatted drive.

Is the sync different constant, or does it grow during playback? You may be able to fix it with muxing settings. For example by specifying the fps or an offset.

You can view file properties with the MediaInfo tool (included in the pack). Could be interesting to compare the original with the remuxing one.

The PVR I am using (a Humax) does not support NTFS so it is not possible to transfer files via this file system. Further research has, though, identified an unsupported customised set of firmware for the PVR which does support NTFS and I am considering trying this in the hope that it will avoid problems with future recordings. My main concern is that this will invalidate the warranty on the PVR.

What is strange is that most (but not all) files, although apparently truncated to 4GB, do play to the end of the recording (before remuxing) so the content does not appear to be truncated.

It is would be far too much effort to try to resync the various files as each play fine before remuxing. I have selectively excluded the problem files from thumbnail/property scanning by temporarily changing the file extensions on the problem files only. This way, I have avoided the crashes, but continue to get thumbnails and properties for the other files.

I have had a look at MediaInfo but cannot find how to do a file comparison between files (original vs remuxed) - can you please advise.

Here is some sample output from a Remux:
Input
Source 1: Codec: MPEG-2 Profile: Main@8. Resolution: 704:576i. Frame rate: 25
Source 1: Codec: MPEG-Audio Bitrate: 192Kbps Sample Rate: 48KHz Channels: 2 Layer: 2
Source 1: Codec: MPEG-Audio Bitrate: 64Kbps Sample Rate: 48KHz Channels: 1 Layer: 2

Output (TS muxing)
Meta file
MUXOPT --no-pcr-on-video-pid --new-audio-pes --vbr --vbv-len=500
V_MPEG-2, "D:\Downloads\Alexander (2004) [TS ERROR]\Alexander.ts", track=4113
A_MP3, "D:\Downloads\Alexander (2004) [TS ERROR]\Alexander.ts", timeshift=-363ms, track=4352, lang=eng
A_MP3, "D:\Downloads\Alexander (2004) [TS ERROR]\Alexander.ts", timeshift=-267ms, track=4353, lang=eng

Remux Report
Network Optix tsMuxeR. Version 2.6.12. www.networkoptix.com
Decoding MPEG-Audio stream (track 2): Bitrate: 192Kbps Sample Rate: 48KHz Channels: 2 Layer: 2
Decoding MPEG-Audio stream (track 3): Bitrate: 64Kbps Sample Rate: 48KHz Channels: 1 Layer: 2
MPEG-2 muxing fps is not set. Get fps from stream. Value: 25
Decoding MPEG2 stream (track 1): Profile: Main@8. Resolution: 704:576i. Frame rate: 25
Processed 294217 video frames
Flushing write buffer
Mux successful complete
Muxing time: 2 min 15 sec

NB:
1) General Track options left at the default Delay of -267ms - Is this correct?
2) Output selected as TS muxing, however I noticed some files warned as being M2TS - should this option be selected for these files?

There is no standard value for the audio delay. It probably reads the values from the input file.

You could also try a completely different container for the file, such as Matroska (.mkv). You can re-mux to .mkv with a tool called MkvToolnix.