The WPF program caused a KERNELBASE.dll exception on Windows11

[VShawn]

Description

I developed an RDP desktop program using WPF + WindowsFormsHost + MSTSCLib.dll(.NET6 and .NET8), and everything worked fine on the Win10. However, in Win11, whenever I click on the information button in the RDP connection bar, it causes the WPF program to crash. (Tests have shown that any pop-up of RDP will cause a crash.)

Initially, I thought it was an issue with WindowsFormsHost, so I rewrote a complete Winform RDP window and opened it in the WPF project, but the problem persisted.

Then, I moved this Winform RDP window to a Winform project, and now clicking on the information button in the RDP connection bar does not cause the software to crash.

You can see the difference between Winform and WPF in this video:

1.mp4

related

related ticket: 1Remote/1Remote#559

Reproduction Steps

Open the solution I uploaded in Win11, change the account password to fit your server, run it, and click the information button in the connection bar. You will find that it only crashes in the WPF project. (The RDP sections of the two test projects have exactly the same code.)

Demo Upload.zip

Expected behavior

No crash with WPF.

Actual behavior

crash with WPF.

Log in the event viewer:

错误应用程序名称: WpfRDPHost6.exe，版本: 0.0.0.0，时间戳: 0x65cd0000
错误模块名称: KERNELBASE.dll，版本: 10.0.22621.4249，时间戳: 0x0cf64c6a
异常代码: 0xc000041d
错误偏移量: 0x000000000005fe4c
错误进程 ID: 0x0x7FAC
错误应用程序启动时间: 0x0x1DB68BFFE406869
错误应用程序路径: D:\Project\Upload\WpfRDPHost6\bin\Debug\net8.0-windows10.0.17763.0\WpfRDPHost6.exe
错误模块路径: C:\Windows\System32\KERNELBASE.dll
报告 ID: 0037c9ba-27af-481f-a4f0-af1324548f1d
错误程序包全名: 
错误程序包相对应用程序 ID: 

Report.wer.zip

[lindexi]

@VShawn Thank you. And I am using 1Remote now. This is a very useful tool.

And I can not repor this issues in my machine in 1Remote. Although I used the software for a long time.

I do not think the first exception raise in KERNELBASE.dll, and I guess the KERNELBASE.dll just the final crash module, because no one to handle the exception.

I can not get useful info from Report.wer.zip file. Could you take the dump file or attach the debugger when crash?

[lindexi]

Update:

I catch the native win32 exception and get the stacktrace here:

 	KernelBase.dll!RaiseException()	
>	mstscax.dll!__delayLoadHelper2()	
 	mstscax.dll!__tailMerge_comctl32_dll()	
 	mstscax.dll!TSExpandableTaskDialogW(struct HWND__ *,unsigned short const *,unsigned short const *,unsigned short const *,unsigned short const *,unsigned short const *,unsigned long,unsigned int,long (*)(struct HWND__ *,unsigned int,unsigned __int64,__int64,__int64),__int64,unsigned int,struct _TASKDIALOG_BUTTON *,int *)	
 	mstscax.dll!CTsConnectionInfoDlg::Show(void)	
 	mstscax.dll!CUI::UI_DisplayConnectionInfo(struct HWND__ *)	
 	mstscax.dll!CBBar::WndProc(struct HWND__ *,unsigned int,unsigned __int64,__int64)	
 	mstscax.dll!CTsWindow::CTsWindow_STATIC_WndProc(struct HWND__ *,unsigned int,unsigned __int64,__int64)	
 	user32.dll!UserCallWinProcCheckWow(struct _ACTIVATION_CONTEXT *,__int64 (*)(struct tagWND *,unsigned int,unsigned __int64,__int64),struct HWND__ *,enum _WM_VALUE,unsigned __int64,__int64,void *,int)	
 	user32.dll!DispatchClientMessage()	

It means the mstscax.dll throws the exception and no one to handle it.

But I do not know why the mstscax.dll throws the exception.

And the __delayLoadHelper2 is the lazy load helper in Microsoft Visual C++, and it is the standard method.

[h3xds1nz]

It would be good to know which particular import is it trying to delay load on Win11 though.

@lindexi Does it repro without any special care?

[miloush]

yes repros out of the box for me, but you need a computer to connect to via RDP

[h3xds1nz]

The problem tbh is setting up a debug env inside VM with win11 as my main is still 10. Having VM to connect to is the easy part.

Some thoughts tho, given the delayload being from comctl32 and this working on WF, which will usually load a different version, there might be a possible mismatch with missing import (export) or similar.

If I remember correctly, without a manifest, WF will take the newest system version while WPF will take that old 5.8 iirc or whatever.

So if you guys could test that theory by ensuring the same comctl32 version is loaded for both WPF/WF and see whether it crashes, it might move it forward.

[haefele]

I just gave it a try, and forcing my WPF app to load version 6 of comctl32 did fix this problem!

I also double-checked, and your memory is correct, WPF by default loads old 5.8 version.
Adding this to my app.manifest forced version 6+ and now this crash doesn't happen anymore.

Seems like #6810 could be related.

[lindexi]

@haefele Thank you. And I think it same as #6810

[VShawn]

I am confident that app.manifest to forced comctl32 to version 6 can solve the issue. It can serve as a workaround until the official version is updated.

here's the updated demo:

Upload.zip

[h3xds1nz]

Some days, I'm just on fire. What can I say?

Fun part is that mstscax has comctl32 v6 listed in its embedded manifest, however it is as <dependency optional="yes">, which I've never seen before tbh (mostly I guess I didn't pay attention since a few win libs have it after I looked now), and that attribute is not even documented, but I guess it then doesn't force on the activation context in the SxS and binds to whatever was loaded first, which in case the of WPF app ends up being v5.8 and then the delay import search blows.

I don't think there's anything for WPF to do; sure it would be nice if some shared WindowsDesktop primitives would offer an easy activation context wrapper for common controls but if a developer is working with COM/ActiveX, he should be well aware about winsxs and do it himself via native APIs (or just append a manifest and let the loader take care of it) and therefore no real need for it.

Eitherway, happy my thoughts have contributed to solving the issue, and that's an interesting project @VShawn!

[miloush]

Agree there isn't anything for WPF to do. Even when considering TaskDialog API, I think the consensus was leaning towards developers having to include the manifest themselves. It sounds like mstscax is what should be fixed here.