Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS 2017 crashes: unhandled exception in Microsoft.VisualStudio.Package.Colorizer.GetLineInfo() #2589

Closed
SirEel opened this issue Mar 11, 2017 · 13 comments

Comments

@SirEel
Copy link

SirEel commented Mar 11, 2017

Repro steps

Installed VS 2017 RTM with F# language chosen. Additionally installed Desktop, ASP.NET, ASP.NET Core, Data, and Azure workflows.

I always use Tools-Options to change the font in text editor and FSI to DejaVu Sans Mono instead of the default Consolas. This worked fine in VS 2015. I also customize the text editor's background color when using the Blue color scheme, but I've encountered same problems below when using other color schemes with default colors. I don't know if these settings are causing the problem, but the error messages trace to Microsoft.VisualStudio.Package.Colorizer.

I haven't used VS 2017 for anything except creating FSX scripts and executing them in FSI. So I don't know if this is an F#-specific problem. But the error messages indicate it's coming from "an editor or extension".

Expected behavior

No errors, no crashing

Actual behavior

Problem #1:
At seemingly random moments Visual Studio pops up an error that says, "An exception has been encountered. This may be caused by an extension. You can get more information by examining the file at C:\users\ ... \ActivityLog.xml"

In ActivityLog.xml I find:

714 2017/03/11 19:46:24.763 Error Editor or Editor Extension System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component. at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo) at Microsoft.VisualStudio.Package.Colorizer.GetLineInfo(IVsTextLines buffer, Int32 line, IVsTextColorState colorState) at Microsoft.VisualStudio.Package.Source.GetWordExtent(Int32 line, Int32 idx, WORDEXTFLAGS flags, Int32& startIdx, Int32& endIdx) at Microsoft.VisualStudio.Package.ViewFilter.GetWordExtent(Int32 line, Int32 index, UInt32 flags, TextSpan[] span) at Microsoft.VisualStudio.Editor.Implementation.SimpleTextViewWindow.GetWordExtent(Int32 iLine, Int32 iCol, UInt32 dwFlags, TextSpan[] pSpan) at Microsoft.VisualStudio.Editor.Implementation.ShimQuickInfoSource.TryGetQuickInfoFromDebugger(IQuickInfoSession session, TextSpan[] dataBufferTextSpan, String& tipText) at Microsoft.VisualStudio.Editor.Implementation.ShimQuickInfoSource.AugmentQuickInfoSession(IQuickInfoSession session, IList`1 qiContent, ITrackingSpan& applicableToSpan) at Microsoft.VisualStudio.Language.Intellisense.Implementation.QuickInfoSession.Recalculate() at Microsoft.VisualStudio.Language.Intellisense.Implementation.QuickInfoSession.Start() at Microsoft.VisualStudio.Language.Intellisense.Implementation.DefaultQuickInfoController.OnTextView_MouseHover(Object sender, MouseHoverEventArgs e) at Microsoft.VisualStudio.Text.Editor.Implementation.WpfTextView.RaiseHoverEvents()

This does not stop Visual Studio once I close the error dialog, so I continue working.

But then ...

Problem #2:
At seemingly random moments, Visual Studio crashes. Windows 10 pops up and says "This program has encountered an error and will restart." It restarts. The event log says:

Application: devenv.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.Runtime.InteropServices.COMException at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32, IntPtr) at Microsoft.VisualStudio.Package.Colorizer.GetLineInfo(Microsoft.VisualStudio.TextManager.Interop.IVsTextLines, Int32, Microsoft.VisualStudio.TextManager.Interop.IVsTextColorState) at Microsoft.VisualStudio.Package.Source.GetWordExtent(Int32, Int32, Microsoft.VisualStudio.TextManager.Interop.WORDEXTFLAGS, Int32 ByRef, Int32 ByRef) at Microsoft.VisualStudio.Package.ViewFilter.GetWordExtent(Int32, Int32, UInt32, Microsoft.VisualStudio.TextManager.Interop.TextSpan[]) at Microsoft.VisualStudio.Editor.Implementation.SimpleTextViewWindow.GetWordExtent(Int32, Int32, UInt32, Microsoft.VisualStudio.TextManager.Interop.TextSpan[]) at Microsoft.VisualStudio.Editor.Implementation.ShimQuickInfoSource.TryGetQuickInfoFromDebugger(Microsoft.VisualStudio.Language.Intellisense.IQuickInfoSession, Microsoft.VisualStudio.TextManager.Interop.TextSpan[], System.String ByRef) at Microsoft.VisualStudio.Editor.Implementation.ShimQuickInfoSource.AugmentQuickInfoSession(Microsoft.VisualStudio.Language.Intellisense.IQuickInfoSession, System.Collections.Generic.IList`1<System.Object>, Microsoft.VisualStudio.Text.ITrackingSpan ByRef) at Microsoft.VisualStudio.Language.Intellisense.Implementation.QuickInfoSession.Recalculate() at Microsoft.VisualStudio.Language.Intellisense.Implementation.QuickInfoSession.Start() at Microsoft.VisualStudio.Editor.Implementation.ShimQuickInfoSource+<>c__DisplayClass12_0.b__0(System.Object, System.EventArgs) at System.Windows.Threading.DispatcherTimer.FireTick(System.Object) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate) at System.Windows.Threading.DispatcherOperation.InvokeImpl() at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object) at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(System.Object) at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) at MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object) at System.Windows.Threading.DispatcherOperation.Invoke() at System.Windows.Threading.Dispatcher.ProcessQueue() at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef) at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef) at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate) at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)

