Opening files from one computer to another crashes on file open

[hugh.wyeth9RYLJ]

This has been a persistent issue for probably the better part of a decade of Max versions, but it's getting (seemingly) worse. A Max file, sometimes containing some content from plugins, like ForestPack or MultiScatter, will open, save, merge fine on PC A. But when opened on PC B will crash. (The original file is archived from PC A and copied to PC B).

If I merge from the same file into a new empty scene, it will usually also crash. Sometimes, it won't - I can save the new file with the merged content fine- however, it is not linked up to proxies/texture files. When I then relink to those assets, usually using the RelinkBitmaps script and save, it'll save fine but will then crash on open. 

I do not get any error message other than this extraordinarily useful piece of information - 

For a lot of file open crashes, you can merge parts until something crashes and you now have identified a problem mesh or whatever it was. These scenes do not have that issue. There is some issue with how it links to texture/proxy assets (seemingly). I originally though that the continuous Google Drive backup may be causing issues, but having uninstalled it, it did not change this crashing issue at all. 

On the original PC, the file is still fine and has zero issues. This happens both with files from PC A to PC B and vice-versa. 

Any help would be greatly appreciated! I am running Max 2021 with Vray, fully updated, all drivers and windows 10 fully updated. All assets and plugins are up to date/purchased through reputable sellers. 

[hugh.wyeth9RYLJ]

Ok it's definitely something to do with proxies it seems. Even when relinked correctly, the archived proxies, unzipped onto PC B just don't seem to work nicely with max. No idea why. So the current solution is "Strip and replace all proxies in the scene" which is a huge amount of work every time! Any ideas on why proxies (vrayProxy) would cause it would be welcome! This is both Cosmos browser proxy assets and assets I've proxied myself. 

[Diffus3d]

Sounds like a question that is better for the folks at Chaosgroup to be honest.  If it's happening with vrayproxies it's probably something they know about.  I guess the question is if you use max proxies does it still happen?  (Just as a test?) 

I'll be totally honest with you, I have never had a problem moving max files between scenes and I use all the plugins you've listed.  I have had render farm machines that refuse to pick up jobs sometimes but usually a reboot fixes it.  

Shots in the dark:

• Maybe try to open the file from someplace other than your desktop or program files folders.  (/shrug)
• If you have had this problem for decades maybe there is something in your workflow or your hardware that's incorrect or configured differently between machines.  
• Does the Windows Event Viewer record the cause of the crashes?
• Maybe the textures are somehow hard linked into the proxy objects that use a path that doesn't exist on the 2nd machine?  (or maybe the archive function doesn't update maps on materials on proxies?)

Best Regards,

[darawork]

Hi, just an idea... but maybe the maximum file path lenght limit is different on each workstation?
The proxies might have a filepath longer than 260 characters. Just a guess why they work on one workstation and not the other. I've had this cause problems before, when archiving files.

You can check this by following the answer in this Microsoft link:
https://answers.microsoft.com/en-us/windows/forum/all/how-to-extend-file-path-characters-maximum-lim...

Regards,

[hugh.wyeth9RYLJ]

Thanks @darawork and @Diffus3d for your replies.

@Diffus3d you could be right about workflow! I can't figure out what it would be tho - i archive to the desktop and copy across. Perhaps me having "Convert file paths to UNC" might cause an issue? The file will sometimes open successfully from the desktop or some other folder, but I won't be able to save it. 

@darawork that could well be it! I will try this the next time this happens and reply back here if it does fix it!

[darawork]

Hopefully that might be it, but again, it's just a guess.

I use this Script for 3DSMax when archiving scenes now. It can grab all the assets, put them into a folder of your choice and rename the file paths to point to the new location. I find it a lot neater than the in-house 3DSMax routine, which can sometimes result in very long file paths... especially on messy projects. You should give it a test on a backup scene.

http://www.scriptspot.com/3ds-max/scripts/collect-asset

Regards,

[hugh.wyeth9RYLJ]

This looks really good! I did use to use SoulburnScripts CollectBitmaps, but obvs it doesn't work with other assets. This looks perfect, thanks!

