Thread by @AnsonHorton

I was trying to remember any interesting event associated with a new year and the best I could come up with this morning is many years after what I've been tweeting about, in 2010. In 2010 we were working on Dev11 (VS 2012) and iterating closely with Windows on Windows 8.

I was leading a team to create a tooling experience for JavaScript Windows Store apps. Windows 8 was the introduction of the Windows Store and the new WinRT APIs, ABI format, etc. that allowed languages like JS, C#, VB .NET, C++, etc. to directly call the Windows API.

It was still early in Dev11 development, and my team was writing a new JavaScript language service (as well as a new project system). There was already an existing JS language service.

However, it was built on top of JScript 5.8, which was the JS runtime that supported ES3 and shipped with IE8. To support ES5, ABIs, larger apps and better performance we decided to implement a new LS on top of Chakra (which was the JS runtime that shipped in IE 9 in early 2011).

Chakra was a highly optimized JS runtime implemented in C++ within a module named jscript9.dll. The JS LS was very different from the C# LS, because to get completion, we actually executed the JS up to where the caret was located within the file.

We then examined the runtime state and used that to generate completion lists, etc. This introduces all kinds of fun problems that I'll talk about at some point, like guaranteeing that program execution actually *gets* to where your caret is, that you don't get stuck in infinite

loops, that execution doesn't take too long, etc. That's another post though. For this thread, we all received a mail on Nov. 23rd, 2010 kicking off the creation of a 'Holiday Build' of Windows and developer tools that folks could play with during the last few weeks of December

(if they chose to). In many ways, the intent was to create a forcing function for integration across many teams and divisions. The goal was to have a installable VS that supported JavaScript Windows Store development within ~3 weeks (so by Dec. 15th)

It's important to know that this was months ahead of our plan for a dogfoodable version of JS. So, we had a problem. We weren't even close to ready. In particular, the JS LS had this annoying behavior of AVing, which since it ran within the devenv process, would crash VS.

It was sufficiently frequent that folks surely would have lost all of their work on a regular basis and there simply wasn't time to address the known issues, much less uncover what we would certainly find afterwards as our validation was nascent.

So we were in a pickle, we couldn't rely on the old JS LS because it didn't understand the WinRT API at all (or ES5), and we really did want to start dogfooding on the new LS if we could. We couldn't have folks trying this and crashing every few minutes though, so…

time for everyone to close their eyes and hold their noses, we decided to *catch* AVs. Please don't do this, it's not good practice. However, it is possible by making use of this attribute docs.microsoft.com/en-us/dotnet/a….

In this case, the part of the LS that interacted with VS was written in managed code and called into JScript9ls.dll in order to provide language analysis. So, in that relatively short time, we implemented a proxy layer that insulated all of our calls into jscript9.dll such that

if an exception, like an AV, happened we would 'zombie' the proxy layer and prevent all further calls into jscript9. This would disable all LS functionality, your code wouldn't colorize, there would be no completions, etc.

We did display a message indicating that the LS had crashed and suggested saving your work and restarting. This prevented data loss, but obviously the process was in an unknown state. Our intent was that the proxy would limit the damage that would cause. Long story short, it did.

We successfully delivered the Holiday build, opened up dogfooding for Windows Store JavaScript apps, and were able to start getting dogfooding on the new JS LS and Project System. Of course, we now had another problem.

We didn't get 'Watson' (Windows Error Reporting) dumps whenever the LS crashed because we intercepted the AVs. Our new year's goal was to then remove that support, fix the underlying issues, and get a new build out as quickly as possible.

Although we didn't want to catch AVs any longer, we still wanted to prevent the LS from crashing if we had a managed exception.

We didn't want to lose reporting though, so early in 2011 we added the following dialog that would also zombie the language service, but allowed us to easily get reports with enough context to fix the issue:

When we shipped externally we changed this kind of reporting into what we call a non-fatal Watson, which would capture process state at the point where the error happened and upload anonymous telemetry about the issue (if the user opted in) so we could diagnose and fix.

Anyway, that year was very hectic right before the holidays and we just barely managed to deliver. Since then, whenever starting on a new project, I make sure have a sane and immediate way to collect, collate, and diagnose errors on day 1.

You never know when you might need to deliver months ahead of your original schedule :) Happy New Year everyone - this was a morale item given out in 2000 for folks on the VB team to ring in Y2k!