Known workarounds

None

Related information

  • Operating system
    Windows 10
  • Branch
    Whatever comes with VS 2017 RTM
  • .NET Runtime, CoreCLR or Mono Version
    FSX files executing in FSI
  • Editing Tools (e.g. Visual Studio Version)
    2017 RTM
  • Links to F# RFCs or entries on http://fslang.uservoice.com
    none
  • Links to performance testing scripts
    none
  • Indications of severity
    occurs many times each day
@vasily-kirichenko
Copy link
Contributor

It's fixed in master long time ago.

@SirEel
Copy link
Author

SirEel commented Mar 11, 2017

Vasily, then whatever VS 2017 installed is pretty old.

Can you please point me to instructions for installing the latest stable build.

Thank you.

@cartermp
Copy link
Contributor

@SirEel Correct, VS 2017 bits are equivalent to what was shipped in RC 4 (as is the case with almost all of VS). There's a significant delay from master <--> VS RTW across most products.

You can install the latest stable master from CI here: https://github.com/Microsoft/visualfsharp/wiki/Using-CI-Builds

Note that these are unsigned, though, so you'll need to use the tool mentioned in the above link to get around that. We're very close to having signed builds of the latest master from our internal build system available. If you don't want the hassle of working with unsigned builds, I'd advise waiting until next week.

@SirEel
Copy link
Author

SirEel commented Mar 11, 2017

Phillip, Vasily,
Thanks. When the new signed build is available, will there be much delay before it feeds into Tools - Options - Extensions and Updates?

@cartermp
Copy link
Contributor

cartermp commented Mar 11, 2017

Good question. @brettfo or @KevinRansom could answer if there's a delay, but personally I think there should be a bit of a delay there. We're likely to spin up a build of master every day or two, so you'd constantly be pinged in VS for an update. We haven't discussed that particular cadence yet.

Just to be clear, though - the signed VSIXs we'll be generating from builds of master will be the same VSIXs which would install through Extensions and Updates. So there's nothing vastly different there.

@KevinRansom
Copy link
Member

@SirEel ... I believe the intent is for us to publish vsix' for our daily build. So ... no there should not be large delay. @brettfo is handling this work and may have more accurate information.

Kevin

@SirEel
Copy link
Author

SirEel commented Mar 11, 2017

Which leads to: when, and how frequently, do you expect an F# developer to update to the current build? Many of us interpret Update notices in Visual Studio as a sign that the new thing is a good thing, without going on Github to see what's in it. However, my experience with Newtonsoft.Json has taught me to be skeptical of that package's many frequent updates. I'd still be in favor of a frequent update cycle for Visual F# if the builds don't break things as often as Newtonsoft's do. After all F# produces fewer bugs, right?

@KevinRansom
Copy link
Member

@SirEel as frequently as they feel comfortable with, or whenever there is a new feature in the preview tooling they want to try out. I don't think we will be deploying via The VS Gallery, and so there will not likely be update notices on VS until the official release of the updated tooling.

I hope this helps

Kevin

@SirEel
Copy link
Author

SirEel commented Mar 11, 2017

OK, I'll try getting used to installing VSIXs.

BTW the instructions at https://github.com/Microsoft/visualfsharp/wiki/Using-CI-Builds seem to omit a few things.

  1. If I run the last step, sn -Vu ,, then I can't use Visual F#. I have to leave -Vr in place until I'm done in Visual Studio. This should go away when the build is signed, but meanwhile your instructions don't make it clear.

  2. I think you omit the first step. I had to uninstall F# Language support via the Visual Studio Installer before I could run VSIXInstaller.exe /uninstall:VisualFSharp.

Other than that, it's working so far.

@KevinRansom
Copy link
Member

The wiki is writeable, feel free to update it as you feel appropriate.

@SirEel
Copy link
Author

SirEel commented Mar 11, 2017

Kevin, hopefully it's more clear now. Thanks.

@cartermp
Copy link
Contributor

👍 Thanks for the update to it, @SirEel.

We're also still experimenting with how bet to handle updates with VS 2017 and onward. The update model has changed considerably since previous releases, and we also have an entirely new infrastructure with which to push updates. We described what our current plan is in our blog post. This may well change, though, and we'll announce any changes via another blog post when that happens.

@cartermp
Copy link
Contributor

Closing this as a dupe of #2318 for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants