I've been debugging a very thorny issue.
Basically, I have an obfuscated assembly that crashes in various ways . The unobfuscated assembly has no problems, though there is no guarantee the obfuscator isn't to blame here. (that's what I might be aiming to fix)
Anyway, The obfuscated assembly also runs fine on .Net 4.0. It runs fine if I disable JIT optimizations in .Net 4.5.
What I've tried:
I tried debugging it against the IL. The access violation appears to come from an IL operation that simply loads something onto the stack. Again, completely managed code.
Just in case it's related to the String.Empty, I went through the IL and replaced all of the string::empty calls with ldstr "".. Now, instead of an AccessViolation, I get a FatalEngineException
Running it through a deobfuscator with all of it's options turned off makes it work though. Basically, all that the deobfuscator does with nothing turned on is just barely rearrange the IL and insert some NOPs.
Also, the executable does pass PEVerify, so that's not a concern.
The bad executable: Test.exe
The good executable: Test-cleaned.exe
The offending stacktrace:
Test.exe!PreEmptive.SoS.Client.Cache.CacheService.ServiceCache() Line 22032 + 0x137 bytes Unknown Test.exe!Test.TestConsole.Main(string[] args) Line 14 + 0x6 bytes Unknown
You can use ildasm to compare the two executables. Because it's reordered though, I found it a bit too difficult for my taste. I made a small tool to just dump the method's IL and have the methods in a sorted order for ease of comparison.
The bad IL dump: testcount.il
The good IL dump: testcountcleaned.il
Anyway, if anyone has any ideas on how to analyze this and figure out exactly what pieces of IL are causing this, I'd appreciate it.
