Tooltip throws ArgumentNullException

[JNaumann86]

• .NET Version: 6.0.8
• Windows version: 10.0.19042 Build 19042

• Does the bug reproduce also in WPF for .NET Framework 4.8?: No (Can be also tested with the attached demo.sln by changing the target framework)

  Problem description: If a tooltip has been closed by timer and directly afterwards a mouse click action like CaptureMouse will be triggered an ArgumentNullException will be thrown. Can be not reproduced with .Net Framework 4.8.

Bug looks similar to this bug, which has been already fixed: https://github.com/dotnet/wpf/issues/6319 But bug still exists by doing different repro.

Actual behavior: App crashes with the following exception:

System.ArgumentNullException: Value cannot be null. (Parameter 'element') at System.Windows.Controls.ToolTipService.GetBetweenShowDelay(DependencyObject element) at System.Windows.Controls.PopupControlService.CloseToolTip(ToolTip tooltip) at System.Windows.Controls.PopupControlService.OnPostProcessInput(Object sender, ProcessInputEventArgs e) at System.Windows.Input.InputManager.RaiseProcessInputEventHandlers(Tuple`2 postProcessInput, ProcessInputEventArgs processInputEventArgs) at System.Windows.Input.InputManager.ProcessStagingArea() at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input) at System.Windows.Input.MouseDevice.Synchronize() at System.Windows.Input.MouseDevice.ChangeMouseCapture(IInputElement mouseCapture, IMouseInputProvider providerCapture, CaptureMode captureMode, Int32 timestamp) at System.Windows.Input.MouseDevice.Capture(IInputElement element, CaptureMode captureMode) at System.Windows.UIElement.CaptureMouse() at ToolTip.MainWindow.OnMouseLeftButtonDown(Object sender, MouseButtonEventArgs e) in D:\Workspace\Software\ToolTip\ToolTip\MainWindow.xaml.cs:line 64 at System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget) at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target) at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs) at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised) at System.Windows.UIElement.ReRaiseEventAs(DependencyObject sender, RoutedEventArgs args, RoutedEvent newEvent) at System.Windows.UIElement.OnMouseDownThunk(Object sender, MouseButtonEventArgs e) at System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget) at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target) at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs) at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised) at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args) at System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args) at System.Windows.Input.InputManager.ProcessStagingArea() at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input) at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport) at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel) at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, O bject args, Int32 numArgs, Delegate catchHandler) at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam) at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg) at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame) at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame) at System.Windows.Threading.Dispatcher.Run() at System.Windows.Application.RunDispatcher(Object ignore) at System.Windows.Application.RunInternal(Window window) at System.Windows.Application.Run() at ToolTip.App.Main()

Expected behavior: App should not crash.

Minimal repro: Please use the attached demo.sln and run it with .net 6 target framework. After the app window appears move your mouse into the window. A tooltip will be shown, which shows you the actual mouse position. Stop moving the mouse and wait 5 seconds until the tooltip disappears. Directly and quickly after the tooltip disappears quickly move your mouse a short distance and afterwards quickly do a left click.

Attached demo.sln: ToolTipBug.zip

[miloush]

Looks like duplicate of #6319 @SamBent does this help? I cannot reproduce under VS debugging but when I run Debug build without debugging I could reproduce couple of times and I managed under windbg too.

[JNaumann86]

Hi, I am using IDE Jetbrains Rider and I can reproduce it in debug mode with success rate of 100%. I even have an easy work around to avoid this bug. On click action before doing the mouse capturing I just have to close the tooltip manually. I just wanted to create the bug to help making .net6 a bit more stable :)

[SamBent]

Yes, this helps a lot. This is the repro (and time-travel trace, sent by @miloush privately) I've been waiting for since March.

It's a dupe of #6319 in the sense the root cause is the same: the app and WPF's PopupControlService are both manipulating the tooltip object (setting toolTip.IsOpen), and sometimes confusing each other in the process. The details of how the manipulation happens might be different, but that doesn't matter much.

Some notes:

• Bug 6319 is not fixed. There are some references there to other bugs that have been fixed, but the crash while trying to get the owner's BetweenShowDelay has not been addressed.
• All versions of .NET (at least back to 4.5, and probably farther) react to the ToolTip.Closed event by resetting the (internal) Owner property to null, even when the event is initiated by the app's direct manipulation. It seems to be just luck that this didn't lead to ANE crashes - there are no comments, tests, or any evidence that anyone knew that Owner was fragile in the presence of direct manipulation. The code just happened to work.
• The ANE crash also occurs in .NET 4.8.1. Not surprising, since it contains the same new code as .NET 6.0. That code affects all apps, regardless of TargetFrameworkVersion.
• Apps that manipulate tooltips directly are unlikely to get the benefit of the new WCAG 2.1-compliant behavior. They could get failing grades on accessibility tests.

[JNaumann86]

Hi thank you for the update!

I just wanted to state, that my workaround of closing the tooltip manually is not always working. Sometimes the bug still occurs, but with less frequency. Could you please estimate in which minor version upgrade of .Net6 the bug will be fixed?

Thank you!

[czdietrich]

Any news on this? This issue still states Investigate, is there currently active work on this?

[dipeshmsft]

@czdietrich, we have a fix for this. We are testing it right now. Once testing it complete, we will make a PR for this and other tooltip bugs.

[czdietrich]

Hi @dipeshmsft, thank you for the quick response and update to this issue. 👍

[znakeeye]

Tried running the demo.sln, but never got the crash. Are there any particular steps needed?

My system

• Windows 10
• 100% DPI
• .NET 6.0.11
• Debugging from within VS.

[czdietrich]

So, what is the latest status to this issue? We got PRs for the different .NET versions.

Can we expect they will be part of the .NET service packs in February?

[cmunforte]

We are also waiting this fix to go into the .Net 4.8 Framework. Any ideas when a Windows Update will be available for our customers to download?

[dipeshmsft]

@czdietrich, we are reviewing the timelines for shipping this fix. I will respond on this thread with the schedule ASAP.

@cmunforte, can you raise a DTS bug for .NET Framework? Any changes in .NET Framework are done through the DTS process. The CSS representative of the corresponding enterprise needs to file a DTS bug for this change to be in .NET Framework along with the business impact and justification.

[cmunforte]

@dipeshmsft I don't know what a DTS bug is or how to raise it. Do you have a link?

[werksarztzentrum]

We need also a quick fix for .NET Framework 4.8, all our Windows 11 Users have this problem in WPF.

[dipeshmsft]

@werksarztzentrum we have started work on that front as well. @cmunforte, sorry I missed your question, were you able to find the link to open a DTS bug?

[cmunforte]

@dipeshmsft No, I did not find the link to open a DTS bug. Actually we have found a fix to this issue so it is not as urgent anymore. So after a bit of fiddling around I was able to fix this crash within our code by attaching to the "ToolTipOpening" event and setting "e.Handled" to true.

public ChromiumWebBrowser Browser;
this.Browser.ToolTipOpening += this.OnToolTipOpening;

private void OnToolTipOpening(object sender, ToolTipEventArgs e)
{
         // Fixes the System.ArgumentNullException within System.Windows.Controls.ToolTipService.GetBetweenShowDelay
         // Funnily enough it still shows the tooltip!
         e.Handled = true;
}

I have also mentioned the fix here with further details:

ToolTip Crash Fix

[dipeshmsft]

@cmunforte @czdietrich @JNaumann86 we have merged the fix in the release branches and the fix will be out in upcoming servicing release of .NET 6 and .NET 7.

[dipeshmsft]

@cmunforte @czdietrich @JNaumann86 can you verify if the latest release ( 7.0.5 / 6.0.16 ) resolves issues in your applications ?

[dipeshmsft]

As the fix is already merged, closing this issue now.

[czdietrich]

@cmunforte @czdietrich @JNaumann86 can you verify if the latest release ( 7.0.5 / 6.0.16 ) resolves issues in your applications ?

Latest tests seem to show that the issue is gone now. At least we were no able to reproduce the issue any longer, but due to its sporadic nature we cannot say it with 100% certainty, but it is very likely to be fixed.

We will now begin to roll out the fix to our customers (if it is not already indirectly fixed by Microsoft Update) and look out for new reports. If so, we will report back here.

Thank you very much that this issue seems now to be finally gone. It was really the hardest .NET issue we faced in the recent time of .NET and with the most negative effect on our customer base. And I kindly hope that such issues can be more prioritized in the future for a better overall experience.