Gmt.exe disappears on Win10 and Win11

Has anyone heard instances of gmt.exe disappearing on windows installs? I have been using gmt for many years, and just this week I have run into gmt.exe disappearing from C:\programs\gmt6\bin\ on several of my computers.
I wonder if this is due to a new security update to Windows or possibly my institution’s antimalware software?
This is a shot in the dark, but I figured if anyone would know, it would be someone here.
None of the other .exe files seem to be gone, although there are many, so I didn’t count each one. gmt.exe is not in the recycle bin. Strange!

Any ideas?

Update: Yes, it appears that my institution’s antimalware software, Cisco Secure Endpoint, has deemed gmt.exe as malware. I will work with my institute’s IT team to get an exclusion made.

Maybe the executable isn’t signed? And then flagged, @Joaquim?

Yes, the gmt binaries are not signed (no idea on how to do that). And yes, AVs are a plague.

I think only device drivers can be signed? but I may be mistaken.
Cisco endpoint has flagged gmt.exe as
I am working with our IT staff to get an exception made. Hopefully we can get a solution quickly.

I believe installers can be signed too but I have some distant idea that it implies buying a license somewhere.

Here is what my IT folks said. Their fix was successful for me.
“We can exclude the gmt.exe process by its hash, and then have additional processes it creates be excluded, but we wouldn’t do that full path because \gmt\gmt.exe is also the executable path for the executable that the Gator adware network uses. I suspect that’s why it’s flagging it as malicious, it’s doing a filename check before checking the hash.”
So, I consider this thread solved. If anyone else has similar problems hopefully this will help.

Semi good I’d say as it will break on next GMT version.
But gmt.exe is one source of the problem, remember that on Windows and classic mode the individual modules still reply by their names. i.e. we can do psxy ... instead of gmt psxy ...

Compel IT dept. to install WSL, and you can easily compile and upgrade gmt when you feel for it!

… and pull your hairs with file permissions if you mix those two faces of the window.

The IT folks put in an exception for gmt.exe today and I am back up and running. I am a classic mode user, but the other exe files were not flagged so there are no issues now. When I update GMT someday and the hash changes, I will know what to request from IT to get it to not be flagged.

I have WSL, but this is why I still use cygwin for most of my scripting (bash/perl). Cygwin is far from perfect, but it allows one to mix the Linux and Windows environments and directories. I wish GMT would compile in cygwin. I have had no luck with getting version 6 to compile. I understand that GMT can only support so many different environments, so I just use the windows binaries with cygwin and it works fine.

Would be helpful if you could post all the output that occurs when you do try to build in Cygwin. GMT has supposed Cygwin for many years but given the fewer and fewer people who bother it is possible we have not kept up with the hassle. But there are tons of #ifdef CYGWIN statements in GMT so we are interested to see what fails (none of us have cygwin at the moment).

I use gmt on WSL every day without any file permission- or directory issues. Accessing windows drive(s), e.g C: is trivial.

If cygwin users are so few; why not remove the ifdef`s?

@Andreas: According to Microsoft, using WSL in the windows directory system (outside of the WSL environment) results in a performance penalty and is not recommended.

I use a cloud storage system and I don’t want to have to duplicate my files on WSL and windows. Have you noticed any performance or file permission issues when working outside of the WSL native directory structure?

@pwessell - I will do that someday and post in a new thread. My recollection was that there were many warnings, but it did compile. Then when I went to execute anything, I got errors related to gmt.conf and things related to the gmt set command. I also had to rename the main gmt dll file as it was looking for the wrong file. Someday, I will start a thread. Thanks for the interest!

@marshallst: Not really; I have not thought about any performance difference if I’m working inside or ‘outside’ the WSL native directory. I spend most time outside of the WSL native directory.
That said, comparing the performance of WSL compared to a machine running Linux on the metal, there is a big difference. I’m forced to use WSL1 - I think WSL2 is noticeable faster, so maybe the difference is smaller in those cases. I tried Cygwin some years ago (maybe 10) and that felt awfully slow. Maybe it’s better now.

I’m forced to use Windows on my work laptop. WSL works great in that case, and although it’s not lightning fast, it’s sure alot better than to have to deal with Windows’ command prompt and have access to ~everything a Linux distribution has to offer.

My previous and quite unpleasant experience was that if I touched WSL files (delete/copy) with the Windows file manager then I was screwed with file permissions. Since there is really nothing I can’t do on the Windows side alone (with occasional bash help), WSL remains for me as a test ground for the plethora of my source builds.