What is Microsoft Office Isolated Conversion Environment?

Hi,

My filter driver gets it’s reparse requests ignored when it is reparsing files in paths like this one
C:.…\AppData\Local\Packages\oice_16_974fa576_32c1d314_xxx.…

Searching around, I find references to some tech called ‘Microsoft Office Isolated Conversion Environment’ which appears to be some kind of sandboxing mechanism (although details are hard to find). My guess is that Win10 might be refusing to reparse access to here for security reasons.

Does anyone know if I am on the right lines here? If so is there any way I can escalate privilege or something to allow a reparse to happen?
Thanks

I have never heard of that. This doesn’t make it sound like anything that special though:

https://blogs.technet.microsoft.com/robert_hensing/2007/05/22/moice-microsoft-office-isolated-conversion-environment/

What do you mean that your reparse requests are ignored?

Thanks Scott,
Yes I saw this link, that and a couple of others are the basis for my assumptions (and my catchy thread title).
Not sure what is described here is quite the same as what I see in Office 2016 though. I figured they might have kept the tech but somehow built it directly into office.
If I procmon an excel file open from a network share, I see a copy of the excel file created in this location (possibly for the file preview before enabling edit).
If I ask my filter driver to encrypt all excel files, the excel thread creating this file will successfully trigger a reparse in my driver and create this file encrypted.
A second excel thread tries to open this file milliseconds later, this again triggers a reparse in my driver but the new CreateFile never appears (or perhaps gets consumed higher in the stack, but bizarrely it doesn’t appear in procmon either).

I only see this issue with win10 (win7 is fine with same Office version) and only when accessing network files.

Do you reparse to another location on the local drive or on the network share? When you reparse an open to an alternate path it should be the I/O Manager that retries the create with the new path, so it’s odd that you’re not seeing another open.

I’d put a breakpoint on the second reparse and then trace the response to the application. If you do a .reload when you hit the breakpoint you should see the call stack go back to user mode, at which point you can put a breakpoint after the Office call to CreateFile. It would be interesting to know what the application is getting back in this case.