I just wanted to mention something in regards to the various people discussing the usage of the full path name with the " ' ", i.e. apostrophe character, in the folder structure versus the usage of duplicating every listed excluded process / executable in the multiple 8.3 syntax variants, i.e. ~1, ~2, ~3, ~4, and so on. The reason that the 8.3 syntax may be necessary for some people to utilize is that the Microsoft SCCM SCEP management interfaces for controlling the SCEP Policies of their SCEP clients do not recognize the " ' " apostrophe character as a valid path character for any given exclusion. You can quite literally use the SCCM SCEP Policy modification interfaces within SCCM to browse to the folder containing the process executable that you want to exclude, choose it, and then be returned to the SCCM dialog to click the "Add" button and it will not let you add it because of the presence of the " ' " character. We have seen this cause issues before within other systems that for whatever reason have decided that the apostrophe is not a valid character to have in a folder structure. So short of getting Microsoft to alter SCCM's interfaces to accommodate the usage of the apostrophe character in this instance or getting Malwarebytes to no longer use the apostrophe in their product's folder structure on the end clients, we have been relegated to working around this issue in some way.
The usage of the 8.3 syntax affords you a way around this, but also unfortunately means that you have to add all of the potential variants of this 8.3 syntax as exclusions because one client workstation's ~1 folder may just as easily be another's ~3 folder, etc. depending on the order in which any given Malwarebytes' products have been installed.
Another way could be to simply put the executable's name without any path structure and that is supposed to match that exclusion to any file matching that name pattern no matter its location on the file system. Unfortunately this would open up for the potential of more unintended exclusions of that file name in paths you may not intend to have it excluded from being scanned within.
To compound things further there seems to be inconsistent implementation within Malwarebytes of their own folder naming syntax. As an example my current workstation has the following three folders within its "Program Files (x86)" folder -
Malwarebytes' Anti-Malware
Malwarebytes' Managed Client
Malwarebytes Management Console
I am not sure why there is the inconsistency but as you can see there is not an apostrophe on the last product's, i.e. Management Console, folder name.
This could be easily remedied while still maintaining whatever proper possessive English syntax that someone seems intent on enforcing / implying through the usage of this fairly useless usage of the apostrophe by simply having something like the following folder structure implemented by the various Malwarebytes products.
C:
->Program Files (x86)
->->Malwarebytes
->->->Anti-Malware
->->->Managed Client
->->->Management Console
I personally don't know why Malwarebytes has even bothered to try using the apostrophe in the first place in the folder structure. You don't see the following folder names for any of the following companies products to enforce or imply the possessive ownership or creation of their own products -
Microsoft's Office
Microsoft's SDKs
Microsoft's Security Client
Microsoft's Silverlight
Microsoft's SQL Server
Microsoft's Visual Studio 10.0
Mozilla's Firefox
Mozilla's Maintenance Service
Sorry but this syntax issue has always annoyed me from the first day I saw it and has caused small, easily addressable issues off and on throughout the years, but knowing that it could have so easily been avoided / or since addressed by Malwarebytes causes me frustration.
In its own small way this simple apostrophe syntax choice on Malwarebytes part has made the issue being addressed in this thread just that little bit more annoyingly tedious for their user's to troubleshoot / address, and easily and effectively discuss without defining a "Rosetta Stone" of sorts for why you may or may not have to use one type of exclusion syntax or another.
Sorry for the vent.
