News:

2023-03-15 Major improvements to the new Geolocation feature

Main Menu

ExifTool >10.20 not running on Win10 x64

Started by gwegner, July 28, 2016, 05:22:22 AM

Previous topic - Next topic

Phil Harvey

Quote from: gwegner on July 29, 2016, 04:53:56 AM
Even if that worked it wouldn't help the end user.

Surely your app can set an environment variable before it launches exiftool.

In C, this would be done via the standard execle() library function.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Phil Harvey

#16
Yup.  I was able to update Windows Defender from a USB stick, and can reproduce the effect you are seeing, with the exception that exiftool doesn't hang for me -- it just takes a long time to start up, even after I delete the temporary files and try again.

And unfortunately it doesn't help to change PAR_GLOBAL_TEMP to put the temporary files somewhere else.  The problem seems to be that Windows Defender is just taking a long time to scan the files that ExifTool uses.

I can also report that this problem is not limited to ExifTool >10.20, it also affects earlier versions (application launch is greatly slowed, although not quite as much as later versions).

Basically, Windows Defender is crap.  It is introducing a huge inefficiency when exiftool is launched.  I don't think there is anything we can do to fix this except disable Windows Defender and hope that Microsoft fixes their crappy software.

For what it's worth, I have submitted a report about this to Microsoft.

- Phil

Edit: No response yet from Microsoft.
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

gwegner

Hi Phil, I understand that you are disappointed. But claiming the the Windows Defender is crap, just because it struggles with some files in your package is a bit strange. At least it works with tons of other software without any problems and it's the most unobtrusive anti virus solution available on Windows. I'm more then happy, that Microsoft finally has a working and (usually) fast AV-solution directly built in - this saves a lot of trouble with the 3rd party AV tools that most users install. They are mostly bloated and often they serve more the AV company to make money then anyone else.

Let's hope that microsoft reacts and everything gets back to normal. But I wouldn't rely on that.
I've had a case like this once, where I had introduced a special hash function to my code that drove the av scanners mad. After replacing that function with something else, everything was back to normal. It might be worth to do some tests to find out which is the critical file that the scanners stumbles upon and see if there is something that you can do.
I know how disgusting it is to search for problems like this, especially if the happen on the platform you don't normally use, but sometimes it's necessary in order to save the users from trouble.

Phil Harvey

I think the problem is out of my hands.  I didn't write the PAR packager that is used to package the Windows exe version of ExifTool.  I thought there may be some hope if there was a difference with older versions of ExifTool (since I updated the PAR version in ExifTool > 10.20), but even older versions of ExifTool show this slow-down problem when the current version of Windows Defender is active.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

gwegner

Hi Phil, thank you anyway for your time. I will add a topic to my faq that recommend adding exiftool to the exceptions of the virus scanner if its performance is bad.

Keep up the great work!
Best,
Gunther

Phil Harvey

Hi Gunther,

I should note that I tried adding both "exiftool.exe" and "exiftool(-k).exe" to the Windows Defender exceptions settings.  It didn't have an immediate effect for me, but after rebooting somehow the ExifTool launch time dropped from about 4 seconds to maybe 1 or 2 seconds.  Deleting these exceptions returned the time to ~ 4 secs.  However, it was still faster (< 1 sec) to turn off Windows Defender completely.

Also, isn't it a huge security hole to add an exception by name?  All a virus writer has to do is name his .exe the same as some other commonly excepted piece of software.  Doesn't sound too smart to me.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

gwegner

I've never had to enter any exception there before.

johnpdoe

Hi,

this thread was a saver! I have a little tool that makes use of exiftool, and all hell broke loose after I moved it to a new install of Windows 10 Pro x64. An old version of exiftool would run albeit very slowly (10s to open), (20s+ to edit a tag in a jpg). Updated to the latest version of exiftool and it would not run at all.

Windows Defender > Settings > exclusions > Add exiftool.exe, and happy days.

Thanks for the great info!

Phil Harvey

Quote from: johnpdoe on July 31, 2016, 07:02:15 AM
Windows Defender > Settings > exclusions > Add exiftool.exe, and happy days.

I'm glad you're happy, but when I did this exiftool was still noticeably slower than when Windows Defender was disabled completely.  Do you find this?

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

ammalena

This workaround does not work for me (in relation to a semi-related posting below).  I tried adding the exclusion, and I tried disabling Defender.  No go.

https://exiftool.org/forum/index.php/topic,7418.0.html
-Anthony

odinson

Thank you! This thread has helped me a lot with my ExifTool launch speed issues.

Quote from: Phil Harvey on July 29, 2016, 09:15:46 AM
Also, isn't it a huge security hole to add an exception by name?  All a virus writer has to do is name his .exe the same as some other commonly excepted piece of software.  Doesn't sound too smart to me.

I didn't quite understand this. Don't all AVs allow adding exceptions by file or folder name (even allowing wildcards)? How else is an end user supposed to specify the exclusion? Of course the AV is free to internally do whatever it wants, like put some unique hash in its exclusion database.

Phil Harvey

Quote from: odinson on November 22, 2016, 09:47:41 PM
How else is an end user supposed to specify the exclusion?

I'm not solving the problem, I'm just pointing it out.  But as an example, the AV could use an MD5 checksum to identify the excluded software.  Then it would stop being excluded if the software was upgraded or somehow got infected.  I know this would be a big performance hit, but as I said I'm not solving the problem.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

odinson

Quote from: Phil Harvey on November 23, 2016, 07:13:01 AMBut as an example, the AV could use an MD5 checksum to identify the excluded software.
That's what I said too - "Of course the AV is free to internally do whatever it wants, like put some unique hash in its exclusion database." So how do we know for sure that Defender is not doing this?

Phil Harvey

Quote from: odinson on November 24, 2016, 09:24:04 AM
So how do we know for sure that Defender is not doing this?

It isn't doing this if you don't have to re-do the exclusion after you update ExifTool.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

odinson

Quote from: Phil Harvey on November 24, 2016, 09:38:21 AM
It isn't doing this if you don't have to re-do the exclusion after you update ExifTool.

Interesting, thanks. Now I have to check my other AVs because I distinctly remember adding exclusions long back and having updated the EXEs with no warnings whatsoever, so I don't know whether the exclusions are still in effect.