Hanging unless run under debugger

[matelich]

When I try to use VistaFolderBrowserDialog in my WPF .NET 4.6.1 application, it hangs the application. If I run it under the debugger (in Debug or Release mode) it works great.

I've tried to repro this in the sample application by changing various calls and switching to the Nuget package, still works fine.

I've tried to simplify how I'm calling the VistaFolderBrowserDialog and copy/pasted the sample code to my application, still hangs.

Any thoughts as to why or how to track down the issue?

[augustoproiete]

Hey @matelich I'm not able to reproduce the hanging behavior you described.

Attached is a sample project of a WPF app using .NET 4.6.1 that opens the VistaFolderBrowserDialog using Ookii.Dialogs.Wpf v1.1.0 (latest as of this writing) and I was able to run a:

• Debug build without the debugger attached
• Debug build with the debugger attached
• Release build without the debugger attached
• Release build with the debugger attached

No hanging or exception occurred.

If you can provide me with a way of reproducing the hanging behavior, I'd be happy to investigate further.

The relevant code in the sample attached:

var dialog = new VistaFolderBrowserDialog
{
    Description = "Please select a folder.",
    UseDescriptionForTitle = true,
};

if (!VistaFolderBrowserDialog.IsVistaFolderDialogSupported)
{
    MessageBox.Show(this,
        "You are using an old Windows version. The regular folder browser dialog will open.",
        "Sample folder browser dialog");
}

if (dialog.ShowDialog(this).GetValueOrDefault(false))
{
    MessageBox.Show(this, "The selected folder was: " + dialog.SelectedPath,
        "Sample folder browser dialog");
}

---

• Repro_Hanging_Issue_11.zip

[matelich]

Thanks for getting back to me quickly, @augustoproiete. I did try various repro steps to explore things. Going to try to add more usage into my other WPF applications to see if there's some common factor that might identify why it doesn't work.

I threw some logging in and reproduced in my application, the hang is at int result = dialog.Show(owner); in private bool RunDialog(IntPtr owner)

[itsho]

seems related:
I'm experiencing slowness when the selected path is a long network path.

If I enable Native code debugging, I see that the most time is spent somewhere in this call stack:

win32u.dll!NtUserMsgWaitForMultipleObjectsEx�()	Unknown
user32.dll!RealMsgWaitForMultipleObjectsEx()	Unknown
shell32.dll!SHProcessMessagesUntilEventsEx()	Unknown
shell32.dll!CChangeRouterProxy::RegisterThread()	Unknown
shell32.dll!SHChangeNotifyRegisterThread�()	Unknown
comdlg32.dll!CFileOpenSave::Show()	Unknown
[Managed to Native Transition]	
Ookii.Dialogs.Wpf.dll!Ookii.Dialogs.Wpf.VistaFolderBrowserDialog.RunDialog(System.IntPtr owner) Line 171	C#
Ookii.Dialogs.Wpf.dll!Ookii.Dialogs.Wpf.VistaFolderBrowserDialog.ShowDialog(System.Windows.Window owner) Line 157	C#
Ookii.Dialogs.Wpf.Sample.exe!Ookii.Dialogs.Wpf.Sample.MainWindow.ShowFolderBrowserDialog() Line 166	C#
Ookii.Dialogs.Wpf.Sample.exe!Ookii.Dialogs.Wpf.Sample.MainWindow._showDialogButton_Click(object sender, System.Windows.RoutedEventArgs e) Line 56	C#

or:

win32u.dll!00007ff9d17c9164()	Unknown
user32.dll!00007ff9d2ca059d()	Unknown
shell32.dll!SHProcessMessagesUntilEventsEx()	Unknown
shell32.dll!CChangeRouterProxy::RegisterThread()	Unknown
shell32.dll!SHChangeNotifyRegisterThread()	Unknown
comdlg32.dll!CFileOpenSave::Show()	Unknown
[Managed to Native Transition]	
Ookii.Dialogs.Wpf.dll!Ookii.Dialogs.Wpf.VistaFolderBrowserDialog.RunDialog(System.IntPtr owner) Line 171	C#
Ookii.Dialogs.Wpf.dll!Ookii.Dialogs.Wpf.VistaFolderBrowserDialog.ShowDialog(System.Windows.Window owner) Line 157	C#
Ookii.Dialogs.Wpf.Sample.exe!Ookii.Dialogs.Wpf.Sample.MainWindow.ShowFolderBrowserDialog() Line 166	C#
Ookii.Dialogs.Wpf.Sample.exe!Ookii.Dialogs.Wpf.Sample.MainWindow._showDialogButton_Click(object sender, System.Windows.RoutedEventArgs e) Line 56	C#

or:

