PureBasic Forums - English

I am having problems with M$ Security Essentials antimalware process slowing PB to a snail pace which in some cases is causing PB to stop responding or bug out with a failed to communicate with compiling exe. ( Win7 )
This has only just started happening.
Anybody else found this?
For the moment i am having to stop real time protection in mse when using PB which is not terribly good. What might be my next option to get this sorted?

You beat me to it, I noticed the exact same issue today.
I've also tried adding various processes and files the the MSE "Exclude" lists but no luck so far ...

I registered slow compilation times or "startup of my codes" today when coding and compiling much,
but didn't have timeouts. It was just slow.

I do now latest Windows Update, it has:
- MS Security Essentials Client Update Package (27.April 2012)

Maybe this will fix it, let's see.

Dang, and I have been sweating for an hour trying to figure out what code I added that caused the "Create executable" to jump up to 20 seconds or so...

On Win7 64bit it is PB 32bit that got so slow now. 64bit PB/IDE is still fast here.

Could it be it is more at the end of the compilation process (maybe assembling and linking)?

Danilo wrote:On Win7 64bit it is PB 32bit that got so slow now. 64bit PB/IDE is still fast here.

Could it be it is more at the end of the compilation process (maybe assembling and linking)?

Exactly the same here also. 64 is no problem. 32 is slow as a wet week.
In my case I am running a source which I have the compiled exe in a data centre which is now failing for some reason on an Xp machine & I cannot see any reason why a program which has been running live for several months should now fail to be starting. I am hoping it is not something to do with this MSE antimalware process.

I am also on w7-32.

Half of the delay is in "Creating Executable File..." and the other half is when the "Compilation in progress" dialog box closes.

Another oddity is that now some of my files will execute, but they will not create an asm file to view.

Same here but I am not using MSE. I use Avast AV though and the problem disappears if I disable the real time scanning.

Same thing here on my two computers (W7). The only remedy I found was to exclude the process "Polink.exe" in MSE, as well as the installation folder of PB.

That's a pity, unfortunately i don't know what to do, except encourage you to use another AV. PB doesn't do tricky stuff, it just output an assembly file and link it with several libs.

Can't MSE ignore certain files, folders and processes? Or is it just a toy AV?

MachineCode wrote:Can't MSE ignore certain files, folders and processes? Or is it just a toy AV?

Sure it can - on the MSE 'Settings' tab - depending on your need = 'Exclude Files And Locations' .... or ... 'Exclude File Types' .... or.... 'Exclude Processes'

MSE is no different than any other AV package, each has their "particulars" and quirks. We test a lot lof AV packages here for private corporation and goverments use (every 'free' and purchased av suite or package available on the market), and MSE always comes out in the top range so I assure you that it is not a 'Toy AV' and is very serious about what it does and does it very well, its also very literal in its actions. Aside from MSE, the only other AV package i'd recommend for a stand alone 'personal' computer system, knowing what i know now from the actual testing, is maybe Avast, personally I wouldn't waste time for anything else than those two and i've seen, used, and tested them all.

The issue is not with permissions or exclusions or anything else - the real issue is the real time protection. MSE, like other AV packages, has real time protection enabled by default. As srod noted above, he used Avast and still had to disable real time protection. Real time protection, in reality, is supposed to do what has been indicated in this thread (delaying compilation due to the real time protection scan), and it should be the same for other AV packages worth anything and if it isn't then there is a good chance that AV package is not doing its job properly but instead is leaning towards a more "convienance" factor and "feature" claims for marketing in lieu of true real time protection because real time protection is supposed to do exactly as its doing in this case. So changing to a different AV package from MSE or what ever your using is not a solution, because in reality if you have an AV package that has real time protection and its delaying the compilation then its doing what real time protection is supposed to do, and thats a fact period, and it does this because it doing what its supposed to do - scanning for threats. However, the public has gotten so used to having the softened convienance features of modern software when an AV product comes along with a feature like this that actually literally does what its supposed to do (the real time protection) they complain there is a problem with the AV package when in reality there isn't. Unfortunately there are people out there with this "hack the planet" and criminal mentality that have exploited so many things in a way that enables them to produce things which are inherently harmful to computer systems so the trend is towards a no nonsense approach to such and you end up with literal implementations of things like the real time protection in MSE and thats a good thing - finally. If you have real time protection enabled and not experiencing the compiling issue then your AV software is either not doing its job properly or needs to be removed and re-installed properly because real time protection should be doing as indicated in this thread.

Some people mix-n-match AV software and have a few different types installed on their systems - really bad idea and I don't care what the exprience is with doing so or what others claim because its not factual and you were foooled into thinking they were all working together to protect you. Its a fact that AV software will interact with other AV software, and the net effect is that something will be missed and will continue to exist for a long time before its ever detected. We test it all the time in the lab, something is always missed with multiple AV software installed on a system where as if only one AV software is installed the missed item is detected. So only have one AV software package installed.

So exclusions for files and project folders and the PureBasic install folder/files, etc..... (and being logged on to the computer with proper permissions preferably in the admin group might help some). But, keep real time protection enabled so the AV software can do its job.

Also note that MSE is no longer a beta product - In Mid April 2012 it became "RTM" status, so what i'd recommend is that you go to the MSE download page and download MSE - uninstall the MSE you have now and install again with the one from the MSE download page to ensure you have the "RTM" version - the update is also available via windows update if you were part of the MSE beta or the feedback program - but to be sure get the one from the MSE download page - its free, and always update to the latest definitions which can be gotten via Windows update. MSE also is not intended to be used with other AV packages installed (not just turned off - but instead simply not installed) so if your using MSE its best to uninstall any other AV software.

Just as a side note, with MSE, for x86 users (not sure on the 64 bit because i only do the x86 side of things at work so i haven't looked), look at the root of your C:\ drive (or... whatever your boot drive is) and see if there is a new folder there (if you have installed the MSE "RTM" via windows update) with a long alpha-numeric or GUID type number (might need to enable "view all files" to see it). If there is, remove MSE from the computer, reboot, then re-install MSE then reboot again. The folder may reappear but its not supposed to do so and this in most cases would indicate that you did not install MSE with administrative permissions and did not 'unblock' (in the properties on the general tab) the install .exe first before install, however, this folder being present doesn't harm anything and its more of a curiousity than anything and guess what, you will not have permissions to it but don't worry theres nothing inside actually other then left over install files for MSE. An uninstall of MSE, reboot, proper re-install of MSE, reboot, should get rid of this folder though. For dual OS users with dual boot OS's, can't say other than MSE was intended for, and expects to see, windows - duh, it is a MS product intended for windows and MSE is free after all.

'Excluded files and locations' did not fix it here, i had to add all of PureBasic's .EXE to the 'Excluded Processes':

Run with PB 32bit and 64bit and [Copy] the debug output to MSE Settings -> 'Excluded Processes' (CTRL+V to Paste it) and press [Add] there in MSE. Compilation time is very fast again.

Executable startup still takes half a second. To speed it up, exclude the following files too, if you want: Seems to be important to MSE that Paths and File names are case sensitive, so
it has to be "Compilers\", not "compilers\".

Yes, path name letter case is important. Its because some malware, trojans, and viruses, use letter case tricks to mimic and MS has applied the detection literally for MSE which is how it should be.

Thanks for posting the excludes, I was just going to come up with something myself to post but ya beat me to it.

Anyway, you can also add the exclusions directly to the registry as well, for MSE:
copy and paste to a text file file named "MSE_exclusions.reg" (without the quotes) or a name of your choosing e.g. "myMSERegFileName.reg" and have it available if you ever re-install, then just merge it into the registry.

You can do the temp the same way, for MSE:
But for the temp replace the XXXX with your own user path name.

Note: You will need to shut down MSE temporarily to merge the registry entries, because MSE won't let anything change its registry settings via an external merge to protect its self like a good AV product should do to keep its self from being manipulated by malware wanting to add exclusions for the malware to avoid detection.

Danilo wrote:'Excluded files and locations' did not fix it here, i had to add all of PureBasic's .EXE to the 'Excluded Processes':

Run with PB 32bit and 64bit and [Copy] the debug output to MSE Settings -> 'Excluded Processes' (CTRL+V to Paste it) and press [Add] there in MSE.

Code: Select all

pbDir$ = #PB_Compiler_Home

Debug pbDir$+"PureBasic.exe;"
Debug pbDir$+"Visual Designer.exe;"
Debug pbDir$+"Compilers\"+"pbcompiler.exe;"
Debug pbDir$+"Compilers\"+"PBDebugger.exe;"
Debug pbDir$+"Compilers\"+"PBDebuggerUnicode.exe;"
Debug pbDir$+"Compilers\"+"FAsm.exe;"
Debug pbDir$+"Compilers\"+"porc.exe;"
Debug pbDir$+"Compilers\"+"polib.exe;"
Debug pbDir$+"Compilers\"+"polink.exe;"

Compilation time is very fast again.

Executable startup still takes half a second. To speed it up, exclude the following files too, if you want:

Code: Select all

tmp$ = GetEnvironmentVariable("TEMP")

For i = 0 To 9
    Debug tmp$+"\PureBasic_Compilation"+Str(i)+".exe;"
Next

Seems to be important to MSE that Paths and File names are case sensitive, so
it has to be "Compilers\", not "compilers\".

I had already manually entered almost all of these, with no luck, so I tried pasting in the output. Unfortunately, it did not help either. I am running w7-32 with msse. I guess it is time to find a new av. Between my laptop being a couple years old, and my code being long, the av now adds over 20 seconds to the startup time, and that severely slows down debugging. (I can create a LOT of bugs in 20 seconds! )