Emulator

The bisect seems invalid. I get the alert with Windows Defender's malware definition that was created 3.5 hours ago, but not one that was created 19 hours ago.

I will try to see if we can ask Microsoft to check whether this is a false positive.

I don't think I'm wrong: Windows 10 allows me to download 5.0-10916 (no thret detected by Windows Defender), but not 5.0-10918 (Trojan detected in the updater.exe)

Yes, you're actually right. I suppose there are two conditions for this happening, then: 5.0-10918 or later, and the newest definitions.

unfortunately the problem is still there: Dolphin 5.0-10943 - Defender version 1.303.701.0

Today same problem: Dolphin 5.0-10956 - Defender version 1.303.1004.0

I posted this on the forums and was instructed to report here too:

Windows Defender now flags the updater binary of every new Windows build of Dolphin as malware (I haven't tried PR builds but they're probably affected too). The detection name is always Trojan:Win32/Azden.A!cl and, as indicated by the !cl at the end of the detection name, it's always caused by their cloud definitions (which AFAIK are based on machine learning), so the version of the local definitions doesn't matter at all.

I noticed this happened with all builds from 5.0-10960 to the current (at time of this post) 5.0-10979. I submitted the updater of every affected build for analysis but all Microsoft seems to do is whitelist the updater of that specific build some hours after receiving the submission instead of fixing whatever is causing the false detection, so it's just a matter of a new Dolphin build being released for the whole loop repeating itself again.

I don't know if there's another way or channel to contact them about this situation other than the file submission portal, but manually uploading the updater of every new build is a tedious process and at this pace it's just a matter of time before complaining users start appearing on our forums and other social media. Perhaps I was lucky to be online at the time those builds were released and the manual analysis was finished before others had time to download the affected builds and get Windows Defender yelling at them, but that won't always be the case.

To be honest, I'm officially giving up after manually filling up 10 file analysis submissions just in the past week and simply configured Windows Defender to always ignore files identified with Trojan:Win32/Azden.A!cl, but I think it's important bringing attention to this issue to our staff and be ready when the complains start appearing again...

It would be interresting to know what part of the updater is detected as such; to at least give us a chance on actually changing the offending code. Even more so when it is part of the libraries we use; since we're not the only ones that do.

Assuming that Microsoft whitelist the updater binary of that particular false positive report after receiving the file for analysis and considering our updater code hasn't changed for a long while, couldn't we do something to make the updater binary generated by our buildbot always have exactly the same hash? As of now, every build of Dolphin has a unique hash for the updater binary, even through the source code used to generate that updater binary is the same.

If we could get the binary to get a different hash only when its source code really changed, we could theoretically report that binary for Microsoft and be done with the false alarms for as long as the updater doesn't receive any source code change...

I recently started experiencing this, too. Glad I am not the only one! It seems like all I had to do was go to the Defender settings and add the updater.exe to the exceptions, although this just a temporary workaround, I'm hoping Windows fixes this soon.

On my end I think this problem has been solved, I mean now it's been some weeks that I haven't experienced this problem anymore...so what do you think?