For the past few days, my newly installed Visual Studio 2015 would randomly crash, naturally at the most inconvenient of times. In the 10 odd instances I could notice no discernable pattern to the crashes. It seems to happen randomly but consistently.
2015 comes with a new feedback feature in the form of smilies. You can send Microsoft a smile or a frown. I have been sending frowns every time the crash happened. Whoever opens and reads this frown would have seen my increasingly desperate messages.
This particular crash only seems to happen to me as well. Nobody else at work seems to suffer from it. There was also no error message except “Windows is trying to find a solution to your problem” – It never found it. I was beginning to wonder if I was the only person on earth to suffer from this. Hardware failure crossed my mind. Was my RAM broken? Did my computer catch a virus? You begin to think crazy thoughts when you lose your work. OK, so it wasn’t that bad, most of the time Visual Studio would recover and at most I would only lose a semicolon, but it was still a form of torture having your train of thought interrupted randomly.
Every time you send a frown to Microsoft, you could optionally attach more information. If you select the Visual Studio Crashed as the reason of your frown, you would be presented with an option to record the steps to reproduce the crash. In my case, there was no steps. Visual Studio could be idle with no project open and it would just crash. I tried capturing idleness, but it would never crash when the capture was running. I also didn’t want to run the capture for hours during my normal work – who knows what it captures and which NSA datacenter it would end up in!
A quirk with the Visual Studio capture was that it can’t capture itself. At first this wasn’t evident to me and I sent a rant and frown to MS for having a broken tool. After reading the instructions, which said to open another Visual Studio, it was probably attaching a debugger from this VS to the other VS. Then it dawned on me that, what if I just ran a VS and attach it to my working VS, so that I can get some data when it crashes!
That’s exactly what I did and I was rewarded with a break on an UnauthorizedAccessException. From here onwards, solving the issue was quite straight forward. For some reason there was corrupt permissions on this VSRemoteDebugger temporary folder, fixing the permissions to allow write access solved it.
I guess at the end I got lucky that the error is a CLR exception and not some Access Violation. I was kinda expecting to have to analyse a stack trace, maybe send it off to MS in hope that they’ll fix it, but it was necessary in this case – I fixed the issue myself.