Try building the Release version of one of the sample Bootstrap projects then try to run it under the Debugger. Note that the Debug version of the project does not prevent debuggers._________________Infralution Support

It works for me when I'm running the program in the debugger from the start of the application. But as soon as the program has passed the CheckProcessIntegrity method I am able to attach any debugger without any problems - tried that successfully with VS Debugger and OllyDbg. So I have to call randomly the CheckProcessIntegrity method to detect if a debugger has attached during runtime?

The anti-debug protection is primarily to prevent someone stepping through the decryption code that loads the assemblies into memory. It doesn't prevent someone attaching a debugger later._________________Infralution Support

This is always possible with any encryptor product (no matter what their publicity may say). If the code executes on your computer then it is always possible to somehow dump the memory before or after the code runs. It is a matter of how difficult this. .NET Encryptor can detect the more common mechanisms used to dump memory of a process - but not all. We don't use some of the more esoteric anti-dumping/debugging mechanisms because we want .NET Encryptor to be simple, reliable and affordable. Many anti-dumping/debugging techniques introduce bugs (sometimes platform dependant). That's why we provide the option to turn down or off the protection mechanism using the value you pass to CheckProcessIntegrity. .NET Encryptor is like putting locks on your house - it prevents people decompiling your code with easily available tools. No encryption tool can prevent the determined (and skilled) thief as long as the code is executing on your machine._________________Infralution Support