[Diffus3d]

Please keep us posted because this issue is unique.  

Best Regards,

[hugh.wyeth9RYLJ]

RE @darawork  - doesn't look like this fixes it, although it would seem to make the most sense considering archiving keeps the full hierarchy which I then copy into another 6/7 level folder hierarchy!

RE your script - just running it crashes the scene in the same way - this is the script window at the point it crashes - 

 

It's definitely related to VrayProxies, but not sure how!

[Diffus3d]

Maybe they were created in a different version of Vray?  

[darawork]

Hi, well that must be annoying 😞

Just to make sure, has the script hung or crashed outright? With an asset heavy scene it may hang for a minute or two while it is gathering stuff in the background and the progress bar freezes. It does this on me with big heavy scenes, but it always comes back alive after a while. Does it crash the scene with a CustomerErrorReport window? Or is it just non-responsive? If it's the latter, give it a minute or two to come back to life.

As for the proxies, I'll have to think about that a bit more, but what Diffuse3D said above could be worth looking at.

Regards,

[hugh.wyeth9RYLJ]

I get the error message as in my initial post unfortunately. @Diffus3d both running identical versions! I'm still looking through my scene, but I do obviously need to do some work, so it'll be slow progress from me to figure out the actual issue. Really appreciate the comments!

[Diffus3d]

Might be time to email the good folks at Chaosgroup, they have good support and will likely solve it for you.

Best Regards,

[hugh.wyeth9RYLJ]

Yes will do, see what they say!

[hugh.wyeth9RYLJ · Accepted solution]

Ok, I believe I've actually solved it and it was nothing to do with vrayproxies. @darawork was sort of right in mentioning filepath length (taking the limit off in regedit didn't seem to help this particular issue)- the issue is the way max's archiving just creates the full relative filepaths for all assets when zipping. This is fine when zipping a scene from PC A to B the first time. But the moment I then zip that same scene from PC B, it essentially nests the entire filepath structure within the entire filepath structure - eg a vrayproxy object links to the vrmesh file in folder - P/assets/3dmodels/trees/treemodelsvol2/models/proxies - that path is zipped up in the initial archive from A to B. Then I work on it on PC B, then zip to move back to A - the new filepath is P/projects/projectA/assets/P/assets/3dmodels/trees/treemodelsvol2/models/proxies etc etc. The issue has been at no point do i receive a warning that this is exceeding filepath length and 7zip just unzips it fine. The proxies seemed to be an issue because cosmos proxies are located in a relatively long filepath location, so they'd come up as the cause more often than not. 

I realised this is the cause when copying the unzipped folder to a different location and windows throws up an error message saying filepath is too long, which made no sense as it means the original location was also exceeding filepath length. 

From now on I'll be using @darawork 's asset collecting script and manually zipping that up as it fixes this particular issue!

Hope that makes sense for everyone. 

[Diffus3d]

Thank you for posting the solution that worked for you @hugh.wyeth9RYLJ !

Best Regards,

[hugh.wyeth9RYLJ]

So I'm unfortunately having to re-open this thread in the hopes of finding another solution! Although the above seemed to fix that instance of this issue, I'm now having it again. I'm using @darawork 's script (really really nice script!) to reassign all paths to one folder and to also strip paths for missing assets. So in theory, there should be zero linked assets that are outside of the one folder where the file is saved and all assets copied to. The max file is also relinked all it's assets to this folder using the script. 

But I'm getting the same issue. If i download the folder onto PC B, if i leave it in the downloads folder it's fine, But if I move it it's not - it crashes as before. Honestly I'm well past having the time to dedicate to figuring out why, so I'm now working out of my downloads folder for this project before copying any files back to the original PC A. I feel like it's still an asset linking issue when a filpath exceeds the limit, but I can't see a single path in max asset tracker that's not in the one root folder after using the script. I suspect it may be an issue with PC B as opening the same file and saving it elsewhere seems to work fine on my laptop, but i have had the same issue moving max files from PC B to A.