CFile (MFC) does not work with Internet Explorer Enhanced Protected Mode (CFile::Open fails) - by Kater Mau

Status : 


Sign in
to vote
ID 800932 Comments
Status Active Workarounds
Type Bug Repros 0
Opened 9/16/2013 5:51:06 AM
Access Restriction Public


I have an ActiveX Control built with MFC.
I want to make it compatible with Internet Explorer Enhanced Protected Mode (EPM) (which is turned on by default in Windows 8.1).

After marking the control compatible with Internet Explorer Enhanced Protected Mode I can no longer use CFile for reading or writing files in the temp directory.
The temp directory which you can read/write in EPM is for example C:\Users\USERNAME\AppData\Local\Packages\windows_ie_ac_001\AC\Temp\
But you can not read the parent path.

The problem is:
If you call MFC "CFile::Open", this one calls "_AfxFullPath2" and this one calls "GetVolumeInformation".
The function "GetVolumeInformation" fails (because you are not allowed to read the volume?), at the end the whole "CFile::Open" fails.

If you use a normal "CreateFile" instead of "CFile" it works.

This is a bad situation because now CFile is no longer compatible with IE11 on Windows 8.1. CFile is used everywhere in our codebase.

I also had a look at the Visual Studio 2013 RC but the source code of CFile is not changed at this point.
Sign in to post a comment.
Posted by Microsoft on 11/18/2013 at 5:12 PM

Thanks for the report. We have investigated and determined that this is by design. MFC is not designed to run in an app container, which is essentially what the scenario is when running in IE EPM.

A possible workaround is to use CreateFile, as you mentioned in your original report.

Pat Brenner
Visual C++ Libraries Development
Posted by Kater Mau on 10/8/2013 at 9:10 AM
I have tried your suggestion to get the temp path. It works in Windows 7 Internet Explorer 10.
It does not work in Windows 8.1 (32 Bit) Internet Explorer 11
The function IEGetWriteableFolderPath fails with 0x80004001 which is E_NOTIMPL?

But nevertheless, to get the temp path is not the real problem.
With the original GetTempFileName I get a path like "C:\Users\USERNAME\AppData\Local\Packages\windows_ie_ac_001\AC\Temp\" in Windows 8.1 Internet Explorer 11 and Enhanced Protected Mode.
This is also a place where I can write.

But if I want to write there CFile::Open failes. As I already wrote:
"If you call MFC "CFile::Open", this one calls "_AfxFullPath2" and this one calls "GetVolumeInformation".
The function "GetVolumeInformation" fails (because you are not allowed to read the volume?), at the end the whole "CFile::Open" fails."

> The GetVolumeInformation tries to get the volume information of drive c: because this is the volume of the temp path.
I guess you are not allowed to get volume information in Enhanced Protected Mode?

I wonder why you can not reproduce it. Does the OCX really run in *Enhanced* Protected Mode (not Protected mode!). What is the temp path you get in the message box?
If it is something like "C:\Users\USERNAME\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low\tes9DAF.tmp" it does NOT run in Enhanced Protected mode!
It should be something like "C:\Users\USERNAME\AppData\Local\Packages\windows_ie_ac_001\AC\Temp\"

I have built the OCX with MS Visual Studio Professional 2012 Version 11.0.60610.01 Update 3
I have tested the OCX with Windows 8.1 Pro (32 Bit), Internet Explorer 11 Version 11.0.9600.16384, Visual Studio is not installed on this Windows 8.1 machine.
Posted by Microsoft on 10/7/2013 at 2:38 PM

Thanks for the report. We have investigated this issue and cannot reproduce the problem. The testing was performed in the following environments:

1.    Win 8.1, VS 2012 Update 3
2.    Win 8.1 VS 2013 RC
3.    Win 7/VS 2012 Update 3/IE 10

We believe that we tested this OCX exactly according to your guidelines.

You said that SDK CreateFile works fine, but CFile::Open doesn't work because GetVolumeInformation has failed. For us, it doesn't look like a problem in MFC source code.

After looking into the OCX source code, we discovered that your code obtains the temporary folder path using the following code:

TCHAR szTempPath[_MAX_PATH + 1];
TCHAR szTempFile[_MAX_PATH + 1];
if (GetTempPath(_MAX_PATH + 1,szTempPath)>0)
    if (GetTempFileName(szTempPath,_T("test"),0,szTempFile)>0)

However, the following CodeProject article ("A Developer's Survival Guide to IE Protected Mode") recommends calling IEGetWriteableFolderPath:

We tried to change your code in the following way:

LPWSTR pwszCacheDir = NULL;
TCHAR szTempFile[_MAX_PATH + 1];

HRESULT hr = IEGetWriteableFolderPath(FOLDERID_InternetCache, &pwszCacheDir);
if (SUCCEEDED(hr))
         GetTempFileName(ATL::CW2T(pwszCacheDir), _T("test"), 0, szTempFile);

We're not sure that this helps (as mentioned before, we weren't able to reproduce the problem, so I cannot check this possible solution). But we suggest that you try the workaround above and see if it resolves the issue for you.

Pat Brenner
Visual C++ Libraries Development
Posted by Kater Mau on 9/19/2013 at 6:40 AM
I have added a demo project.
You can also find it here:
Posted by Microsoft on 9/18/2013 at 8:04 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. In order to efficiently investigate and reproduce this issue, we are requesting additional information outlined below.

Could you please give us repro steps or demo project to demonstrate this issue so that we can conduct further research?

We look forward to hearing from you with this information.
Posted by Microsoft on 9/16/2013 at 6:51 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(