Can't create MFC mdiframe Window in process isolation mode

[Outtay]

Describe the bug Context: I'm trying to execute integration tests of my company's MFC application in a docker image. Those integration tests contain a lot of UI logic and even if it's not shown MFC windows and classes are created and loaded.

This poses no problem when using hyper-v isolation mode. However, in process isolation mode mdiframe windows can't even be created.

To Reproduce Steps to reproduce the behavior:

• Go into Visual Studio (needs MFC components installed) and create a sample MFC project.
• Make it a "Multiple Documents" application
• Build it in Release Mode (64-bit) to get an executable
• Run the base server image (mcr.microsoft.com/windows/server:ltsc2022) and mount the directory of the solution
  • For example like this

    docker run -v "C:\dev:C:\dev" --name windowsProcess --isolation process -it mcr.microsoft.com/windows/server:ltsc2022

• Start powershell.exe
• Install the latest vcredist for the appropriate architecture inside docker
  • For example like this

    $url = "https://aka.ms/vs/17/release/vc_redist.x64.exe"
    $filePath = "$env:TEMP\vcredist_latest.exe"
    Invoke-WebRequest -Uri $url -OutFile $filePath
    Start-Process -FilePath $filePath -Args '/install /quiet /norestart' -Wait

• Go into the solution and execute the program with $myprocess = Start-Process .\x64\Release\TestMFCApplication.exe -PassThru
• Shortly afterwards you can enter $myprocess.ExitCode and get the Exit Code 255, showing that it did not exit successfully

Expected behavior If everything is repeated but with changing process to hyperv isolation, then $myprocess.ExitCode will return nothing as the program is still running.

Configuration:

• Edition: Windows 11
  • Base Image being used: mcr.microsoft.com/windows/server:ltsc2022
• Container engine: docker
• Container Engine version: 25.0.3

Additional context Attached I have the example MFC application solution with the only change being that it also outputs to the console if the frame can't be loaded. There is also the compiled .exe in there next to the source code so that it doesn't need to be built anymore (but I understand if someone wouldn't want to trust an .exe). TestMFCApplication.zip

I have investigated it using remote debugging until I couldn't anymore and where it always returns unsuccessfully is in wincore.cpp with the call

HWND hWnd = CreateWindowEx(cs.dwExStyle, cs.lpszClass,
        cs.lpszName, cs.style, cs.x, cs.y, cs.cx, cs.cy,
        cs.hwndParent, cs.hMenu, cs.hInstance, cs.lpCreateParams); 

This is the call stack for that there

    mfc140u.dll!CWnd::CreateEx(unsigned long dwExStyle, const wchar_t * lpszClassName, const wchar_t * lpszWindowName, unsigned long dwStyle, int x, int y, int nWidth, int nHeight, HWND__ * hWndParent, HMENU__ * nIDorHMenu, void * lpParam) Line 727    C++
    mfc140u.dll!CFrameWnd::Create(const wchar_t * lpszClassName, const wchar_t * lpszWindowName, unsigned long dwStyle, const tagRECT & rect, CWnd * pParentWnd, const wchar_t * lpszMenuName, unsigned long dwExStyle, CCreateContext * pContext) Line 622 C++
    mfc140u.dll!CFrameWnd::LoadFrame(unsigned int nIDResource, unsigned long dwDefaultStyle, CWnd * pParentWnd, CCreateContext * pContext) Line 755 C++
    mfc140u.dll!CMDIFrameWnd::LoadFrame(unsigned int nIDResource, unsigned long dwDefaultStyle, CWnd * pParentWnd, CCreateContext * pContext) Line 269  C++
    mfc140u.dll!CMDIFrameWndEx::LoadFrame(unsigned int nIDResource, unsigned long dwDefaultStyle, CWnd * pParentWnd, CCreateContext * pContext) Line 438    C++
    TestMFCApplication.exe!CMainFrame::LoadFrame(unsigned int nIDResource, unsigned long dwDefaultStyle, CWnd * pParentWnd, CCreateContext * pContext) Line 402 C++

[ntrappe-msft]

@deverouxmartin-msft has discussed a potential fix. We'll update this Issue when we can share the details.

[Outtay]

@ntrappe-msft those are great news. Thank you! This has actually turned into quite a blocker for our migration of the CI/CD system into the cloud. Can you maybe give me an idea when I might be able to test this? Nothing binding, just if it might be fixed this year? (Or if you can say more, if it'll take weeks or rather months?). Then I can look at other solutions for our setup if it takes too long. If not then not, just wanted to ask.