Friday, April 30, 2010

VS2010 "cannot create the window"

I installed the release-to-market (RTM) version of Visual Studio 2010 and it worked well for a few days and then suddenly it started giving me a "cannot create the window" error and refused to start.

I did a whole bunch of searching and discovered that there were some incompatibilities with Office 2010 beta (an incompatible DLL) that was causing most of the problems. Not in my case though because I'd never installed Office 2010. If, however, you are reading this and you have installed a version of Office 2010 then you might want to search further as that might be your problem.

I contacted the developers at Microsoft and they were outstanding in the help that they provided me. I downloaded a debugger and created some memory dumps of what was happening in VS2010 when it started and sent them off to Microsoft. They isolated that the problem was happening when the machine.config file was being loaded. I know that I had edited my machine.config and so I became suspicious of my edit.

A quick aside about machine.config's. On a 32-bit operating system with .NET 2 installed there's only one machine.config and that usually lives here:


If you have installed VS2010 then that means that you have also installed .NET 4 so there's another machine.config for .NET 4 and you can find that here:

(On my machine this is the one that VS2010 is using even though I'm running Windows 7 x64.)

If you have a 64-bit OS then you have 64-bit versions of these machine.config's as well taking the total to four. These can be found here:


(I don't know why one is in capitals and the other in proper case.)

An analysis of my machine.config's (all 4 of them) showed that I have incorrectly edited 2 of them. I had added a new section to the machine.config but had failed to add that section name to the sectionGroup. So I was missing this part of the machine.config:

<sectionGroup name="myNewSectionGroupName" ... > <section ...> </sectionGroup>

Which goes inside the <configSections> ... </configSections> part of the file.

In the end it was a PIBKAC* and not a VS2010 bug.

*PIBKAC = Problem Is Between Keyboard And Chair


Tuesday, April 20, 2010

.Net 4 VS2010 Conversion Notes

I'm in the process of converting a bunch of projects from .NET 3.5 to .NET 4.0 and know that I will be converting plenty more in the future so I thought I'd jot down some notes as I went along. This list of notes should increase over time.



.NET 3.0 and 3.5 were really an extension of .NET 2.0 so the machine.config remained constant here C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config or in the 64-bit equivalent here C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG

With .NET 4 we have new 32-bit and 64-bit locations here C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config and here C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config

If you've made modifications to your machine.config file for .NET 2.0, 3.0, or 3.5 then you'll have to propagate those changes to the .NET 4.0 version.


Links to conversion resources

Official What's new in ASP.NET MVC 2

ASP.NET 4 Breaking Changes


Breaking Changes that I've bumped into

<httpRuntime requestValidationMode="2.0" /> needs to be added to web.config to prevent the "A potentially dangerous Request.Form value was detected from the client" error.


Tuesday, April 13, 2010

Merging in Mercurial

I'm using TortoiseHg and trying to get the hang of merging changes from multiple contributors so I setup a small test and did some changes and commits and pulled each one into a main repository without doing any merges (except one at the beginning). This is what the tree looked like.

 Then I tried to do a number of different merges and found that nothing really worked (or in the end made sense) except for merging from the bottom of the graph to the tip. When I started doing this things started flowing smoothly. I had lots of conflicts because I made sure that each time I changed a file I changed the same line in different locations to force conflicts. The conflicts were easily resolved in the default KDiff3 text merge tool. This is what the graph ended up looking like in the end.

Saturday, April 3, 2010

Windows Home Server - the good and bad

About ten months ago I bought and setup a Windows Home Server on my home network. Since that date I've used it twice for recoveries.

I follow the three rules of "backup reality", i.e. if these 3 criteria aren't met then I don't consider it a real backup:

  1. If must be automated.
  2. It must be redundant.
  3. It must be duplicated off-site

This is a must for any business (even though many don't do this) but it's a pretty tall order for a home network. I find that Windows Home Server with Amazon S3 syncing gives me all this.

They say that an untested restore of a backup is no backup at all.

The first time I got to try out the restore feature of the server was when I upgraded the hard disk on a Server 2003 server from 250GB to 2TB. This was the perfect opportunity to try out the WHS restore feature. I let the nightly backup complete and in the morning I swapped out the drives, put in the restore disk and rebooted the machine. WHS recognized the machine and picked the correct backup and target and a few hours later the server was back up and running on a new hard disk. I was a bit surprised at how long the restore took, I remember it being several hours. I know that it also had to format the hard disk but still thought that it was longer than I would have expected.

The second time I got to try the restore was when I was unable to sign on to a Windows 7 Ultimate machine. Win7 just told me that my password was invalid. I could boot in safe mode and sign in but not in regular mode. I signed in using safe mode and moved the most recent data set to a USB drive and tried a number of troubleshooting recovery steps. Searches showed that this type of problem was being experienced by many Windows 7 users but no fix has come from Microsoft yet and none of the suggested workarounds had worked for me. So I attempted to do a restore from WHS. On booting with the recovery CD it wasn't able to correctly mach up the disk. That machine has 128GB Solid State Drive (SSD) as the boot drive and a 2TB drive as the secondary drive. The restore automatically picked to restore the boot drive to the 2TB drive which was the wrong one. That was easily changed using the restore UI but after the restore had been running for a couple of hours and completed about 80% of the restore it failed with a networking error. That networking error was also found all over the net with plenty of people experiencing the same type of error almost at the end of their restore. None of their workarounds worked for me. So my next and final recovery step was to re-install the OS. I did this and it still had problems booting.

Now the one thing that I didn't tell you about this machine was that when I put it together I had inadvertently wired the SSD boot drive as drive 1 and the 2TB data drive as drive 0. After putting the case back together and starting the machine I saw the problem and when into the bios and changed the boot drive to be the non-default 1 (from the default 0). This I believe was the source of most of my problems. My theory is that deep in the bowels of Windows 7 and many other pieces of device software written by many companies the boot drive is frequently assume to be 0 and this is often hard coded. Because the boot drive is rarely anything else this type of bug is hardly ever seen.

I opened up the case and switched the wires around and made the boot drive 0 and the data drive 1 and that was the first time in days that the machine had operated in a normal manner and this time it finally booted with my re-installed OS. Since then it has been running way smoother and I attribute this to the non-standard drive wiring that I had done. Even though it's supposed to be able to work the other way I just don't think that it's worth the risk to do that again. Drive 0 will always be my boot drive in the future if I have any choice.