I got my shiny new work laptop on Tuesday this week, a HP EliteBook 8560P. Mmm, shiny.
So a portion of the remainder of my week has been spent on installing things like SQL Server and other development tools on it. Until I got to Visual Studio 2010, for which the installer hung at the end of the first screen (the one where it installs Setup components before you get to choose which bits of VS you actually want to install).
A few details. I'm running Windows 7 Enterprise, and I was installing Visual Studio 2010 Ultimate. I was using Virtual CloneDrive to mount an ISO image of the Visual Studio DVD from a USB hard drive. All things I've done before without any issues.
Thought 1: My ISO image has got subtly corrupted somehow. I downloaded from MSDN a new ISO image of Visual Studio. No joy.
Thought 2: There's a problem with running the installer off a mounted ISO. Despite being sure I'd successfully run off a mounted ISO before, I burned a DVD and ran the installer from there. No joy.
At this point I tweeted that I was struggling:
I was grousing more than expecting anyone to offer advice, but I received these tweets back:
Fair enough, I'll give that a go:
Thought 3: It is working, I'm just not giving it long enough to work. I ran the installer for at least 8 hours overnight Wednesday. No joy.
At this point I was Googling pretty hard for issues relating to the Visual Studio hanging, but no one seemed to have had a problem at the same stage as me. It did lead to me trying
Thought 4: A missing Registry key
I added the key. No joy.
Thought 5: The installer was trying to write temporary files to the external USB drive. I copied the ISO onto the hard drive, disconnected the external USB drive and re-ran the installer. No joy.
Desperation was setting in at this point, and I began to wonder if the problem was my install order.
Thought 6: Because I've installed SQL Server (and SQL Express), something in SQL Server is interfering with the install. I uninstalled both instances of SQL Server 2008 and the shared components. No joy.
Here comes the science bit...
I'd already been running SysInternals' Process Explorer to try and see what was going on with the installer process but it didn't really show me enough detail. However I notioced from a discussion on the Microsoft forum someone else using Process Monitor, so I fired that up instead, and filtered it so I was just looking at setup.exe. This is what I saw:
My first thought here was: why is setup.exe trying to write files to live.sysinternals.com?, closely followed by: have I done this right or is Process Monitor somehow screwing up these results? And suddenly, in one of my occasional flashes of intuition, it clicked.
I have a drive mapped to \\live.sysinternals.com\tools, and the drive that I have mapped is the I: drive. 'Cos, y'know, Internals begins with I. Turns out that the Visual Studio installer maps a folder in your %TEMP% folder to I: too and then uses it for decompressing some of the CAB files that the installer uses. Since I already had an I: drive, the installer was trying to use it but failing as I (obviously) don't have write privileges to the SysInternals folder, and the whole thing ended up in an infinite loop. I unmapped my I: drive from the SysInternals folder, re-ran the installer and everything installed successfully.
Now, clearly, the set of people who a) have an I: drive mapped but b) don't have write access to it and c) need to install Visual Studio, is going to be pretty small, but at the same time I can't help feeling the installer should have handled this better. In the end it was a simple workaround for me to resolve it, but it took me too long to discover the problem. Logged on Connect at https://connect.microsoft.com/VisualStudio/feedback/details/705657.