The Hex-Rays decompiler has been designed to decompile compiler-generated code, so while it can usually handle hand-written or unusual assembly, occasionally you may run into a failure, especially if the code has been modified to hinder decompilation. Here is one of such errors:
If you have a genuine function with a huge stack frame, you’ll probably have to give up and RE it the hard way – from the disassembly. However, in some situations it is possible to fix the code and get the function decompiled.
Bogus stack variables
Stack variable with a large offset may be created by mistake (e.g. pressing K on an immediate operand), or induced deliberately (e.g. junk code referring to large stack offsets which are not used in reality). The fastest way to check for them is to look at the stack variable definitions at the start of the function and look for unusually large offsets:
To fix, double-click the variable or press Ctrl–K to open the stack frame editor, then undefine (U) the wrong stackvar(s).
Then you need to edit the function properties (Alt–P) and reduce the local variables area to the actually used size (usually equival to the offset of the bottom-most actually used variable):
If you still get the error message after all that, the bogus variables may have been re-added during autoanalysis, so it may be necessary to patch out or otherwise exclude from analysis the instructions which refer to them.
Unusual stack pointer manipulation
This trick may cause IDA to decide that the stack pointer changes by a huge value, or not detect stack changes, causing it to grow the stack frame unnecessarily. This can be dealt with by adjusting the stack pointer delta manually, or patching the instructions involved.
See also:
Igor’s tip of the week #27: Fixing the stack pointer
Decompiler Manual: Failures and troubleshooting)
