User forums > Using Code::Blocks
Problem with Debugger when upgrading MinGW
recobb:
--- Quote from: stahta01 on February 14, 2011, 03:33:44 pm ---Note: The below assumes the OP is a Vista or Windows 7 user.
@recobb: You do realize that Vista and Windows 7 have different permissions per folder.
If either one of the below fixes the problem.
1. Run Code::Blocks as Admin does the problem go away.
2. Turn off UAC and if problem goes away it is a Windows Security issue.
--- End quote ---
Nope, XP, Pro x64, version 2003, SP2
Jenna:
--- Quote from: recobb on February 14, 2011, 02:24:40 am ---I don't think so - I don't have the problem using the 6.8 version. I'm using Commodo, for whatever that is worth.
--- End quote ---
Did you try it with comodo disabled ?
MortenMacFly:
--- Quote from: jens on February 14, 2011, 05:17:48 pm ---
--- Quote from: recobb on February 14, 2011, 02:24:40 am ---I don't think so - I don't have the problem using the 6.8 version. I'm using Commodo, for whatever that is worth.
--- End quote ---
Did you try it with comodo disabled ?
--- End quote ---
Definitely worth a try. I am using Comodo myself. But for a developer this can be a pain in the a**. It took me literally month to set it up so that it does not interfere with my development process / style.
Remember that Comodo has different modules (AV, Firewall, Defense+ and the sandbox) - they ALL caused pain for me, so try to disable them step-by-step or set them into training mode to be alerted if something is blocked. Once found the components you can fine-tune them.
recobb:
--- Quote ---
--- Quote ---
Did you try it with comodo disabled ?
--- End quote ---
Definitely worth a try. I am using Comodo myself. But for a developer this can be a pain in the a**. It took me literally month to set it up so that it does not interfere with my development process / style.
Remember that Comodo has different modules (AV, Firewall, Defense+ and the sandbox) - they ALL caused pain for me, so try to disable them step-by-step or set them into training mode to be alerted if something is blocked. Once found the components you can fine-tune them.
--- End quote ---
That didn't seem to change anything. I killed Commodo from it's menu, then looked in Process Explorer to see if it left anything still running. I found the cmdagent process still running (part of Commodo, and it hogs a lot of CPU), so I killed that. I couldn't identify any other processes associated with Commodo. The problem is still there.
But it was worth a check. I've certainly had my problems with Commodo and gdb/gcc/CB in the past, and had to do some tweaks to be able to use things at all without a whole lot of error/warning messages popping up. I forget what I did, but I haven't been seeing those messages lately.
recobb:
More info - I said the problem went away with the project I had posted. Not so. But it appears to be more sensitive to file location than just being 'not in the project folder'.
When I reported that the problem was gone this morning, the file had been in the parent folder of the project folder, and that worked OK. I also put the file in a sub-folder of the project folder (the bin folder), and that was OK. But when I put the file in a folder parallel to the project folder, the problem appears. That is, say the project is in folder ..\wxprojects\debugerror. Then I have no problem if the data file is in ..\wxprojects\debugerror\bin or ..\wxprojects, but it does appear if it is in ..\wxprojects\otherfolder.
Please give that a try.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version