Author Topic: Comodo v3 Defense+ vs CodeBlocks & GDB Debugging  (Read 11889 times)

Offline red eagle

  • Newbie
  • *
  • Posts: 1
Comodo v3 Defense+ vs CodeBlocks & GDB Debugging
« on: February 29, 2008, 10:02:06 AM »
I have been using Comodo Firewall v2.? and CodeBlocks and the GCC compiler package.  All has been well over the last year no problems...

In the last few weeks I upgraded CPF v2 to CPF v3, nice.

Well in most case yes it seems very usable and secure.

But my problem now is that I have to permanently disable Defense+ to use the GCC GDB debugger.
If I use them together I get segmentation faults in GUARD32.dll

This is the output from within GDB:

> run
gdb: win32_init_thread_list
Program received signal SIGSEGV, Segmentation fault.
0x10008cf1 in ?? () from G:\WINDOWS\system32\guard32.dll
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> info registers
eax            0x1c   28
ecx            0x22ea84   2288260
edx            0x7c90eb94   2089872276
ebx            0x10000000   268435456
esp            0x22ead0   0x22ead0
ebp            0x22eb18   0x22eb18
esi            0x45e000   4579328
edi            0x0   0
eip            0x10008cf1   0x10008cf1
eflags         0x10246   [ PF ZF IF RF ]
cs             0x1b   27
ss             0x23   35
ds             0x23   35
es             0x23   35
fs             0x3b   59
gs             0x0   0
>>>>>>cb_gdb:
> bt 30
#0  0x10008cf1 in ?? () from G:\WINDOWS\system32\guard32.dll
#1  0x00000000 in ?? ()
>>>>>>cb_gdb:
> info frame
Stack level 0, frame at 0x22ead4:
 eip = 0x10008cf1; saved eip 0x0
 called by frame at 0x22ead8
 Arglist at 0x22eacc, args:
 Locals at 0x22eacc, Previous frame's sp is 0x22ead4
 Saved registers:
  eip at 0x22ead0
>>>>>>cb_gdb:
> info dll
From            To            Syms Read   Shared Object Library
0x7c901000  0x7c9afe88  Yes         G:\WINDOWS\system32\ntdll.dll
0x7c801000  0x7c8f4bec  Yes         G:\WINDOWS\system32\kernel32.dll
0x77c11000  0x77c67d74  Yes         G:\WINDOWS\system32\msvcrt.dll
0x68101000  0x6815c0b4  Yes         G:\WINDOWS\system32\SDL.dll
0x77dd1000  0x77e6ab38  Yes         G:\WINDOWS\system32\advapi32.dll
0x77e71000  0x77f01464  Yes         G:\WINDOWS\system32\rpcrt4.dll
0x77fe1000  0x77ff0884  Yes         G:\WINDOWS\system32\secur32.dll
0x77f11000  0x77f568a0  Yes         G:\WINDOWS\system32\gdi32.dll
0x7e411000  0x7e49fde8  Yes         G:\WINDOWS\system32\user32.dll
0x76b41000  0x76b6c8b4  Yes         G:\WINDOWS\system32\winmm.dll
0x76391000  0x763acc68  Yes         G:\WINDOWS\system32\imm32.dll
0x629c1000  0x629c828e  Yes         G:\WINDOWS\system32\lpk.dll
0x74d91000  0x74dfa6d0  Yes         G:\WINDOWS\system32\usp10.dll
0x10001000  0x10021686  Yes         G:\WINDOWS\system32\guard32.dll
0x774e1000  0x7761c018  Yes         G:\WINDOWS\system32\ole32.dll
0x4ffe1000  0x4ffe71da  Yes         G:\WINDOWS\system32\fltlib.dll

The only option from here is to quit the debugger.

I am not a Windows System programmer so most of this is over my head, but is guard32.dll in the correct memory address?, it seems to be in a lower address than the rest.

I have installed the very latest version of CodeBlocks released last night and the problem still reoccurs.

In Comodo disabling Defense+ temporarily makes no difference, only permanently disabling it allows GDB to work correctly.  I guess that guard32.dll is not loaded.


I hope that this information helps.



Richard.

Offline Chai

  • Newbie
  • *
  • Posts: 19
Re: Comodo v3 Defense+ vs CodeBlocks & GDB Debugging
« Reply #1 on: November 20, 2008, 10:34:54 PM »
I have just switched to Code::Blocks (8.02, latest version as of this writing) and am experiencing the same exact problem with CF (3.5.55180.432, latest version as of this writing).  I tried adding the Code::Blocks and mingw executables to the Defense+ database as "Trusted" files, to no avail.  Only disabling and rebooting allows the gdb debugger to function without a segmentation fault due to guard32.dll.

 

Free Endpoint Protection
Seo4Smf 2.0 © SmfMod.Com Smf Destek