My Autohotkey ****** Keeps Getting Deleted By Bdts

weary
edited April 2016 in Protection

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


I have the EXE file and the entire directory it is in excluded in BDTS, yet the file keeps getting detected/deleted. How can I prevent this?


Also, after restoring it, I can run it, but I cannot rename it. BDTS allows it to be executed (until it decides to delete it again) but blocks it from being renamed? (I hate how BDTS puts everything in lower case.)

Comments

  • weary
    edited April 2016

    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?

  • weary
    edited April 2016

    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.

  • 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 ?

  • 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.

  • MarcHoppe
    edited April 2016

    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..........

  • 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.

  • 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.

  • Ed K
    edited March 2017


    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.