Hello, I'm a bit frustrated right now with this topic. I have finished a simple game made from scratch, but the following problems happened when preparing the release version:

1. When copying the .exe from the development directory to a new one where I was preparing the version, the .exe got detected as a Trojan by Windows Defender and deleted it. Had to manually allow it to avoid it getting deleted. I have Windows 10.

2. Tested it on my old laptop with Windows 8.1, the file was not detected as a virus. It showed a confirmation about unknown origin, but nothing else.

3. A friend of mine tested the game. Her antivirus instantly deleted the .exe after extracting it from the .zip, and just like in point 1, had to manually allow it to avoid it getting deleted.

What can I do to avoid this happening? I searched on the internet but to no avail. Some people even claimed that this happened with a simple Hello World. The only definitive solution seems to be to pay to sign your exe which is insane.

I also read suggestions to analyze it with VirusTotal which I did. Only 2 of 71 antivirus flagged it as malicious. Although Windows Defender was not in that 71.

I'm very frustrated because this is a simple game that I want to publish at Itch.io. With this false positives you are basically demanding a lot of extra trust on the game, which will put off any person looking to a play a casual game, but I can't find a way to solve this. My main questions are:

1. Is there any reliable way I can change my code to avoid this false positives? Couldn't find any guidelines about this. Also, can't think of any suspicious thing I do in the game. The only thing is that the game creates 2 new files to save user configuration and save data, but I don't see how to avoid that.

2. Is there any reliable way outside of modifying the code to avoid this?

3. Does this usually happen with any .exe file? I read cases happening with even a Hello World, but on the other hand in my previous work we made desktop applications with C++ and Qt and I never heard of problems with releases because of false positives.

Thank you for your time.

I asked a similar question here: https://handmade.network/forums/wip/t/7926-rss_and_atom_feed_reader

Unfortunately, as far as I know, the solution is to sign the executable and build a "reputation" as a trusty source. (Which I never did, so it might not be enough).

You can try to submit your exe for analysis to different anti virus provider (e.g. for windows defender: https://www.microsoft.com/en-us/wdsi/filesubmission ). But you'll need to do that for every release (if it works at all, once again I didn't try).

Well, after researching a bit and not founding anything, I modified some code pieces that may be "suspicious", while testing the .exe in the VirusTotal page where only 2 of 70 antivirus marked it as malicious, but couldn't find any modification that changes the result.

And then I started modifying the compiler flags. And won't you believe it, I was compiling with /fp:fast. The moment I changed it back to /fp:precise, no antivirus detected it as malicious. Tested multiple times back and forth to make sure.

Couldn't test it yet in other computers, but the result from VirusTotal seems promising.

Anyone knows why /fp:fast may make it generate suspicious code? I find it astonishing.

The detection is not about this specific compiler argument.
The anti-virus just looks at your binary in general. And due to various heuristics it uses determines is it suspicious or not. Once you start generating code very differently - it may decide it is not suspicious anymore. Or opposite - it is suspicious now. Having precise or "fast" float math is irrelevant. It just changes codegen significantly so that heuristics produce different result, in your case favorable to you.

Btw be aware that "/fp:fast" argument is not about having "fast" math or not. With this argument most of the time compiler will actually produce broken math instead. "fastness" comes mostly from compiler be able to vectorize loops, which you can do it yourself when needed anyway. In general I do not recommend using /fp:fast. Floating point operations are same speed regardless of this argument.