Interesting Tweet

I just saw this tweet on Twitter:



I don't know the whole back story, and I'm sorry Jim feels that his work is going down the drain, but I only have one thing to say to this:

Hip Hip Hooray!!!!!

SQL Server 2005 SP3 Horrible Setup Experience Results in BSOD

I maintain a bootstrapper at work and recently we were asked to update SQL Server 2005 SP2 to SQL Server 2005 SP3.

Not a big deal, right?

Wrong!

When installing SQL 2005 SP3 the setup just blows chunks and reboots the computer via blue screen of death!

Worse, the machine goes into an infinite reboot because the installation is an incomplete state and everytime the SQL services try to start the machine BSODS again.

You can boot safe mode and disable the services and then reboot again. But if you attempt to uninstall SQL server you get an error message saying it can't be accomplished.

Wow, thank you Microsoft, you've outdone yourself yet again.

So in digging into this problem it seems that the SQL team is punting to the Windows team. They are saying that they manifested PE files for Vista/2008 in SP3 and that due to a bug in Windows SXS on SP2 ( hotfix available for SP2 or otherwise update to SP3 ) that there is nothing the SQL team can due to solve this.

Um, they could at least put an AppSearch/LaunchCondition into their install so that my machine doesn't turn into a burning pile of dung!

Anyways here's my official warning. Avoid SP3 like the plague and if you must go there, make sure you provide your own prereq check for SP3 or SxS hotfix level in and as always make sure you integration test your installs on the lowest platform configuration possible. I'd hate for some ISV to test on SP3, never see this problem and then ship a product that embeds SQL to a customer. I'd hate even more to have to be taking that BSOD support call.

Records Being Dropped From Merge Module Projects When Built Using the InstallShield 2009 Standalone Build

---------------------------------------------------------------
[Update/Retraction 3/16/09]
I like to think I'm a big enough man to admit when I'm wrong, so here goes...
The problem reported in this post is fixed by updating to the SP2 version of IS 2009 Standalone Build. Now in my defense, I didn't know there was an SP2 until I reported this problem because the Software Manager doesn't properly identify the update (so I thought I already had "Standalone Build" installed). Anyway, I'm going to leave the original post up (below) in case any readers have the same problem.
---------------------------------------------------------------

I thought I'd post information about another bug I found in InstallShield 2009 merge module projects that I found while comparing output from a merge module project built using the standalone builds for IS 12 and IS 2009.

Records entered into the ProgId or Registry tables in the merge module source project do not get created in the output merge module file (.msm).

Acresso support has duplicated this behavior and I am currently working with them to find a work around (my incident number is SIOA-000143195).

This can be a serious issue if you are not using [or cannot use] the "COM Extract At Build" option to populate the appropriate MSI tables with COM interfaces when the module contains COM binaries. An example of this (that I'm stuck with at the moment) is if the install contains 64-bit COM binaries but is actually built on an x86 machine. In this case, the "COM Extract At Build" option doesn't work so we use the "REG File To Merge At Build" option to add the required interfaces directly to the MSI Registry table.

I suspect (but have not confirmed) that this may also occur for any records added to the Class or TypeLib tables in a merge module source project file. There may also be others.