ExifTool >10.20 not running on Win10 x64

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

Previous topic - Next topic

gwegner

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

Phil Harvey

#1
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.

Are you sure you don't have a conflict with antivirus software on the affected system?

- 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 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...)

Phil Harvey

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
...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 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.

Phil Harvey

#5
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
...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,
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.

Phil Harvey

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
...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

Of course that makes it hard to reproduce. :-)
You can find the versions in the screenshot that I've attached.

gwegner

So, I've made a short screencast to illustrate what's happening:
https://dl.dropboxusercontent.com/u/2088648/web/exiftool-defender-demo.mp4

Phil Harvey

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
...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, 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.

Phil Harvey

You may be able to work around this by changing the temporary directory to something else that is writable.  See the PAR Environment documentation 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
...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

Even if that worked it wouldn't help the end user.

Hayo Baan

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.
Hayo Baan – Photography
Web: www.hayobaan.nl