The DLL is not digitally signed. I’m not sure it would help, really, if it were - during deployment, there is an executable, part of the runtime (and the one being caught before, but not anymore), that patches a bunch of DLLs (pretty sure this one as well), along with the main executable of the application, thus voiding any signature. I guess this behavior - all of a sudden - looks suspicious, and I can see why. But, again, I am only the end-user of this runtime, building on top of it, so I cannot offer a very in-depth look at thie whole process; what I did, was to let the publisher know that maybe they should push this with Avast a little bit more.

The history we had with the executable was that first it was called a threat, infection was unspecified; upon reporting it as a false positive, it is given the green light; a few days later, the very same file is blocked again (Virustotal shows that only avast considers it a threat, Win32:Malware-gen) - the same result we get by scanning the file’s folder on-demand. Reported again to Avast as a false positive…now it is tolerated again. This happened for the very same copy, from the same machine, tests running only after double-checking that we had the latest definitions.

As for the DLL, Virustotal shows the green checkmark coming in from Avast, but at runtime it is caught as Win32:Evo-gen[Susp].

When we encountered similar issues with a competitor, our vendor whitelisted this much quicker, due to the “whitelisting” program in place - that is why I was asking for directions.

Thank you, David, as well. Not sure about the “alert information file”; as for the location - well, we deploy either in ‘Program Files’, either in user’s ‘appdata’ location; not sure if that’s what you meant.