roslyn: Roslyn should never report a non-fatal watson on the UI thread

From @davkean on August 3, 2018 7:9

I raised this issue here: https://github.com/dotnet/roslyn/issues/20101, but the reporting part got lost. I’m running into UI delays due to Roslyn reporting watsons on the UI thread. If I look around the tree, other components, such as CPS (see ProjectFaultHandlerService.HandleErrorAsync), push the work onto a background thread.


Frame | IncCt | IncAvg
-- | -- | --
ROOT | 1 | 49,444
ntdll.dll!_RtlUserThreadStart | 1 | 49,444
ntdll.dll!__RtlUserThreadStart | 1 | 49,444
kernel32.dll!BaseThreadInitThunk | 1 | 49,444
devenv.exe!__scrt_common_main_seh | 1 | 49,444
devenv.exe!WinMain | 1 | 49,444
devenv.exe!CDevEnvAppId::Run | 1 | 49,444
devenv.exe!util_CallVsMain | 1 | 49,444
msenv.dll!VStudioMain | 1 | 49,444
msenv.dll!VStudioMainLogged | 1 | 49,444
msenv.dll!CMsoComponent::PushMsgLoop | 1 | 49,444
msenv.dll!SCM_MsoCompMgr::FPushMessageLoop | 1 | 49,444
msenv.dll!SCM::FPushMessageLoop | 1 | 49,444
msenv.dll!CMsoCMHandler::FPushMessageLoop | 1 | 49,444
msenv.dll!CMsoCMHandler::EnvironmentMsgLoop | 1 | 49,444
msenv.dll!MainMessageLoop::ProcessMessage | 1 | 49,444
user32.dll!DispatchMessageW | 1 | 49,444
user32.dll!DispatchMessageWorker | 1 | 49,444
user32.dll!UserCallWinProcCheckWow | 1 | 49,444
user32.dll!_InternalCallWinProc | 1 | 49,444
windowsbase.dll!MS.Win32.HwndSubclass.SubclassWndProc | 1 | 49,444
windowsbase.dll!System.Windows.Threading.Dispatcher.LegacyInvokeImpl | 1 | 49,444
windowsbase.dll!System.Windows.Threading.ExceptionWrapper.TryCatchWhen | 1 | 49,444
windowsbase.dll!System.Windows.Threading.ExceptionWrapper.InternalRealCall | 1 | 49,444
windowsbase.dll!MS.Win32.HwndSubclass.DispatcherCallbackOperation | 1 | 49,444
windowsbase.dll!MS.Win32.HwndWrapper.WndProc | 1 | 49,444
windowsbase.dll!System.Windows.Threading.Dispatcher.WndProcHook | 1 | 49,444
windowsbase.dll!System.Windows.Threading.Dispatcher.ProcessQueue | 1 | 49,444
windowsbase.dll!System.Windows.Threading.DispatcherOperation.Invoke | 1 | 49,444
windowsbase.dll!MS.Internal.CulturePreservingExecutionContext.Run | 1 | 49,444
mscorlib.dll!System.Threading.ExecutionContext.Run | 1 | 49,444
mscorlib.dll!System.Threading.ExecutionContext.RunInternal | 1 | 49,444
windowsbase.dll!System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext | 1 | 49,444
windowsbase.dll!System.Windows.Threading.DispatcherOperation.InvokeImpl | 1 | 49,444
windowsbase.dll!System.Windows.Threading.ExceptionWrapper.TryCatchWhen | 1 | 49,444
microsoft.codeanalysis.editorfeatures.dll!Microsoft.CodeAnalysis.Editor.Shared.Utilities.SynchronizationContextTaskScheduler.PostCallback | 1 | 49,444
mscorlib.dll!System.Threading.Tasks.TaskScheduler.TryExecuteTask | 1 | 49,444
mscorlib.dll!System.Threading.Tasks.Task.ExecuteEntry | 1 | 49,444
mscorlib.dll!System.Threading.Tasks.Task.ExecuteWithThreadLocal | 1 | 49,444
mscorlib.dll!System.Threading.ExecutionContext.Run | 1 | 49,444
mscorlib.dll!System.Threading.Tasks.Task.ExecutionContextCallback | 1 | 49,444
mscorlib.dll!System.Threading.Tasks.Task.Execute | 1 | 49,444
microsoft.visualstudio.languageservices.dll!Microsoft.VisualStudio.LanguageServices.Packaging.PackageInstallerService+<>c__DisplayClass_0.<OnWorkspaceChanged>b__ | 1 | 49,444
microsoft.visualstudio.languageservices.dll!Microsoft.VisualStudio.LanguageServices.Packaging.PackageInstallerService.ProcessBatchedChangesOnForeground | 1 | 49,444
microsoft.visualstudio.languageservices.dll!Microsoft.VisualStudio.LanguageServices.Packaging.PackageInstallerService.ProcessProjectChange | 1 | 49,444
microsoft.visualstudio.languageservices.dll!Microsoft.CodeAnalysis.ErrorReporting.WatsonReporter.Report | 1 | 49,444
microsoft.visualstudio.telemetry.dll!Microsoft.VisualStudio.Telemetry.TelemetrySession.PostEvent | 1 | 49,444
microsoft.visualstudio.telemetry.dll!Microsoft.VisualStudio.Telemetry.SessionChannel.WatsonSessionChannel.PostEvent | 1 | 49,444
microsoft.visualstudio.telemetry.dll!Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.PostWatsonReport | 1 | 49,444
mscorlib.dll!System.Threading.WaitHandle.WaitOne | 1 | 49,444
mscorlib.dll!System.Threading.WaitHandle.InternalWaitOne | 1 | 49,444
clr.dll!WaitHandleNative::CorWaitOneNative | 1 | 49,444
clr.dll!Thread::DoAppropriateWait | 1 | 49,444
clr.dll!Thread::DoAppropriateWaitWorker | 1 | 49,444
clr.dll!Thread::DoSyncContextWait | 1 | 49,444
clr.dll!MethodDescCallSite::CallTargetWorker | 1 | 49,444
clr.dll!CallDescrWorkerWithHandler | 1 | 49,444
clr.dll!CallDescrWorkerInternal | 1 | 49,444
microsoft.visualstudio.telemetry.dll!Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.NoPumpSyncContext.Wait | 1 | 49,444
kernelbase.dll!WaitForMultipleObjects | 1 | 49,444

Copied from original issue: dotnet/project-system#3825

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 36 (36 by maintainers)

Most upvoted comments

I don’t see NFW on a background thread as any better than a NFW on the UI thread. We should resolve these cases by eliminating the conditions that led to the report in the first place.

if NFW decide to send a report, it will freeze the process, so which thread it is running shouldn’t matter. if it decides not to send a report, it takes about no time, so it again, shouldn’t matter whether it runs on UI thread or not.