Microsoft.Win32.OpenFileDialog cause application crash After update .NET9

[luchunminglu]

After update .NET9, dialog.ShowDialog() crash the application . It happens on some machine, not all machine.
The same code work on .net8.

Microsoft.Win32.OpenFileDialog dialog = new Microsoft.Win32.OpenFileDialog();

bool? dialogResult = dialog.ShowDialog();

[miloush]

There is no information that we can act upon, and it might be impossible to figure out what's going on without a repro. What is the call stack from the crash?

[miloush]

Not sure if you deleted the comment with video but that looks like the shell is crashing trying to load a thumbnail of one of the fails, doesn't look like a WPF issue. Does it crash when you try it from any other application?

[luchunminglu]

2025-01-18.19.19.54.mp4

[luchunminglu]

It crash when update to .net9, it works fine on .net8.

as the video show, It show the file dialog, but can't choose from it, the app crash.

when packaged, use the following comand and run the applicaiton, it still crash.

dotnet publish myapp -r win-x64 -c Release --self-contained /p:PublishSingleFile=true /p:DebugType=embedded

os : Microsoft Windows 10.0.19045,
.NET: 9.0.1
VS:17.12.4

[h3xds1nz]

I cannot replicate the behaviour (then again, I'm not lucky enough to have a chinese-locale VM available at the moment) running the same versions you are.

Does it replicate only in that folder or it doesn't matter when you change the InitialDirectory to somewhere else (e.g. empty folder)?

Could you share the full stacktrace from Event Viewer? I really wonder where the STATUS_STACK_BUFFER_OVERRUN comes from.

[miloush]

Could it be because packed/self-contained? But yeah, call stack would be helpful. You can also try to enable native debugging in VS.

[luchunminglu]

[luchunminglu]

it doesn't matter when change the InitialDirectory to somewhere

[lszczygielek]

Hi @luchunminglu , did you find a solution?

[luchunminglu]

Hi @luchunminglu , did you find a solution?

NO。 It occur on sone machine, not all machine. I return back to .net8 for that machine.

[lindexi]

@luchunminglu
Can I reopen this issues so we can track it?

[siagupta0202]

@luchunminglu Can you help us with the machine configuration and the crash dump for the issue?

[luchunminglu]

@luchunminglu Can you help us with the machine configuration and the crash dump for the issue?

WpfApp1.exe.4476.dmp.zip

max allow file size 25MB， so zipped it

[h3xds1nz]

@luchunminglu Could you try putting this into your project file and see whether this fixes the crash? As of .NET 9, shadow stack is enabled by default.

<CETCompat>false</CETCompat>

[luchunminglu]

@luchunminglu Could you try putting this into your project file and see whether this fixes the crash? As of .NET 9, shadow stack is enabled by default.

<CETCompat>false</CETCompat>

It works. Problem solved

[h3xds1nz]

It works. Problem solved

In that case, is that particular machine missing any Windows updates? AFAIK there were some fixes in the last month or two regarding to CET.

[luchunminglu]

ine missing any Windows updates? AFAIK there were some fixes in the last month or two regarding to CET.

It already updated.

[h3xds1nz]

I'd wait for .NET 9.0.2 and re-test it there (which should come 11th February).

The dump points to a crash with FAST_FAIL_SET_CONTEXT_DENIED which happens inside the CLR VEH handler, where the return address doesn't correspond to what's on the shadow stack currently. This was fixed in dotnet/runtime#109074 and backported to .NET 9.0.2.

[h3xds1nz]

@luchunminglu Could you please re-test on .NET 9.0.2 (released yesterday) runtime without disabling CET on the project?

[luchunminglu]

still crash

WpfApp1.exe.12688.dmp.zip

[h3xds1nz]

Right, I see, the particular dump shows that there's a few .NET Framework components loaded into the process as well, I guess via

SharpShell.dll (from C:\Users\cmlu\AppData\Roaming\hikvision\HikBox Client\resources\Windows\SharpShell.dll).

And the shadowstack failure happens in the netfx CLR (clr.dll) runtime, not net's CoreCLR (coreclr.dll) runtime, most likely due to the SharpShell extension.

This is for someone from the runtime/netfx team to say but since netfx doesn't support running in processes with CET mitigations (given that Microsoft started rolling out CET support in 2020 and netfx 4.8 was 2019), I'd guess the runtime won't be ready for it as well, so if you dynamically load the CLR runtime it into a process with CET-mitigations enabled, you will face these issues.

Might seem that all is needed to fix is the handling of exception record and pushing correct return values onto the stack, there might be hope for Microsoft to backport this.