Weird IAM file size

[Neil_Cross]

I'm investigating an issue with an assembly file that is unusually large in file size.  I opened the IAM, deleted literally everything from it, removed all links, model states, reps, appearances, materials, purged everything, but the file size is still 650mb for what is essentially an empty IAM file.

One thing I noticed is that when I create an empty new model state, the file size balloons to 1.3GB! Then when I create a second empty state, it jumps to nearly 2GB.

New model state...

The only thing I can see in this IAM that shouldn't be here is some leftover parameter groups that I can't remove.

Anyone have any idea how to remove these or properly flush this assembly to get rid of the bloat? I've tried saving as a new file too but no joy there.

[andrewiv]

Is there maybe some simulation data stored in that file?  I would activate the dynamic simulation, stress analysis, and frame analysis environments to see if there is anything there that can be purged.

[Neil_Cross]

There was a couple of FEA studies in there which was the source of the parameter groups, so I've deleted all the studies which has cleared the parameter list, but the file size is still 650mb.  There isn't any Dyn Sim or Frame environments.  The IAM just looks like a blank standard.iam template now but it's 650mb!

[andrewiv]

I know you said you did a purge, but is there anything leftover in the styles editor that might be causing the bloat?

[CGBenner]

@Neil_Cross 

Hey Neil, long time!  ... what version of Inventor do you see this in? 

[Neil_Cross]

Hellooooo yea sure has been a long time!

Inventor 2026.1

Yep everything is purged as far as I can tell, I've uploaded the file here:

OneDrive Link 

Like I said earlier, if you open it, create a new model state and save the file, it jumps to 1.25GB!

[andrewiv]

Could it be express mode?  I have express mode enabled so I just tried a test.  I have an assembly that is 363.5 KB and after disabling express mode and saving it again the size dropped to 176.5 KB.  Worth a try.

[Neil_Cross]

I tried that too, opening to normal and express mode.  There aren't any parts in it so express shouldn't be enabled anyway, but either way that didnt change anything with it.

[andrewiv]

It doesn't matter how you open it.  It matters how it was last saved.  If express mode is enabled in the application options then it saves the extra data and increases file size.  I'm wondering if the file is still hanging on to previously saved graphical data that won't go away for some reason.  If you disable express mode in the application options and then open and save the file it should reduce the file size even if there is nothing in the file if only a little bit.

[Neil_Cross]

Well it sort of does matter how you open it, because you can specify express mode yes/no before opening it 🙂 I didn't specifically say that I saved it afterwards as I figured it was assumed that I would have done that, but either way yes even with express mode disabled at application options level it isn't reducing the file size on save.  It's still a 640mb empty IAM file.

[BDCollett]

Hi Neil,

I have just come across this exact issue. 1.9GB file that I have removed everything from. 
It also had FEA data. Never had express mode and that is also disabled from application options.
New Model States make it grow.

The model was originally from 2025, so this isn't a 2026 specific issue.

Hopefully someone from Autodesk can open your model and try and explain what's going on because this kind of file size bloat combined with people using Vault gateway turns into a painful experience!

[johnsonshiue]

Hi Neil,

I am downloading the file. I will take a look. In the meantime, you may use 7zip to open the iam file. It will should you the segments stored in the iam file. I suspect it is either corrupted Model States related or corrupted cached graphics (Express mode) related.

Many thanks!

[BDCollett]

Hi Johnson,

This is the result of opening my IAM with 7Zip.

Is there a way to fix the file?

[Neil_Cross]

Mine is also a 2025 file originally as that what my client uses, but I was using 2026 to troubleshoot the problem, but the original issue was in 2025 also

[BDCollett]

I was doing the same.

Also having issues with the same models where a model is renamed/moved in Vault, the Model State table seems to be holding onto the old name/location and asking to get from Vault, but it never resolves because it doesn't exist. I can't find any way to purge this or fix it.

[johnsonshiue]

Hi Ben and Neil,

For some reason, I cannot download the file. The URL seems to be blocked by our network security system. The reference files listed in 7zip are probably simulation result files or OLE files. I am not aware of a user workflow to surgically remove those files. Maybe a developer can do it on a debug build.

Many thanks!

[Neil_Cross]

Hi Johnson - try this one, Google Drive

Google Drive Link 

[MKE_Howard]

Im so invested and curious about why the file still 650mb. 

Also, hi Neil, I know this is not the place but... make more videos please. I waited 8 months for your face to show up on my YT feed. Thankyou❤️. 

[johnsonshiue]

Hi! The RefdFile objects are intriguing. These objects came from Insert Objects (Manage -> Insert Objects -> Link), the so-called OLE linking workflow. These objects are not typical OLE links (images or texts). They are binary files. Some seem to be Excel files. You may check them by doing the following. Change the file extension to .zip and decompress it by using 7zip. Go to RefdFile folder and open each in Notepad.

It is unusual to have so many OLE links. I guess the user may have a process of adding these OLE links to an iam file. But somehow the links are lost and the linked objects stay in the file. Unfortunately, I am not aware of a way to purge these RefdFile objects.

Many thanks!

[Neil_Cross]

Thanks Johnson - is there any scope to have the dev team write a bespoke utility to flush these files? These assemblies are part of a larger general assembly with a fairly large part count, and there was at least 5 or 6 other sub-assemblies that showed the same bloat as this one, and that adds a significant resource hit to the workstation when handling these in session.  The client/user shouldn't really have to recreate half a dozen assemblies again to workaround this, a lot of these had assembly level features as well so it would take quite some time to recreate them from scratch.  The fact that someone else experienced this, and that person noticed this thread, that can't be the biggest coincidence in the world, my guess is this is probably quite a common issue but a lot of people don't notice because how many people look at the file size of things on disk like this.  Dunno, would be nice if they could investigate anyway.

Thanks!

@MKE_Howard thanks I appreciate that 👍 I've sort of retired from that channel tho, I served my time and wasn't getting much back in the way of support from the audience to sustain it and make it a justifiable use of my time.  I'll never say never but currently have no plans to start doing regular videos there again.