How I fixed Visual Studio crashing when opening XAML (WPF) files
For the second time, Visual Studio 2008 began crashing when double clicking on a XAML file. In this case, the crash was spectacularly underwhelming. No error message, blue screen or other indication of something horrible happing. Visual Studio would simply go a way, or “blink out” as I’ve seen it referred to.
After much searching I was able to determine that the PowerCommands for Visual Studio 2008 extension was somehow involved in the problem. I tried quite a few different solutions including adding a dependantAssembly reference in my Visual Studio configuration, doing a clean solution then rebuilding the project. Up to that point the only thing that worked was uninstalling the extension. Reinstalling afterwards would cause the problem to return.
Working without PowerCommands was an option I did not want to consider. Many times each day I would use functions such as “Open Command Prompt” which fires up cmd.exe starting in the directory of the file or folder selected in the solution explorer or “Open Containing Folder” on a file, just to mention a couple. It was looking like that was going to be the only solution, I was bummed.
I decided to check with the source a bit further. I looked through their issue list and the top voted issue was VS 2008 crashes when adjusting toolbox items. Reading the description did not give me a lot of hope as it dealt with a problem when the toolbox items were adjusted. It also included an actual error which was lacking in my case.
Among the comments to the above issue, I found the suggestion to run the command “ngen /delete *” (without the quotes) from a Visual Studio 2008 command prompt. Ngen is the native image generator which creates native images from managed assemblies and installs a native image cache on a computer, which is a reserved area of the global assembly cache.
Wow, that sounds important, and I’m suppose to delete * (star)? Ok….I was desperate and I did it before investigating what it meant. Dangerous, I know, I know, but as I said I was desperate!
It worked. Nothing seemed to break…and it worked. Ok, off we go! Wait, time to investigate….just in case problems start cropping up later.
Running ngen /? from the command prompt yielded no information, not a mention of the /delete switch. In my experience, when a command line utility fails to mention an argument that clearly did something, this is an argument that should only be used with full knowledge of what it does. Now I started to get nervous!
I did a quick Google Search and was lead to the MSDN documentation for ngen. It seems that my little command deleted all native images in the native image cache. Hmm….that sounds bad. Fortunately, a little further down the page the following information was also present.
This made me feel a little better. The assemblies were still there, simply not the native images for them. Native images simply cause the applications or assemblies to start up a bit faster. With today’s hardware, I don’t know that I’ll even notice a difference, or if I do, it will be worth it to keep PowerCommands and get rid of the problem.
If this behavior resurfaces, I will do a little more investigation by using the /show argument to find out what native images are installed. Then I will started deleting them one at a time to find the culprit. My guess is that one of the native images somehow became corrupted, or the configuration for it got messed up or something like that. Perhaps finding the culprit will aid in the resolution of the issue that this wonderful extension is experiencing by, if the Google results are any indication, a fair number of developers.