I did exactly what you said and the problem is still exists. The interesting thing is if the DEFENSE+ disabled the problem still exists. If I rename guard32.dll or disable DEFENSE+ permanently then everything working.
What is the effect of disabling “guard32.dl” from autoruns?
Thanls for taking the test. It appears there is no way round.
I’m concerned that guard32.dll is an essential CFP component.
Please run some leaktest to evaluate your security when guard32.dll is disabled.
BTW for reference please post an URL to download the toolchain that includes GDB as it could be useful when developer are going to address this bug.
I can confirm the bug. I use MinGW with GCC 4.2.1: http://sourceforge.net/project/showfiles.php?group_id=2435
But it happens for some projects only. Actually, in my case, it happens since I checked the checkbox “This target provides the project’s main executable” in Code::Blocks (http://www.codeblocks.org/). It seems impossible to uncheck it and I can’t find where this setting is stored. Does anyone know something about this?
I could be way off here but through using the autoruns software as suggested earlier in this thread I have disabled the guard32.dll and everything seems to be working fine as regards using dbg… thing is that the guard32.dll appears (in autoruns.exe) to belong to AVG’s shield.
This doesn’t bother me as I only use avg for on demand scanning.
As I said, I could be waaaay off!
if you want to debug an C+±application (with gdb/MinGW) then gdb create Error 5 ( Can’t execute process ).
the problem exits even when the firewall is turn off. so i have to deinstall it :’(.
Source of the problem is perhaps “SIGSEV fault in guard.dll.”
Why is cmdagent/guard.dll still running even when I shutdown the firewall?
Why can’t i terminate this process?