I've used Visual Studio 2010 to create Windows programs using C# for over 18 months now. For at least 12 of those months, I've been using the community edition of Dotfuscator to obfuscate all my programs. So far it's worked beautifully.
My latest project was released in its initial beta, compiled with Visual Studio 2010 for .NET Framework 4.0. That was obfuscated fine.
Since then I imported that to Visual Studio 2013, moved it to .NET Framework 4.5.1 and then kept working on my debugging version. When I was ready for another beta release to my users, I come to realize that the obfuscated version crashes in its release state. The unobsfucated version in release form does not crash. If I put the obfuscated EXE to replace the debugging version, Visual Studio gives me a warning but then runs the program just fine. No crash.
Even though I have an UnhandledException handler in Program.cs, the program just crashes and Windows gives me nothing more than a assembly line reference. Nothing I can use to narrow down the cause.
I have since moved the program back to Visual Studio 2010, .NET Framework 4.0, .NET Framework 4.0 Client Profile, tried all variations of settings in Dotfuscator. Tried the Pro Edition of Dotfuscator (14 day trial). Nothing. After obfuscation, crash with no usable information. Even if I excluse everything, so 0.0% is renamed, still get a crash.
I have some encryption information that needs to remain obfuscated as it has been for the past year or so. So I need to get obfuscation working. And I simply can't figure out what happened, or what I did, to make it stop working.
I would highly appreciate some guidance on what could have been. Thank you in advance.
EDIT: Here are the very basic and not very helpful error messages. I can follow a stack trace if one were provided. I also have my code covered in generous amounts of error catchers, plus a general AppDomain.CurrentDomain.UnhandledException handler. Still, this is all I get:
http://www.keepitfishy.com/files/crash1.jpg
http://www.keepitfishy.com/files/crash2.jpg
and this is part of the assembly code I get when I try to debug with Visual Studio, I marked the line that is supposed to be the culprit:
7362CEF1 E8 15 05 00 00 call 7362D40B
7362CEF6 59 pop ecx
7362CEF7 68 09 04 00 C0 push 0C0000409h
7362CEFC E8 16 05 00 00 call 7362D417
7362CF01 59 pop ecx
7362CF02 5D pop ebp
7362CF03 C3 ret
7362CF04 55 push ebp
7362CF05 8B EC mov ebp,esp
7362CF07 81 EC 24 03 00 00 sub esp,324h
7362CF0D 6A 17 push 17h
7362CF0F E8 37 DE C3 FF call 7326AD4B
7362CF14 85 C0 test eax,eax
7362CF16 74 05 je 7362CF1D
7362CF18 6A 02 push 2
7362CF1A 59 pop ecx
[error line]7362CF1B CD 29 int 29h[error line]
7362CF1D A3 58 61 75 73 mov dword ptr ds:[73756158h],eax
7362CF22 89 0D 54 61 75 73 mov dword ptr ds:[73756154h],ecx
7362CF28 89 15 50 61 75 73 mov dword ptr ds:[73756150h],edx
7362CF2E 89 1D 4C 61 75 73 mov dword ptr ds:[7375614Ch],ebx
7362CF34 89 35 48 61 75 73 mov dword ptr ds:[73756148h],esi
7362CF3A 89 3D 44 61 75 73 mov dword ptr ds:[73756144h],edi
7362CF40 8C 15 70 61 75 73 mov word ptr ds:[73756170h],ss
7362CF46 8C 0D 64 61 75 73 mov word ptr ds:[73756164h],cs
7362CF4C 8C 1D 40 61 75 73 mov word ptr ds:[73756140h],ds
7362CF52 8C 05 3C 61 75 73 mov word ptr ds:[7375613Ch],es
7362CF58 8C 25 38 61 75 73 mov word ptr ds:[73756138h],fs
7362CF5E 8C 2D 34 61 75 73 mov word ptr ds:[73756134h],gs
7362CF64 9C pushfd
7362CF65 8F 05 68 61 75 73 pop dword ptr ds:[73756168h]
7362CF6B 8B 45 00 mov eax,dword ptr [ebp]
7362CF6E A3 5C 61 75 73 mov dword ptr ds:[7375615Ch],eax
7362CF73 8B 45 04 mov eax,dword ptr [ebp+4]
7362CF76 A3 60 61 75 73 mov dword ptr ds:[73756160h],eax
7362CF7B 8D 45 08 lea eax,[ebp+8]
7362CF7E A3 6C 61 75 73 mov dword ptr ds:[7375616Ch],eax
7362CF83 8B 85 DC FC FF FF mov eax,dword ptr [ebp-324h]
If anyone can help me decipher that, I can perhaps track down the cause. Thanks.
Based off of the error dialog you posted, you are having stack issues in native code:
From MSDN:
0xC0000409 STATUS_STACK_BUFFER_OVERRUN
The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
Tracking down what is causing the overrun may be as simple as looking at the stack trace when the exception is thrown. Even though VS is not showing you code, it may still be able to identify the module and function on the top off the call stack.
If the issue is from corruption of the stack which has long since passed, you may need to approach the issue not from .Net, but as any other native application.
If you are not the author of any native components in your application, you may have a P/Invoke signature which is incorrect, be allocating an incorrectly sized buffer or struct which is passed to a P/Invoked function, or otherwise be calling native code incorrectly. Check your P/Invokes and make sure you have MDAs enabled.