ntdll.dll!RtlpHashStringToAtom()	Unknown
ntdll.dll!RtlpFreeAllAtom�()	Unknown
ntdll.dll!RtlpDereferenceAtom()	Unknown
ntdll.dll!RtlDeleteAtomFromAtomTable()	Unknown
kernel32.dll!InternalDeleteAtom�()	Unknown
dui70.dll!DirectUI::Value::_ZeroRelease()	Unknown
dui70.dll!DirectUI::DUIXmlParser::_DestroyTables(void)	Unknown
dui70.dll!DirectUI::DUIXmlParser::~DUIXmlParser()	Unknown
dui70.dll!DirectUI::DUIXmlParser::`vector deleting destructor'()	Unknown
dui70.dll!DirectUI::AccHDelete<class DirectUI::RefcountBase>(class DirectUI::RefcountBase *)	Unknown
shell32.dll!_DUI_ShellStyleSheet_UninitThreadIfPossible(void)	Unknown
shell32.dll!DUI_ShellStyleSheet_UninitThread(void)	Unknown
shell32.dll!CDUIViewFrame::DestroyFrameWindow(void)	Unknown
shell32.dll!CExplorerBrowser::_CleanupFrame(void)	Unknown
shell32.dll!CExplorerBrowser::Destroy()	Unknown
comdlg32.dll!CFileOpenSave::_OnDestroyDialog()	Unknown
comdlg32.dll!CFileOpenSave::s_OpenSaveDlgProc()	Unknown
user32.dll!UserCallDlgProcCheckWow()	Unknown
user32.dll!DefDlgProcWorker()	Unknown
user32.dll!DefDlgProcW�()	Unknown
user32.dll!UserCallWinProcCheckWow()	Unknown
user32.dll!DispatchClientMessage()	Unknown
user32.dll!__fnDWORD�()	Unknown
ntdll.dll!KiUserCallbackDispatcherContinue�()	Unknown
win32u.dll!NtUserDestroyWindow�()	Unknown
user32.dll!DialogBox2()	Unknown
user32.dll!InternalDialogBox()	Unknown
user32.dll!DialogBoxIndirectParamAorW�()	Unknown
user32.dll!DialogBoxIndirectParamW�()	Unknown
comdlg32.dll!CFileOpenSave::Show()	Unknown
[Managed to Native Transition]	
Ookii.Dialogs.Wpf.dll!Ookii.Dialogs.Wpf.VistaFolderBrowserDialog.RunDialog(System.IntPtr owner) Line 171	C#
Ookii.Dialogs.Wpf.dll!Ookii.Dialogs.Wpf.VistaFolderBrowserDialog.ShowDialog(System.Windows.Window owner) Line 157	C#
Ookii.Dialogs.Wpf.Sample.exe!Ookii.Dialogs.Wpf.Sample.MainWindow.ShowFolderBrowserDialog() Line 166	C#
Ookii.Dialogs.Wpf.Sample.exe!Ookii.Dialogs.Wpf.Sample.MainWindow._showDialogButton_Click(object sender, System.Windows.RoutedEventArgs e) Line 56	C#

[RumbleballTheReal]

Samme issue here. When packaging the projekt according to
https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/modernize-wpf-tutorial-5
the program hangs when showing the dialog.

I stripped the project to the bare minimum to provide a sample project, keeping the dialog spawning code and a button. Now it works in packaged application...

[augustoproiete]

@RumbleballTheReal Could you provide a reproducible example & corresponding dotnet build command-line arguments?

[RumbleballTheReal]

Unfortunately/Luckily (depending on the pespective) its working today... If it happens again, I will try again to provide something.

[matelich]

It's been a good while since I gave up on this, so I thought I'd give it another try. Since last time:

• Updated to .NET 4.8.0
• Doing a 64bit build
• Created a sibling application using 90% the same code

The sibling application works fine in debug and release. My original application still has the same behavior as previously, except Debug builds run properly outside the debugger.

Tried running under dnSpy, after dialog.Show insize RunDialog, it stepped through several loops of SubclassWndProc before hanging. Then printed the following to its output after.

13:46:27.744 Managed Debugging Assistant 'ContextSwitchDeadlock' has detected a problem in 'c:\dev\eddynet\bin64\dashboard.exe'.
13:46:27.746 Additional information: The CLR has been unable to transition from COM context 0x1fc06000 to COM context 0x1fc05ed8 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

Additionally, I had to disable the DisconnectedContext assistant to even get to use the application, and when I try to show the dialog, I get an InvalidApartmentStateChange. Doing a few more runs in the debugger, it's pretty clear that the WCF stuff is really not having a nice time. And the sibling application does not use the WCF stuff, so that's why it works.

This application works fine under VS and standalone, not sure why dnSpy makes it so mad, or what's up with the COM stuff or how to make it happier with Ookii.