How you could start to tackle this problem. I assume that you are able to start the program under Ida and and find in memory the int3 location. If this is not the case, you should describe in some more detail what exactly happens.
- Look in a hex editor if the int3 (=0xCC) is present in the static exe file. For this, you could collect in Ida (on a sheet of paper) the sequence of bytes in memory in the vicinity of the int 3. You should be able to find this byte sequence in the file, but take memory locations into account which might not be present in the static file (due to linking or dynamic memory).
- If the int3 is there in your exe file, replace it with your hex editor by a nop (0x90).
- Start Ida and have a look if the prog can stop at this location.
- Look in Ida if your 0x90 is still there. If no, then it has perhaps been removed by some anti-tamper means. In that case, stop in Ida immediately after start, and try - by stepping through your prog - to isolate the location where it is removed.
This is just an example how to start. There are of course other possible ways to tackle the problem. For instance, when Ida breaks at your int3, try to trace back to find from where the code sequence containing the int3 is called. This should be connected to the anti-debug code, because I assume your int3 is not called when running without debugger.
The most important with this stuff: Don't give up, even if it totally frustrates you (That's the sole purpose of anti-debug).