GDB cannot work! guard32.dll keeps sending SIGSEGV

Hi, everyone. I am a really upset user of the comodo firewall…
Well, this resulted from that I spent almost whole night on trying to debug my program with gdb
But the notorious guard32.dll kept sending SIGSEGV and crashing my program, I am really mad at this.
I have tried a whole bunch of ways to fix this problem, like:

  1. disable the defense+ service permanently. actually I have never enabled it before…
  2. adding the gdb into exclusion list
  3. disable the CIS directly
    None of them worked!!! My gdb still keep crashing due to the SIGSEGV sent by the guard32…
    I got no idea about how on earth can such dll get so much power that you don’t even need a process linking to it to allow it sending signals that will crash other programs.
    Finally I tried to rename the guard32, and hopefully it worked. However, I don’t know if this is going to make any affects to the CIS… Is there any way that is elegant at some level that could deal with this problem?

Hi ReallyUpsetUser, welcome to the forums.

GDB = GNU Debugger?

If so, being it’s a debugger, I would suspect (hope) that it might be trying to access the memory areas of CIS and provoking CIS’s self-defense mechanism. But, that’s only a guess… it might also be events/hooks. If it’s the memory access/events/hooks is being the problem, then GDB only needs to be given authorisation to do this. See this post (same thing) and/or Protection Settings.

However, if it is something to do with guard32.dll (guard32.dll is the kernel guard) and GDB, this might be a problem. To protect processes guard32.dll hooks onto everything… I’m not sure how GDB would handle this. It’s not a problem with other debuggers that I’ve used, but I’ve not used GDB on Windows myself.

In saying all that, with Defense+ permanently disabled I’m not certain why this is happening anyway currently.

Don’t rename the guard32.dll, that might also provoke CIS. You’re better off manually disabling the drivers and services from starting rather than doing that (that works).

Hi Kail,
Many thanks to your reply. Yes, GDB = GNU debugger. I think the problem is caused by GDB tried setting break points but the guard32.dll doesn’t allow it to do so.
As for how to prevent guard32 from hooking onto my GDB and the debugged program, I really got no idea about how to achieve this. :stuck_out_tongue: Hope anyone could give me some clue in how to do this, please.
BTW, I just found that the great guard32.dll can still hook onto any process launched by me even after the comodo has been shut down… I guess that it is set to hook onto every single thread and every single sub-process bred by the initial process.