Hello Enigma Protector Community,
I'm hoping to get some advice on an "Out of memory" issue I'm facing. I'm trying to protect my C# .NET Framework application, but the process fails consistently.
My Environment:
The Enigma Protector Version: [ 7.80]
OS: [Windows 11 64-bit]
System RAM: [64 GB]
Application Details: It's a C# .NET application. The executable file (myapplication.exe) is quite large, approximately 264 MB.
The Problem:
The protection process starts and runs for about 90 seconds. It appears to fail during the "Searching for markers" phase. The final error message is ERROR: Unexpected exception: Out of memory.
My Questions:
Is the large file size (264 MB) the most likely cause of this out-of-memory error?
Is there a known file size limit for protection, or is this dependent on system RAM?
Are there any specific protection settings (e.g., related to code obfuscation, resource protection, or VM) that are particularly memory-intensive and could be adjusted when working with such large files?
Any guidance or suggestions would be greatly appreciated. Thank you for your time!
Below is the key part of the log from the protection attempt:
[21:14:04] Protecting file: C:\path\to\myapplication.exe
[21:14:04] Protection started...
[21:14:04] Input file size = 276818432 bytes
[21:14:04] Searching for markers
[21:15:58] ERROR: Unexpected exception: Out of memory
Out of Memory Error When Protecting a Large (~264MB) .NET Executable
Re: Out of Memory Error When Protecting a Large (~264MB) .NET Executable
Hi gto70070,
What might could cause it?
Since you are posting this in the Enigma Protector section and not in the x64 section, i assume that you are having a 32Bit App and that you are using the 32Bit version of Enigma Protector. What you could do is to check the actual RAM usage of Enigma Protector while the protection process is running (the ~90 seconds you were talking about). If it comes close or reaches 2GB, it could actually be an out of Memory issue of the Enigma Application itself. It needs to parse the whole .exe file to search for protection markers. Enigma 32Bit currently does not use /LARGEADDRESSAWARE flag. This means it can only allocate 2GB of RAM in total, not up to 4GB. (@Enigma if you read this, you might consider changing this).
What can you try now?
264 MB is very large, usually there is no way an app is this big on a general term. I assume you are using the Bundling aka "Publish this to a single file"
feature of Visual Studio when you publish the app. I would recommend not doing that and using the Virtual Box feature of Enigma itself (https://enigmaprotector.com/en/help/man ... lbox-files) and then in the options of the Virtual Box feature, i would suggest, you change it to this:
With these Settings a temporary folder is being created where the .exe maps some files for the Virtual Box feature. Note: It does not store the files back to disk, these are just some temp files that do not contain any relevant data.
When doing the above, Enigma Protector will need to parse probably around 99% less of a filesize. In case you are not using the Bundling feature of VS publishing, can you please add some more information why the exe is so big? So we can understand better and eventually try another approach.
.Net Protection & Enigma Protector general advice
Enigma Protector does not fully support .Net protection the same way it supports native code. It wraps the .Net executable in a Native Code stub with the Enigma Features like Anti Debugging, VM detection etc. Different to a native executable, the .net executable can be dumped rather easy from memory without almost any knowledge.This is not Enigma Protectors fault, its because .Net is using Managed Code. I already bugged Vladimir, the author of Enigma Protector to add Managed Code protection for .Net, we will see what the future brings.
Therefore i would also recommend here to use at least the suggested way of further enhancing the protection of .Net executables from Enigma itself:
https://www.softwareprotection.info/202 ... -protector
Side note here: I would suggest to change ConfuserEx to a manged obfuscator that supports managed code virtualization, so cou can protect certain parts of your code similar to what the VM_START, VM_END markers of Enigma Protectors can do to native code. I wont suggest any product here as i still hope that Enigma Protector will support .Net managed Code Virtualization in the future as well.
-Aiden
What might could cause it?
Since you are posting this in the Enigma Protector section and not in the x64 section, i assume that you are having a 32Bit App and that you are using the 32Bit version of Enigma Protector. What you could do is to check the actual RAM usage of Enigma Protector while the protection process is running (the ~90 seconds you were talking about). If it comes close or reaches 2GB, it could actually be an out of Memory issue of the Enigma Application itself. It needs to parse the whole .exe file to search for protection markers. Enigma 32Bit currently does not use /LARGEADDRESSAWARE flag. This means it can only allocate 2GB of RAM in total, not up to 4GB. (@Enigma if you read this, you might consider changing this).
What can you try now?
264 MB is very large, usually there is no way an app is this big on a general term. I assume you are using the Bundling aka "Publish this to a single file"
feature of Visual Studio when you publish the app. I would recommend not doing that and using the Virtual Box feature of Enigma itself (https://enigmaprotector.com/en/help/man ... lbox-files) and then in the options of the Virtual Box feature, i would suggest, you change it to this:
With these Settings a temporary folder is being created where the .exe maps some files for the Virtual Box feature. Note: It does not store the files back to disk, these are just some temp files that do not contain any relevant data.
When doing the above, Enigma Protector will need to parse probably around 99% less of a filesize. In case you are not using the Bundling feature of VS publishing, can you please add some more information why the exe is so big? So we can understand better and eventually try another approach.
.Net Protection & Enigma Protector general advice
Enigma Protector does not fully support .Net protection the same way it supports native code. It wraps the .Net executable in a Native Code stub with the Enigma Features like Anti Debugging, VM detection etc. Different to a native executable, the .net executable can be dumped rather easy from memory without almost any knowledge.This is not Enigma Protectors fault, its because .Net is using Managed Code. I already bugged Vladimir, the author of Enigma Protector to add Managed Code protection for .Net, we will see what the future brings.
Therefore i would also recommend here to use at least the suggested way of further enhancing the protection of .Net executables from Enigma itself:
https://www.softwareprotection.info/202 ... -protector
Side note here: I would suggest to change ConfuserEx to a manged obfuscator that supports managed code virtualization, so cou can protect certain parts of your code similar to what the VM_START, VM_END markers of Enigma Protectors can do to native code. I wont suggest any product here as i still hope that Enigma Protector will support .Net managed Code Virtualization in the future as well.
-Aiden
Re: Out of Memory Error When Protecting a Large (~264MB) .NET Executable
Hi Aiden,
Thank you once again for your excellent and detailed response. Your solution worked perfectly!
I've moved away from the single-file publishing method, and my main executable is now a much more manageable 8MB. As you predicted, the "Out of Memory" error is completely gone.
Since you have such deep expertise in this area, I was hoping I could ask a follow-up question about a different, tricky issue I'm facing with the licensing system.
Some of my customers are reporting that their license key suddenly becomes invalid, forcing the registration screen to appear again. This is happening even though they haven't changed any computer hardware. It seems to be triggered by something as simple as a system reboot or a standard Windows update.
I suspect this is related to the Hardware ID locking settings. Are there specific hardware components you would recommend locking to that are more stable and less likely to be affected by minor system changes like a reboot or OS update? My goal is to create a robust lock that doesn't inconvenience legitimate users.
Any insights you could provide on this would be a huge help.
Thanks again for everything!
Thank you once again for your excellent and detailed response. Your solution worked perfectly!
I've moved away from the single-file publishing method, and my main executable is now a much more manageable 8MB. As you predicted, the "Out of Memory" error is completely gone.
Since you have such deep expertise in this area, I was hoping I could ask a follow-up question about a different, tricky issue I'm facing with the licensing system.
Some of my customers are reporting that their license key suddenly becomes invalid, forcing the registration screen to appear again. This is happening even though they haven't changed any computer hardware. It seems to be triggered by something as simple as a system reboot or a standard Windows update.
I suspect this is related to the Hardware ID locking settings. Are there specific hardware components you would recommend locking to that are more stable and less likely to be affected by minor system changes like a reboot or OS update? My goal is to create a robust lock that doesn't inconvenience legitimate users.
Any insights you could provide on this would be a huge help.
Thanks again for everything!
Re: Out of Memory Error When Protecting a Large (~264MB) .NET Executable
Hi, there are usually two cases that cause such behavior:gto70070 wrote: ↑Wed Sep 17, 2025 4:43 am Some of my customers are reporting that their license key suddenly becomes invalid, forcing the registration screen to appear again. This is happening even though they haven't changed any computer hardware. It seems to be triggered by something as simple as a system reboot or a standard Windows update.
1. Hardware ID changes, simple to investigate, just compare hardware id before this happens and after. If they are same, check #2
2. Check options at Registration Features - Registration Data Storing, make sure that the path, where the license key is stored is unique (eg, includes name of your software). Sometimes, our customers may keep this value as default, so multiple programs can use same path for storing of license keys, that overwrite each other. Resulting behavior is absolute same as you describe.