Hi Phil,
the latest versions 10.21 and above seem not to run on Win10 x64.
I've tried on two different machines.
On both I cannot even launch exiftool -ver or exiftool -h from the commandline, it just hangs.
When pressing Ctrl-C I get "Terminating on signal SIGINT(2)"
Exiftool 10.20 in comparison it works on both machines.
Let me know, if there is anything I can do to help you find out whats going on.
For now I will ask my LRTimelapse users to stay with the production version 10.20.
Best regards,
Gunther
Hi Gunther,
I don't understand this because since 10.21 I am building and testing the Windows release on a Win10 x64 system:
Edition: Windows 10 Home
Version: 1511
OS Build: 10586.164
System Type: 64-bit operating system, x64-based processor
Is anyone else having trouble running ExifTool 10.21+ on Win10 x64? Edit: Yes. See this thread (https://exiftool.org/forum/index.php/topic,7409.0.html).
Are you sure you don't have a conflict with antivirus software on the affected system?
- Phil
I have only the default Windows Defender running.
I've deactivated it and then the latest versions began to run too.
What's interesting: when I've activated it again, it still runs, but takes a much longer time - the difference is more then noticeable.
Maybe this helps you to narrow down what's going on!
(I don't want to have to tell my users to deactivate their virus scan...)
I doubt that there is anything I can do to help here. I fear that you will somehow have to tell Defender that ExifTool is a trusted app. Submitting a bug report for Windows Defender may be a good idea.
- Phil
Hi Phil, I don't think this is a bug in Windows Defender, I just think that Microsoft must have recently added some signatures that seem to heavily collide with ExifTool. Could you reproduce it?
The performance of any Exiftool version I've tried today is much slower then it ever was, especially for batch operations, but as well for the simple launch.
If I were you I would investigate what's happening and contact microsoft, otherwise your tool suffers a performance brake that it doesn't deserve.
Defender is the most used anti virus tool since it's built in with Windows and I'm convinced that it's not our users that we should have to ask to add exceptions to make our tools run as expected.
I checked, and I am already running this version of Windows Defender on my system where I don't have the problem:
Antimalware client version: 4.9.10586.0
Engine version: 1.1.12101.0
Antivirus definition: 1.207.2950.0
Network inspection system engine version: 2.1.11804.0
Network inspection system definition version: 115.8.0.0
So likely it is something different in your version of Windows Defender.
I also see there is a way to "Add an exclusion". I agree that it shouldn't be up to your users to do this, but does it bypass the problem for you?
- Phil
Edit: BTW, I have just added this to the list of known problems (https://exiftool.org/index.html#problems)
Hi Phil,
thanks for checking. Yes, as soon as I add the exclusion, I'm getting a huge performance boost (the usual performance).
I seem to have a somehow newer Engine and definitions, maybe you could try upgrading and crosscheck?
I'm attaching a screenshot of my versions.
To reproduce do the following:
type exiftool -h in a console windows with activated defender, it takes ca. 4 secs for me.
then deactivate defender or add the exception for the exiftool.exe.
now type exiftool -h again, it takes less then a second for me.
Hi Gunther,
I resist upgrading my Windows Defender version because that would necessitate dropping my defences. My Windows development system is used only for ExifTool development, and as such doesn't need internet connectivity so I keep it completely isolated from the internet, and I want to keep it that way.
FMI, what version of Windows Defender are you running?
- Phil
Of course that makes it hard to reproduce. :-)
You can find the versions in the screenshot that I've attached.
So, I've made a short screencast to illustrate what's happening:
https://dl.dropboxusercontent.com/u/2088648/web/exiftool-defender-demo.mp4
Ah, thanks. I missed that attachment. Right. You're running a newer version of everything. I wonder if it is possible to update Windows Defender manually via a USB stick. I'll look into this.
I saw your MP4, and I've got an idea. Could it be either:
1) The exiftool temporary files (in C:\Users\USER\AppData\Local\Temp) are being erased by Windows Defender after each invocation.
or
2) The temporary files from a previous launch of exiftool are somehow not readable by exiftool when it is run again (possibly due to the permissions)?
Either of these would explain the problem exactly because exiftool requires a few extra seconds the first time it is launched to expand the packaged files into the temporary folder.
If the problem is 1, you should see the ExifTool temporary files disappear after exiftool exits.
If the problem is 2, you should see a new set of temporary files created each time exiftool is run (and your free disk space should shrink each time exiftool is launched).
- Phil
Hi Phil, you are right, it seems to be the temporary folder that gets locked by the defender.
If I delete the exiftool temporary folder, I cannot launch exiftool at all anymore with defender activated (the same I've experienced this morning, when I opened the thread).
Once I've deactivated defender it works fine again. Then - once the temporary folder is available - I activate Defender again, and I get it working, but with the 4 seconds delay.
The temporary folder is not being removed or altered, once it has been successfully created (with deactivated Defender).
And this happens with 10.20 as well as with 10.24. That seems to mean: new users (without the temporary folder) won't be able to launch exiftool at all, if they have defender with the latest signatures installed. Not good.
Hope my findings will help you to find a solution.
BTW: as a someone with many years of IT background and windows/linux and mac user I'd really recommend that should hook your machine to the internet from time to time to install the latest updates from microsoft. I have the same with my mac: I only use it for development. But if I don't upgrade it frequently I miss all the glitches that apple introduces with every new update and cannot work around them - and then my users find them (and those are mostly much worse then on windows :-)). Just a recommendation.
You may be able to work around this by changing the temporary directory to something else that is writable. See the PAR Environment documentation (http://search.cpan.org/~rschupp/PAR-1.010/lib/PAR/Environment.pod) for information on how to change the temporary directory (ExifTool for Windows uses the PAR packager). I think it is the PAR_GLOBAL_TEMP variable that you should try setting.
- Phil
Even if that worked it wouldn't help the end user.
Quote from: gwegner on July 29, 2016, 04:53:56 AM
Even if that worked it wouldn't help the end user.
No, not directly, but it may be one step towards a permanent solution. So I suggest you still try it and let Phill know if this is a viable work-around.
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
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.
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.
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
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
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
I've never had to enter any exception there before.
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!
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
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 (https://exiftool.org/forum/index.php/topic,7418.0.html)
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.
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
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?
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
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.
As noted in the bug forum, I just installed exiftool, and found it to hang. Knowing this issue after reading the install notes, it occured to me Defender sometimes blocks web apps until you make a positive response it is okay to run. So I tried a simple MS Defender scan of the exe, and boom: it now works as expected. No exceptions required.
YMMV.