d3d11.dll file triggers ClamAV's virus signature as a Trojan
Yeah, it's complaining about both my local build and the CI build, think we can rule out compromised build environments here.
No idea whatsoever which part of our code is setting it off though and why it's limited to 32-bit.
Someone bisected this to https://github.com/doitsujin/dxbc-spirv/commit/848e5e325cd747e3ade3413138a2c64a1d15f4dc.
Very annoying, we need that code and I'd rather not start making random changes and risk breaking everything, but being flagged by ClamAV isn't a great look either. If this was some no-name engine I wouldn't care.
I've bisected the issue down to this change in the dxvk-spirv submodule
https://github.com/doitsujin/dxbc-spirv/commit/848e5e325cd747e3ade3413138a2c64a1d15f4dc
Honestly its more than likely an issue with them(ClamAV) I did report it as a false positive, hopefully they look into it very soon
Honestly its more than likely an issue with them(ClamAV) I did report it as a false positive, hopefully they look into it very soon
do you have a link to that report? I have never done this sort of thing and was looking at their "how to report false postives" doc. I just had the same issue.
This is not a ClamAV issue. File is contaminated.
I pulled the file from my Windows 11 install and scanned both the Microsoft file and the one I found in the Heroic Launcher on both the RPM and Flatpak.
This smells like malfeasance. Who put that .dll in the repo? Flag them as a bad actor.
@JKxZ That doesn't prove anything. The only thing you've proven is that it doesn't run into the same issue with Microsofts d3d11.dll and that would be odd considering that it's a core part of Windows 11.
Just as a heads-up, this so-called expert is popping up in several Linux communities thinking he made a revolutionary discovery, just because he ran ClamAV to find something that's been documented for years.
I pulled the file from my Windows 11 install and scanned both the Microsoft file and the one I found in the Heroic Launcher on both the RPM and Flatpak.
The file from your Windows 11 install is part of Direct3D and is completely different code, as the Windows 11 DLL is a full direct implementation of D3D11, while the DXVK DLL is a wrapper which translates D3D11 to Vulkan. That's why there's a difference with detections.
Understood, but if the changes to the source yield a binary matching an existing virus signature and not just a heuristic... doesn't that require a little more attention that just the standard "false positive" response?
This is where to report false positives
https://www.clamav.net/reports/fp
Honestly its more than likely an issue with them(ClamAV) I did report it as a false positive, hopefully they look into it very soon
do you have a link to that report? I have never done this sort of thing and was looking at their "how to report false postives" doc. I just had the same issue.
doesn't that require a little more attention that just the standard "false positive" response?
I mean, the exact change that triggered clamav is known and it is quite obviously harmless?
As for what's triggering Windows Defender all of the sudden, no idea, but I've taken all 3.x releases down for now. This is a huge problem.
And the point of removing DLLs is ..? when no matter if we build it ourselves or not we'll get virus warnings? Mind you it is only ClamAV that is giving this false-positives (who even uses that ???)
I am using DXVK on Windows and I can't compile the project without running a Linux VM - PITA
OK, so It is https://www.clamav.net/reports/fp
Thanks will submit another one
I am using DXVK on Windows and I can't compile the project without running a Linux VM - PITA
Well the new problem that just popped up is that Windows Defender started flagging our 32-bit DLLs out of nowhere. You wouldn't be able to use the DLLs anyway unless you turn it off.
Again, I don't know why it does this, it hasn't done it until now, but it's not a good look when almost all users who would actually use our DLLs would run into a virus warning. Proton doesn't use our release builds anyway. And the last thing I want is to get in trouble because we get accused of distributing malware.
I am using DXVK on Windows and I can't compile the project without running a Linux VM - PITA
Well the new problem that just popped up is that Windows Defender started flagging our 32-bit DLLs out of nowhere. You wouldn't be able to use the DLLs anyway unless you turn it off.
Again, I don't know why it does this, it hasn't done it until now, but it's not a good look when almost all users who would actually use our DLLs would run into a virus warning. Proton doesn't use our release builds anyway.
Hmm, that is interesting, I was not getting false-positives by the Windows Defender yet - I will try building 3.0.2 myself then
Please make the binaries available for download again. These are just false positives.
Like others, I am unable to compile the code.
Thank you in advance for your understanding.
Reported the problem to Microsoft via their portal (https://www.microsoft.com/en-us/wdsi/filesubmission), and got "not malware" back
additionally, the current virus total analysis only shows 1/70 - clamav again
@doitsujin Can you please mark v2.7.1 as the "latest" release so the latest url (https://github.com/doitsujin/dxvk/releases/latest) redirects to that version? This is needed to fix the winetricks dxvk verb installation.
Currently, any game install scripts or launchers that run winetricks dxvk as part of the install process are broken. Winetricks relies on the latest tag to determine which version to fetch, so switching it temporarily would allow these types of winetricks invocations to continue working while this gets sorted out.
Thank you!
I added the 3.0.x release binaries back now.
FWIW, we tried to figure out if there was any particular change that started triggering Windows Defender, but even the 2.7.1 32-bit binaries got flagged when building with an updated MinGW toolchain, so there's that. It also turns out that there's a lot of false positives in the wild for the specific trojan that it got flagged as.
Thing is, if some random no-name AVs think we're malware, there's no particular reason for us to care. ClamAV is still kinda eeeh, it's used in a bunch of places, but we sort-of understand why it's happening at least. Things like Google and Windows Defender are a different story though because most users who use our binary releases will be directly exposed to them, and again, I really can't have my github flagged for distributing malware, hence the sort-of panic reaction.
I added the 3.0.x release binaries back now.
FWIW, we tried to figure out if there was any particular change that started triggering Windows Defender, but even the 2.7.1 32-bit binaries got flagged when building with an updated MinGW toolchain, so there's that. It also turns out that there's a lot of false positives in the wild for the specific trojan that it got flagged as.
Thing is, if some random no-name AVs think we're malware, there's no particular reason for us to care. ClamAV is still kinda eeeh, it's used in a bunch of places, but we sort-of understand why it's happening at least. Things like Google and Windows Defender are a different story though because most users who use our binary releases will be directly exposed to them, and again, I really can't have my github flagged for distributing malware, hence the sort-of panic reaction.
Thank you very much.
May God bless you and your family.
look at the "false positives" from wined3d. i dont think a dev should leave it like that for years without end and take care so that his false positives are getting registered by the respective avs. the situation with false positive dlls is kind of out of hand and needs to end.
get in contact with the respective av providers and get your dlls registered.
Some people are overreacting, this is a false positive, for a relatively obscure AV that is mostly used for linux mail servers. This stuff actually just happens sometimes
I reported it as a false positive to clamAV awhile ago, almost feels like they forgot about my bug report lol
i reported the latest wined3d version to bitdefender and they flagged it as clear. took me like 3min. so i dont really get what the issue is. when i am a dev and i know i create proper things that fully work and are not harmful why not go ahead and proof it if you have nothing to hide. not only does this remove false detection but also proofs to your community.
but apparently it seems devs in general are too lazy (not saying you are), rather not care and rely on someone else to do this. i am working in beta testing so please dont come after me because i know how it goes. i think if you spend so many years in coding on a project you will have 3min to contact an av and get a false positive out of the way.
it should also be noted - if anyone hasnt noticed yet - you will get different results from virus total depending on whether you point to an url or link to a file vs. when you download the file to your pc and then reupload it to virus total. for some reason in the latter case usually you will have much more detections. and to pin this issue down virus total would have to be contacted.
personally whenever i will encounter an issue like this i am usually doing the job myself because its actual fun for me to do and i have bitdefender free running since ages and yes its the best av out there especially for gamers.
i reported the latest wined3d version to bitdefender and they flagged it as clear. took me like 3min. so i dont really get what the issue is. when i am a dev and i know i create proper things that fully work and are not harmful why not go ahead and proof it if you have nothing to hide. not only does this remove false detection but also proofs to your community.
but apparently it seems devs in general are too lazy (not saying you are), rather not care and rely on someone else to do this. i am working in beta testing so please dont come after me because i know how it goes. i think if you spend so many years in coding on a project you will have 3min to contact an av and get a false positive out of the way.
it should also be noted - if anyone hasnt noticed yet - you will get different results from virus total depending on whether you point to an url or link to a file vs. when you download the file to your pc and then reupload it to virus total. for some reason in the latter case usually you will have much more detections. and to pin this issue down virus total would have to be contacted.
personally whenever i will encounter an issue like this i am usually doing the job myself because its actual fun for me to do and i have bitdefender free running since ages and yes its the best av out there especially for gamers.
The issue was bisected down to a normal, harmless change in a dependency, the false positive was submitted to the AV via their official form, the AV has refused to take action so far - what exactly can an open source developer do in this situation exactly?
DLLs
d3d11.dllx2 2026-07
DXVK 3.0 (x32) d3d11.dll file triggers ClamAV's virus signature as a Trojan (Win.Trojan.Virut-53) , I did bug report to ClamAV as a potential false positive.
But due to this being the only file on my system that triggers it and it being a virus signature and not a heuristic/PUA, might be worth a quick double check of sorts.
Thanks for your hard work developing dxvk.