"Unexpected false" exception thrown by Roslyn compiler in the background

Question

I'm currently having a problem with the Roslyn compiler crashing my test instance of Visual Studio with Roslyn.

Basically, I have a Roslyn project which generates a new code file for me based on an existing code file. It's working fine and doesn't throw any exceptions or anything like that. It creates the preview, and it also creates the new document. This all works as expected, even though it still is unfinished. So that's not the problem.

So the code file is generated, and I can open it and scroll through it. This works fine still, but after about 5 seconds an exception will be thrown in my other VS environment. I can't recover from this exception, and I'm forced to stop my Roslyn VS.

The exception is as followed:

A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread.

It has 1 inner exception, namely an "Unexpected false", with the following stack trace:

   at Roslyn.Utilities.Contract.ThrowIfFalse(Boolean condition, String msg)
   at Roslyn.Compilers.AssemblyIdentity.CreateName(String name, Version version, CultureInfo culture, Byte[] publicKey, AssemblyNameFlags flags, String location)
   at Roslyn.Compilers.CSharp.SourceAssemblySymbol..ctor(Compilation compilation, String nameAndExtension, IEnumerable`1 netModules, Version version)
   at Roslyn.Compilers.CSharp.Compilation.AssemblyManager.CreateSourceAssemblyForCompilation(Compilation compilation, Version assemblyVersion, Dictionary`2& referencedAssembliesMap, Dictionary`2& referencedModulesMap, SourceAssemblySymbol& assemblySymbol, DiagnosticBag& diagnostics)
   at Roslyn.Compilers.CSharp.Compilation.AssemblyManager.CreateSourceAssemblyForCompilation(Compilation compilation)
   at Roslyn.Compilers.CSharp.Compilation.get_Assembly()
   at Roslyn.Compilers.CSharp.Compilation.get_SourceModule()
   at Roslyn.Compilers.CSharp.Compilation.GetDiagnostics(CompilationStage stage, CancellationToken cancellationToken)
   at Roslyn.Compilers.CSharp.Compilation.Roslyn.Compilers.Common.ICompilation.GetDeclarationDiagnostics(CancellationToken cancellationToken)
   at Roslyn.Services.Editor.Implementation.Diagnostics.DiagnosticProvider.ComputeDeclarationDiagnostics(ISolution solution, ProjectId projectId, Dictionary`2 latestVersions, CancellationToken cancellationToken)
   at Roslyn.Services.Editor.Implementation.Diagnostics.DiagnosticProvider.LoadOrComputeDeclarationDiagnostics(ISolution solution, ProjectId projectId, Dictionary`2 latestVersions, CancellationToken cancellationToken)
   at Roslyn.Services.Editor.Implementation.Diagnostics.DiagnosticProvider.<>c__DisplayClass3.<GetDeclarationDiagnostics>b__0(CancellationToken c)
   at Roslyn.Services.Editor.Implementation.Diagnostics.DiagnosticProvider.GuardedDiagnostics.GetAddOrUpdate(Func`2 create, Func`2 shouldUpdate, Func`3 update, CancellationToken cancellationToken, Boolean& createdOrUpdated)
   at Roslyn.Services.Editor.Implementation.Diagnostics.DiagnosticProvider.GetDeclarationDiagnostics(ISolution solution, ProjectId projectId, Dictionary`2 latestVersions, CancellationToken cancellationToken)
   at Roslyn.Services.Editor.Implementation.Diagnostics.DiagnosticProvider.<>c__DisplayClass19.<CollectErrors>b__18()
   at Roslyn.Services.Editor.Shared.Threading.AsynchronousSerialWorkQueue.<>c__DisplayClass9.<EnqueueBackgroundWork>b__7(Task _)
   at Roslyn.Utilities.TaskExtensions.<>c__DisplayClass5.<SafeContinueWith>b__4(Task antecedent)
   at Roslyn.Utilities.TaskExtensions.<>c__DisplayClasse`1.<SafeContinueWith>b__d(Task antecedent)
   at System.Threading.Tasks.Task.<>c__DisplayClasse`1.<ContinueWith>b__d()
   at System.Threading.Tasks.Task`1.InvokeFuture(Object futureAsObj)
   at System.Threading.Tasks.Task.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()

That's all the information I get. I'm forced to close my debugee, and that's it. It's strange that it crashes like that after it has generated all the code. The code preview works fine as well. Of course there are squiggly lines, but it doesn't throw the exception. It only throws the exception after it has generated the new code file. It doesn't matter if I have it opened or not.

If I then start a test instance again, and add the code file manually (it still exists as a file, it's just not added to the project yet because of the crash), it will crash again after a few seconds.

So when investigating this further, at a few moments I thought I found the cause, but it happens sporadically. I think it has something to do with adding or removing files to/from a project, but even then it doesn't happen always. It never happened on a project which I used mostly for testing my extension, and it seems to always happen on another project. But I don't know why. It also happened a few times by simply opening a project where I just added the new file in a non-Roslyn VS.

Has anyone had similar problems? Is this a bug in the Roslyn CTP? Or am I doing something wrong? Is there a way to avoid this? It's quite annoying as it simply terminates VS and there's no way to recover from it :D

Answer 1

Hi Nico,

From looking at the source to Roslyn.Compilers.AssemblyIdentity.CreateName, it looks like this happens when you try to create an assembly with an empty string for the name.  How are you creating the compilation? Is it through the VS project system?  Can you take a look at the .csproj, and see if there is anything strange about it?

Regarding the debugging experience, one thing you can do is see the exception when it is first thrown, instead of in the Task's finalizer.  To do this, you need to enable breaking on first chance exceptions in the Debug->Exceptions dialog.  Unfortunately, it's still not a great experience.  We've done some work to improve this sort of thing since the CTP, but overall it's a hard problem when we're trying to so much of our work in an asynchronous or deferred manner.

Hope this helps!

---

-- Kevin Pilch-Bisson [e-mail]

Answer 2

Hi Kevin,

I'm not creating the compilation manually, visual studio does it in the background automatically. I have no control over it at all, except that it seems to start happening whenever I change something. 

I've enabled all the exceptions, and also set to enable unmanaged code debugging. I also have a project that causes the crash always whenever I remove a non-existing file from that project. Whenever I load that project, it shows some managed debugging assistant errors. Compared to loading a 'safe' project that doesn't crash, the only interesting one is a LoadFromContext one.

Managed Debugging Assistant 'LoadFromContext' has detected a problem in 'c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe'.
Additional Information: The assembly named 'Microsoft.Xna.GameStudio' was loaded from 'file:///C:/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/IDE/Extensions/Microsoft/XNA Game Studio 4.0/Microsoft.Xna.GameStudio.DLL' using the LoadFrom context. The use of this context can result in unexpected behavior for serialization, casting and dependency resolution. In almost all cases, it is recommended that the LoadFrom context be avoided. This can be done by installing assemblies in the Global Assembly Cache or in the ApplicationBase directory and using Assembly.Load when explicitly loading assemblies.

The other errors are BindingFailures for TeamFoundation and a few other things, but that happens in the safe project as well, so I doubt it's that.

Then when I remove the file from the project, it throws the aggregated unhandled task exception from my first post. I only get the call stack location from kernel32.dll, which is kernel32.dll?7585339a(), for what it's worth. There's still no way to recover from it, and it will just terminate VS again.

So I can only suspect it's from when it tries to load an assembly in the wrong way. In this case, it's an XNA project, but I don't think there's anything else special about it. I'll just avoid using this project for testing my Roslyn extension, and when I find another one that consistently breaks, I'll compare the errors again to try and pinpoint the cause further.

Answer 3

I can now let it crash reliably from scratch.

1. Start a fresh instance of VS with Roslyn enabled
2. Create a new XNA 4.0 windows game project
3. Add a new class
4. Wait 5-10 seconds for it to explode

That's it. I don't know if it's just me, or if it can be reproduced by anyone else. The problem isn't caused by my extension though, and I now know not to use XNA projects with Roslyn. If anyone else can reproduce this, then it's definitely an issue with Roslyn. If not, then I don't know why it happens to me :D

Answer 4

I would guess that it's a bug in Roslyn.

We haven't done any testing whatsoever with XNA projects yet, so it's likely that there is something about the way that project flavor works that we'll need to handle.

Sorry about the inconvenience!

---

-- Kevin Pilch-Bisson [e-mail]

Answer 5

Kevin,

For me it happens too in SharePoint, .NET 3.5 and a bunch of other project types. It happens each time the Garbage Collector runs after adding a new file to the project using Roslyn. I can keep open the crash dialog and Visual Studio keeps working semi fine...

---

My blog: blog.jessehouwing.nl