PB compilation problems with MSE

Everything else that doesn't fall into one of the other PB categories.
Baldrick
Addict
Addict
Posts: 860
Joined: Fri Jul 02, 2004 6:49 pm
Location: Australia

PB compilation problems with MSE

Post by Baldrick »

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?
USCode
Addict
Addict
Posts: 923
Joined: Wed Mar 24, 2004 11:04 pm
Location: Seattle

Re: PB compilation problems with MSE

Post by USCode »

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 ...
Last edited by USCode on Wed May 02, 2012 1:34 am, edited 1 time in total.
User avatar
Danilo
Addict
Addict
Posts: 3036
Joined: Sat Apr 26, 2003 8:26 am
Location: Planet Earth

Re: PB compilation problems with MSE

Post by Danilo »

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.
User avatar
Tenaja
Addict
Addict
Posts: 1959
Joined: Tue Nov 09, 2010 10:15 pm

Re: PB compilation problems with MSE

Post by Tenaja »

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...
User avatar
Danilo
Addict
Addict
Posts: 3036
Joined: Sat Apr 26, 2003 8:26 am
Location: Planet Earth

Re: PB compilation problems with MSE

Post by Danilo »

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)?
Baldrick
Addict
Addict
Posts: 860
Joined: Fri Jul 02, 2004 6:49 pm
Location: Australia

Re: PB compilation problems with MSE

Post by Baldrick »

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.
User avatar
Tenaja
Addict
Addict
Posts: 1959
Joined: Tue Nov 09, 2010 10:15 pm

Re: PB compilation problems with MSE

Post by Tenaja »

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.
srod
PureBasic Expert
PureBasic Expert
Posts: 10589
Joined: Wed Oct 29, 2003 4:35 pm
Location: Beyond the pale...

Re: PB compilation problems with MSE

Post by srod »

Same here but I am not using MSE. I use Avast AV though and the problem disappears if I disable the real time scanning.
I may look like a mule, but I'm not a complete ass.
Torp
User
User
Posts: 82
Joined: Fri Apr 01, 2005 11:29 am

Re: PB compilation problems with MSE

Post by Torp »

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.
Fred
Administrator
Administrator
Posts: 18162
Joined: Fri May 17, 2002 4:39 pm
Location: France
Contact:

Re: PB compilation problems with MSE

Post by Fred »

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.
MachineCode
Addict
Addict
Posts: 1482
Joined: Tue Feb 22, 2011 1:16 pm

Re: PB compilation problems with MSE

Post by MachineCode »

Can't MSE ignore certain files, folders and processes? Or is it just a toy AV?
Microsoft Visual Basic only lasted 7 short years: 1991 to 1998.
PureBasic: Born in 1998 and still going strong to this very day!
SFSxOI
Addict
Addict
Posts: 2970
Joined: Sat Dec 31, 2005 5:24 pm
Location: Where ya would never look.....

Re: PB compilation problems with MSE

Post by SFSxOI »

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.
Last edited by SFSxOI on Thu May 03, 2012 8:36 pm, edited 13 times in total.
The advantage of a 64 bit operating system over a 32 bit operating system comes down to only being twice the headache.
User avatar
Danilo
Addict
Addict
Posts: 3036
Joined: Sat Apr 26, 2003 8:26 am
Location: Planet Earth

Re: PB compilation problems with MSE

Post by Danilo »

'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\".
SFSxOI
Addict
Addict
Posts: 2970
Joined: Sat Dec 31, 2005 5:24 pm
Location: Where ya would never look.....

Re: PB compilation problems with MSE

Post by SFSxOI »

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:

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Exclusions\Processes]
@=""
"C:\\Program Files\\PureBasic\\PureBasic.exe"=dword:00000000
"C:\\Program Files\\PureBasic\\Visual Designer.exe"=dword:00000000
"C:\\Program Files\\PureBasic\\Compilers\\pbcompiler.exe"=dword:00000000
"C:\\Program Files\\PureBasic\\Compilers\\PBDebugger.exe"=dword:00000000
"C:\\Program Files\\PureBasic\\Compilers\\FAsm.exe"=dword:00000000
"C:\\Program Files\\PureBasic\\Compilers\\porc.exe"=dword:00000000
"C:\\Program Files\\PureBasic\\Compilers\\polib.exe"=dword:00000000
"C:\\Program Files\\PureBasic\\Compilers\\polink.exe"=dword:00000000
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:

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Exclusions\Processes]
@=""
"C:\\Users\\XXXX\\AppData\\Local\\Temp\\PureBasic_Compilation0.exe"=dword:00000000
"C:\\Users\\XXXX\\AppData\\Local\\Temp\\PureBasic_Compilation1.exe"=dword:00000000
"C:\\Users\\XXXX\\AppData\\Local\\Temp\\PureBasic_Compilation2.exe"=dword:00000000
"C:\\Users\\XXXX\\AppData\\Local\\Temp\\PureBasic_Compilation3.exe"=dword:00000000
"C:\\Users\\XXXX\\AppData\\Local\\Temp\\PureBasic_Compilation4.exe"=dword:00000000
"C:\\Users\\XXXX\\AppData\\Local\\Temp\\PureBasic_Compilation5.exe"=dword:00000000
"C:\\Users\\XXXX\\AppData\\Local\\Temp\\PureBasic_Compilation6.exe"=dword:00000000
"C:\\Users\\XXXX\\AppData\\Local\\Temp\\PureBasic_Compilation7.exe"=dword:00000000
"C:\\Users\\XXXX\\AppData\\Local\\Temp\\PureBasic_Compilation8.exe"=dword:00000000
"C:\\Users\\XXXX\\AppData\\Local\\Temp\\PureBasic_Compilation9.exe"=dword:00000000
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.
Last edited by SFSxOI on Thu May 03, 2012 8:42 pm, edited 2 times in total.
The advantage of a 64 bit operating system over a 32 bit operating system comes down to only being twice the headache.
User avatar
Tenaja
Addict
Addict
Posts: 1959
Joined: Tue Nov 09, 2010 10:15 pm

Re: PB compilation problems with MSE

Post by Tenaja »

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! :mrgreen: )
Post Reply