Crash while display file-descripion (8.0ß18 64Bit)

[shortwave]

Hello,
i have many photos with geo-tags, on "mouse-over" to display the file-description, totalcmd crashed. I try to disable comments from explorer (ole2) - no crash, but no file-info.
Version 7.56a works fine.

Greets
Tom
(sorry for my bad english)

[ghisler(Author)]

Sounds like a faulty 64-bit shell extension. TC 7.56a is 32-bit and can see only 32-bit shell extensions.

Try using ShellExView to find the problematic extension. Just search for ShellExView here in the forum for instructions.

[shortwave]

OK, i found the PhotoMetadataHandler: "PhotoMetadataHandler.dll" in system32. I disabled she Shellextension: no crash, but a lot less info.

I try to restore the file from the inst-base, if active totalcommander crashes.
Hmm, my other Filemanager (even a 64Bit) can handle this ... ist there a way to mak this running?

Greets
Tom

[ghisler(Author)]

Try re-enabling it - often there is just a bug in the registry which causes the crash. If this doesn't help, you can only ask the maker of the dll for help.

[karlchen]

Hello, Christian.

Asking the producer of the shell extension "Photo Extract Image", description "Photo Metadata Handler", file C:\Windows\system32\PhotoMetadataHandler.dll, version 6.1.7600.16385 (win7_rtm.090713-1255), may not have the desired result. The producer is the Microsoft Corporation. Their 64-bit Explorer does not have any problems with it.

Cf. this thread, please, [8.0ß23 x64] Image OLE tooltip crash.

Disabling and re-enabling the "Photo Extract Image" extension with Nir Sofer's shellexview does not solve the problem.

I admit that in the past, very often third party shell extensions were faulty and their authors could and did fix the problem. Yet, this is a Microsoft shell extension. As the 32-bit "Photo Extract Image" extension does not cause any trouble to 32-bit T.C. editions, it is not totally unlikely that the 64-bit T.C. editions might be part of the problem themselves.

In general, the long list of reports where T.C. crashes because of a faulty shell extension, where Explorer does not do so, suggest that Explorer might be a little bit more tolerant in handling shell extensions which do not stick to the rules 100%, whereas the same shell extensions make T.C. crash.

True that simply sticking to the shell extension rules published by Microsoft is a valid approach, at least as a starting point. Yet, the frequent complaints about T.C. stumbling upon shell extensions which do not cause problems to Explorer might suggest that this approach is not sufficient in the long run. Finding out what Explorer does in order not to crash on faulty shell extensions, finding out which level of faultiness is acceptable to Explorer and what it does to protect itself from crashing will be no trivial task. Yet, the current situation where identifying the misbehaviing shell extension and working around it is left to the T.C. users alone is dissatisfying. And it may make users switch away from T.C. to another filemanager which does not exhibit this behaviour.

Even if it may not be possible to catch all faulty shell extensions and avoid the crash in all situations, yet, it might be encouraging to know that T.C. at least tries to do so.

Kind regards,
Karl
--
P.S.:
WER has been allowed to send out a report to Microsoft about the crash. I am not sure, however, whether sending those reports will have any effect. I wonder whether Microsoft does more with such reports than collecting them in some archiving system or whether they simply store them to /dev/null.
After all, the sheer number of received WER reports might make it difficult to differentiate between already known (and maybe solved) problems and new problems.

[petermad]

True that simply sticking to the shell extension rules published by Microsoft is a valid approach, at least as a starting point. Yet, the frequent complaints about T.C. stumbling upon shell extensions which do not cause problems to Explorer might suggest that this approach is not sufficient in the long run. Finding out what Explorer does in order not to crash on faulty shell extensions, finding out which level of faultiness is acceptable to Explorer and what it does to protect itself from crashing will be no trivial task. Yet, the current situation where identifying the misbehaviing shell extension and working around it is left to the T.C. users alone is dissatisfying. And it may make users switch away from T.C. to another filemanager which does not exhibit this behaviour.

Well written. I think there is a lot of truth in this statement !

[ghisler(Author)]

I have seen shell extensions which tried to access parts of Explorer, which of course failed when they were run from TC. Others crash when TC is unloaded because Explorer itself is apparently never unloaded. There may be many other such cases which cause a shell extension to crash where TC cannot do anything.