[zparrish]

I recently started seeing MXI files that I created become locked by my workstation. I even copied them from a network drive to a local drive and they still get locked. I can create them, but most of them won't allow me to delete or rename them. I went as far as using Process Explorer to wipe out the handles that lock the files, but as soon as I try to delete or rename the MXI files, the handle comes right back and the file is locked.

Here's how I tested this. I completely uninstalled Maxwell, restarted "explorer.exe", and then was finally able to delete and rename the files. After that, I reinstalled Maxwell (being sure to include the shell extension) and the problem came right back. The only component that I can think of that directly integrates with Explorer is the thumbnail shell extension. To take the testing one step further, I uninstalled Maxwell again, restarted "explorer.exe" and there was no issue. I then reinstalled Maxwell but excluded the shell extension option and there's still no issue.

I do have other applications installed that use their own shell extensions for icon overlays (TortoiseSVN and Google Drive to be specific). As far as I know, those have nothing to do with thumbnail generation though. I suppose there could be an interference with them but I would think that it's unlikely.

I'm using MR 3.2.1.4 and all of the MXI files that are getting locked were made by this version. Thanks Next Limit!

[luis.hijarrubia]

Same here with 3.2.1.3

[T0M0]

I can confirm this 3.2.1.4 here... and MXI resume is also broken

Would be great if this will be fixed , it is official version in the end - check customer portal

[burnin]

yup...
i kill explorer process in WTM then run it again - no other way

Also wondered, is there a bug tracker for cooperation

[JDHill]

I'm using MR 3.2.1.4 and all of the MXI files that are getting locked were made by this version.

Thanks, I see this too, and will take a look to see what's changed.

[JDHill]

Seems to have been some problem in the mxi code; if you are seeing the same thing as I do, you should find that such MXIs crash Studio when you try to assign them, for example, to an HDR emitter. Building against the current code, both issues no longer occur, so it looks like something that's been fixed.