My Autohotkey ****** Keeps Getting Deleted By Bdts
Windows 10 Pro x64
Bitdefender Total Security 2016 20.0.26.1418
I have a simple Autohotkey ****** which I have compiled into an EXE. The ****** is very simple and harmless. Its purpose is simply to prevent Chrome from closing every time I accidentally hit Ctrl+Shift+W:
SetTitleMatchMode, Regex
#IfWinActive, ahk_class Chrome_WidgetWin_1
^+w::
;do nothing
return
^+q::
;do nothing
return
#IfWinActive
I do not expect it to be verboten for me to post this code here because it does ... nothing.
Anyway, every time I run the compiled version of this ******, BDTS deletes it with several log entries resulting:
Potentially malicious application detected
The application [path] was detected as potentially malicious. Active Threat Control blocked this process based on the following actions - the application's behavior can harm your computer
[Allow and monitor] button
Infected file detected
Bitdefender has detected an infected item in [path]. The file was disinfected for your protection (not true; it was deleted!)
[Recover][Delete] buttons
Potentially malicious application detected (yes, a second one)
Potentially malicious application detected
The application [path] was detected as potentially malicious. Active Threat Control blocked this process based on the following actions - the application's behavior can harm your computer
Comments
-
Just now, BDTS deleted the EXE again, even though it was excluded. It did not put it in quarantine.
And I've paused both on-access scanning and Active Threat Control, but still can't replace the file, because BDTS is blocking it from being written. I expect that a reboot will enable me to replace the file, but this cycle will only repeat. Even if I reboot, disable protection, replace the file, and exclude it, BDTS will just delete it again.
What is going on, and how do I stop this?
0 -
I think I have solved my issue. The problem--as best I can tell at this point--is that the EXE was running from within %AppData%. I think the Ransomware Protection feature disallows processes from running under that directory. (Albeit somewhat capriciously, as we've seen.)
My EXE was residing in "C:\Users\UserName\Documents\AutoHotkey". I've moved it to its own directory under %ProgramFiles%, and so far, no issues.
It would have been very helpful if BDTS had accurately reported what was going on. Rather than stating that Ransomware Protection is what was deleting/blocking the file, BDTS reported that the AV and Active Threat Control components were doing it. This is a rather egregious error for BDTS to make, but it does explain why the file was being terminated and deleted even when the AV/ATC components were completely disabled, and perhaps why the exclusion was not working.
I have not tried restoring the file to the %AppData% directory and disabling Ransomware Protection, and I have no plans to. I just want to use my system, without my AV commandeering it and demanding so much of my time and effort.
I do hope this issue is resolved so other customers don't deal with the same frustrations.
0 -
Ok I gotta ask....curiosity gets the best of me.....how can you "accidentally" hit a three key combination enough times to require writing a ****** to over ride that behavior ?
0 -
What's with the quotes around "accidentally?" What is that supposed to imply?
Let me pacify your curiosity by explaining that I use Ctrl+W to close tabs/windows, and Ctrl+Tab and Ctrl+Shift+Tab to move between tabs. It does not happen often, but I do occasionally hit Ctrl+Shift+Q or Ctrl+Shift+W by accident--I'm sorry, I mean by "accident"--which closes the window without warning. This can be a big hassle when you are working and/or have lots of tabs open that cannot simply be reloaded.
By the way, I did not create the ******. Someone else did, because other people have run into the same issue.
I hope that helps.
0 -
I simply meant that to me "accidentally" seemed an odd choice of words for something as deliberate as a three key combination. I'm a mouse guy so find using key modifiers and combinations counter intuitive. I guess if people frequently hit the wrong key then a ****** makes sense. No offense intended.
Can't you submit the resulting .exe to Bitdefender support for white listing ? After a rocky start I have found support to be quite helpful recently. I submitted a third party file to them and they white listed it pretty quickly. It's worth a try..........
0 -
I have not had a problem since moving the EXE out of %appdata%. The whole problem was that Ransomware Protection was killing and deleting it based only on the fact that it was running from %appdata%. So, there's no way to whitelist it anyway.
I submitted a totally unrelated FP to them about a week ago and they haven't done squat with it.
0 -
That's weird. I submitted four tickets since upgrading to TS 2016 about a month ago and not only did support answer them all if I didn't respond back quickly they checked with me to see if I had solved the issue. Pretty impressive lately after a rocky start when I couldn't even get anyone to send a confirmation e-mail so I could join the forums here.
0 -
Thanks Weary - I ran into the same problem after upgrading from 2015 to 2017 - configured bitdefnder (BT) to exclude anything with Auto Hot Key (AHK) both in virus scan exclusions and ransomware - but that doesn't work - Bitdefender deleted my compiled ****** AHK executable and even set my documents\ahk directory to read only so I could not compile my ****** in the same directory and everytime i manually changed back to read/write BF set it to read again - if this is not fixed a in 2017 after you reported in version 2016 - I expect it will not be fixed now even thought I sent a problem report... hope I am wrong.
Good to know if I put it in another directory issue might go away - via task scheduler I use a compiled AHK ****** to startup and login to a brokerage service and this is pain to deal with...thanks again. I learned the hard way that Bitdefender was restricted my automated futures trades a year plus ago - I hope with 2017 there are no issues...need to test that out once I sort out the AHK issue.0
