# X86 decompiler interr in 9.2
**URL:** https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489
**Category:** IDA General
**Created:** [September 14, 2025, 1:14pm UTC](https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489 "2025-09-14T13:14:21Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@Morgan](https://community.hex-rays.com/u/Morgan)
#### Post date: [September 14, 2025, 1:14pm UTC](https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489/1 "2025-09-14T13:14:21Z")
In IDA 9.2 load any 32 bit exe/dll (create new idb) and try to decompile a function, you will get interr 50735.
Then after interr save idb and open it again and it works without interr.
Was working fine in 9.1 without need to save and reopen idb…
---
### Author:  [@apetenchea](https://community.hex-rays.com/u/apetenchea)
#### Post date: [September 15, 2025, 6:05am UTC](https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489/2 "2025-09-15T06:05:50Z")
Hi @Morgan,
Could you please be a bit more specific:
- What flavor of IDA are you using (eg. Home, Pro, Free)?
- Have you tried it with random 32 Windows executables only? If you open a 32 bit ELF, does that work?
This will help us nail down the problem, as I was not able to reproduce it so far (using IDA Pro).
---
### Author:  [@igor](https://community.hex-rays.com/u/igor)
#### Post date: [September 15, 2025, 8:15am UTC](https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489/3 "2025-09-15T08:15:43Z")
This error can be found [in verify.cpp](https://github.com/HexRaysSA/ida-sdk/blob/f9bae92d3d602651e9cc5916d4eb9ccc78d229c9/src/verifier/verify.cpp#L44)
```auto
if ( a.type.get_size() != a.size )
INTERR(50735); // argument size and its type size mismatch
```
Do you have any third party plugins installed which could be modifying microcode? If so, try removing them temporarily to see if that fixes the issue.
---
### Author:  [@Morgan](https://community.hex-rays.com/u/Morgan)
#### Post date: [September 15, 2025, 11:08am UTC](https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489/4 "2025-09-15T11:08:22Z")
So it looks like microavx.py plugin is causing this issue.
I’m using slightly modified version than original one: [https://pastebin.com/7w3Jqm1u](https://pastebin.com/7w3Jqm1u)
---
### Author:  [@Morgan](https://community.hex-rays.com/u/Morgan)
#### Post date: [September 17, 2025, 11:03am UTC](https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489/5 "2025-09-17T11:03:43Z")
So any idea how to fix this interr?
---
### Author:  [@igor](https://community.hex-rays.com/u/igor)
#### Post date: [September 17, 2025, 12:51pm UTC](https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489/6 "2025-09-17T12:51:51Z")
Well, you need to figure out why the plugin produces inconsistent `mcallinfo_t` on your files.
---
### Author:  [@Morgan](https://community.hex-rays.com/u/Morgan)
#### Post date: [September 20, 2025, 3:12pm UTC](https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489/7 "2025-09-20T15:12:00Z")
But it worked fine in IDA 8.4, 9.0, 9.1 without touching plugin. Doesn’t look like issue with plugin to me…
---
### Author:  [@igor](https://community.hex-rays.com/u/igor)
#### Post date: [September 23, 2025, 1:05pm UTC](https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489/8 "2025-09-23T13:05:29Z")
Quite possibly it’s been already wrong before but some new optimization exposed it to the verifier. In any case, we can’t be responsible for workings of third party plugins, unless we get proof that it’s our check which is incorrect.
---
### Author:  [@int](https://community.hex-rays.com/u/int)
#### Post date: [December 5, 2025, 4:43pm UTC](https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489/9 "2025-12-05T16:43:18Z")
@Morgan jfyi the avx lifter in hrtng and especially the original python version you’re using (which the hrtng lifter is based on) have lots of soundness and correctness issues. Specifically, when it is attempting to lift AVX (ff.) instructions in 32 bit binaries, the resulting behavior is undefined since neither lifter variant actually checks they are operating in a 64 bit context, and many assumptions made in the respective lifter variants proceed to emit microcode as if the binary was 64 bit.
I implemented a new lifter with heavy amounts of testing and edge case coverage, which should significantly reduce the risk of undefined behavior: [GitHub - 19h/ida-lifter](https://github.com/19h/ida-lifter). Give it a try, maybe it helps.
* * *
_As a side-note, for any technical readers who care:_
AVX2 on IA-32 (protected mode, 32-bit):
**Register Constraints**
- Only **YMM0-YMM7** accessible (VEX.R, VEX.X, VEX.B extension bits ignored/must be 1 in complement form)
- No REX prefix → no R8-R15, no YMM8-YMM15
- 256-bit registers still full width, just fewer addressable
**VEX Encoding (32-bit specifics)**
- 2-byte VEX (`C5h`): `[C5] [R̄.vvvv.L.pp]` — R̄ inverted, but meaningless in 32-bit (always 1)
- 3-byte VEX (`C4h`): `[C4] [R̄.X̄.B̄.mmmmm] [W.vvvv.L.pp]` — X̄, B̄, R̄ all effectively 1 (ignored)
- W bit still functional for operand size control (e.g., `VPSRLVQ` vs `VPSRLVD`)
- mmmmm: 00001=0F, 00010=0F38, 00011=0F3A
**Functional Differences vs Long Mode**
- Identical instruction semantics
- Memory operands use 32-bit addressing (ModR/M + SIB with 32-bit displacements)
- No RIP-relative addressing → disp32 absolute or register-indirect only
- Stack operations still 32-bit ESP-relative
---
### Author:  [@int](https://community.hex-rays.com/u/int)
#### Post date: [December 5, 2025, 5:43pm UTC](https://community.hex-rays.com/t/x86-decompiler-interr-in-9-2/489/10 "2025-12-05T17:43:25Z")
Alright, this is embarassing: I tested my lifter against 32 bit binaries and did in fact stumble over errors, specifically due to YMM register handling. I fixed all issues and released a new version (1.1.0): [feat: Enable AVX lifting for 32-bit binaries and add headless dump tool · 19h/ida-lifter@e31171a · GitHub](https://github.com/19h/ida-lifter/commit/e31171a945ed5a39e959f68a3fa423154d7ec112).
Funnily enough, I just realised hrtng disables 32 bit binary lifting altogether, probably because when they ported the python plugin to C++ they recognized the soundness issues but didn’t care enough to properly figure out why it didn’t work.
Take care