Avoid Overwriting Files in Administrative Installations

Avoid Overwriting Files in Administrative Installations

  • Comments 11

Last June before the Microsoft .NET Framework 2.0 shipped, I discussed how during administrative installations some 64-bit files overwrote some 32-bit files and I provided a transform to fix the issue. I filed a bug and the issue was fixed before .NET 2.0 shipped. Later in the release cycle the Office Crash Reporting Tool, otherwise known as the Microsoft Application Error Reporting tool or "Dr. Watson", was merged into the .NET 2.0 .msi files for each processor architecture and shipped.

Take a look at the component entries for different files with the same name for both x64 and x86 processor architectures. Paragraph characters (pilcrows) have been added to help delimit separate rows.

OfficeCrashReportingPolicyAmd_1033.F0DF3458_A845_11D3_8D0A_0050046416B9, {0C29705B-6507-4B80-AA5C-DD4683A83766}, WindowsINFFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, 256, dw20.adm_0001_1033.F0DF3458_A845_11D3_8D0A_0050046416B9
OfficeCrashReportingPolicy_1033.D0DF3458_A845_11D3_8D0A_0050046416B9, {8CEA2451-A5C7-426B-91A7-ECCDD5E545F6}, WindowsINFFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, 0, dw20.adm_1033.D0DF3458_A845_11D3_8D0A_0050046416B9

Note component directories for each component. While the first letter in bold is different, they resolve to the same directory as shown in the excerpt of the Directory table below. For good documentation on resolving directories in the Directory table, see Rob Mensching's latest entry in his series about deciphering the Directory table.

WindowsINFFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, WindowsFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, INF
WindowsINFFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, WindowsFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, INF

WindowsFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, TARGETDIR, WINDOWS

WindowsFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, TARGETDIR, WINDOWS

These directories are set using type 51 custom actions as defined below, both called very early in the various sequence tables.

WindowsFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, 51, WindowsFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, [WindowsFolder]
WindowsFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, 51, WindowsFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, [WindowsFolder]

When you install the product, the files are installed correctly because the first component above uses component attribute msidbComponentAttributes64bit (256), which will cause the component to install into the 64-bit location, while the 32-bit component will be redirected into the 32-bit location under %WINDIR%\SysWOW64.

However, when you perform an administrative installation using the 64-bit .msi file, files sequenced later in the File table will overwrite files destined for the same directory that are sequenced earlier in the File table. Component attributes are not a factor when performing an administrative installation. Keep this in mind when authoring your installation packages by directing files ultimately destined for different locations during client installations into different directories in the Directory table.

Different files with the same name but for different processor architectures aren't the only cause of this issue, however. Managed assemblies to be installed into the Global Assembly Cache are also installed into directories as decided by fusion, such that during installation the Directory table doesn't matter. If you're installing satellite resource assemblies with the same name but different cultures, fusion will install the assemblies into the Global Assembly Cache correctly. But if you're performing an administrative installation those resource assemblies cannot resolve to the same directory. Think of administrative installations as unzipping an archive. They are typically little more than that. In this case, consider authoring destination directories such that each satellite resource assembly installs into a sub-directory using the appropriate culture name.

To fix the reporting tool issues in 64-bit flavors of the .NET Framework 2.0 installation, download the attached archive, extract the transform, and use the transform during both the administrative installation and the client installation as shown below.

> copy /y dwfix.mst \\SERVER\SHARE
> NetFx64.exe /c:"msiexec /a netfx.msi TARGETDIR=""\\SERVER\SHARE"" TRANSFORMS=""\\SERVER\SHARE\dwfix.mst"""
> msiexec /i \\SERVER\SHARE\netfx.msi /l*v install.log TRANSFORMS="\\SERVER\SHARE\dwfix.mst"

Attachment: http://hstewart.members.winisp.net/downloads/dwfix.zip
Leave a Comment
  • Please add 5 and 5 and type the answer here:
  • Post
  • > during administrative installations some
    > 64-bit files overwrote some 32-bit files and
    > I provided a transform to fix the issue. I
    > filed a bug and the issue was fixed before
    > .NET 2.0 shipped.

    Thank you for getting that fixed.

    > Later in the release cycle the Office Crash
    > Reporting Tool, otherwise known as the
    > Microsoft Application Error Reporting tool
    > or "Dr. Watson", was merged into the .NET 2.0

    Do you know when that will be fixed?  Or more precisely, when releases to customers will get fixed?  I've been lucky a few times, the 64-bit installer put Dr. Watson stuff on a partition that didn't have a different Windows installation on it (32-bit or otherwise) so it didn't overwrite anything.  But I'm not sure if I've been lucky always.  It would really be better if installers would install their products onto the correct partitions.
  • Norman, there's nothing we can do to fix this problem after it has shipped, which is why I'm providing this transform.

    This problem has nothing to do with partitions, however, but how files are extracted and ultimately installed into either "Program Files (x86)" or "Program Files" on a 64-bit platform. The msidbComponentAttributes64bit component attribute helps the installer identify the right location for the files. This isn't forced based on the processor support for the binary because you might want to install, for example, 64-bit binaries into a 32-bit location on the file system (like for cross-compiler libraries).

    For more information about file system redirection and how it relates to Windows Installer, search my blog for "x64".
  • > Norman, there's nothing we can do to fix
    > this problem after it has shipped

    Microsoft has to continue delivering through Windows Update the known bug with its known destructive consequences?  Microsoft can't fix the version that it delivers through people who download it from Windows Update after, say, next week?  (And why not, say, one week after Microsoft knew about the bug, which was before I knew about the bug.)

    Microsoft can't even put a warning in its Windows Update script to warn users that they might want to delete this selection from their list of Windows Update downloads because it has a known bug with known destructive consequences?  And Microsoft couldn't do this, say, a day after Microsoft knew about the bug, which was before I knew about it?

    Do you need to be told _how_ Microsoft customers discover bugs like this?  This shouldn't be the way.  When Microsoft knows about bugs, customers deserve to be warned before getting screwed by them.

    > which is why I'm providing this transform.

    I see.  Roughly the first 10 paragraphs of your message (depending on what counts as a paragraph) seemed to concern the 64-bit vs. 32-bit issue which you said you'd fixed.  Now I see that roughly the 11th paragraph perhaps helps fix this known bug.  So instead of downloading .Net Framework 2 from Windows Update, I need to learn how to make an Administrative Installation for it.  OK, this is a help.  But still, please think about the questions I asked above.
  • Norman, installing the .NET Framework works just fine. It's only when you actually attempt to do an administrative installation where this problem occurs. This is not a common situation and the vast majority of our users are unaffected.

    Simply put, we cannot ship an MSI that is different from what's already been shipped. That would introduce variants that might prevent patching. This actually happened with .NET 1.0 on older Dell machines and forced us into supporting two different variants from our older patch wrapper by modifying the transforms within the patches for .NET 1.0.

    Recalls are also very expensive to everyone, not just Microsoft.

    You don't need to learn to make an administrative installation at all unless you actually need to deploy an administrative installation to client machines.

    BTW, customers didn't discover this bug. It was discovered internally not long ago, so you can see that customers apparently haven't run into this situation: pushing out 64-bit administrative installations to clients.

    So, the reason this blog post isn't just about the transform I created is because this is a warning to others to help avoid the same situations in your product, which likely would affect how your patches are created (especially if you're using delta patching, where only differences in binaries are patched).
  • > installing the .NET Framework works just
    > fine.

    That is not true.  This was already discussed in one of the public newsgroups hosted on Microsoft's news server and a Microsoft employee already stated that it is a known bug.

    The first time I got hit by it, the actual bug was not immediately believable (though Microsoft obviously already knew about it), but the effects were immediately visible.  I had Windows XP x64 installed on partition D.  Partition E was freshly formatted and empty.  In a Windows Update session, I selected to download and install several updates including .Net Framework 2.  Afterwards, partition E had Dr. Watson stuff on it.

    Had Windows XP 32-bit been previously installed on partition E, it would have been overwritten by the 64-bit stuff.  (Does this bug description look familiar at the moment?)  Had Windows XP 64-bit but a different language version been installed on partition E, I wonder if the result would be usable.

    E was freshly formatted because I had finished experimenting with a beta of Vista.  Suppose I hadn't finished experimenting with that beta, or suppose someone does a Windows Update for Windows XP after Vista is released.
  • P.S.

    > Recalls are also very expensive to everyone,
    > not just Microsoft.

    Yup, too true.  Refusing to do a recall when necessary is not expensive.  A court decision in this morning's newspaper even proved it.  Mitsubishi Motors refused to do a recall on some of their trucks, choosing instead to cover up their defect.  So when a wheel flew off a truck and killed someone, they saved a ton of money.  The court ruled that Mitsubishi Motors only had to pay the victim's family (including young children) about 5 million yen.  Doing a recall would have been more expensive by orders of magnitude.

    Yup, Microsoft's bean counters understand the rules.  Damage users' files on other partitions, so what.  Do not do a recall.
  • Norman, these are error reporting tools and not critical to the operation of .NET tools and applications built on .NET.

    We are working to make sure this doesn't happen in the future. I am also testing an idea that might be able to fix what has already shipped.
  • > these are error reporting tools and not
    > critical to the operation of .NET tools and
    > applications built on .NET.

    Sounds like all the more reason why this particular part of the .Net Framework 2 download should not automatically be selected by Windows Update, and why Windows Update should display a warning to the user that installation of this component is not recommended because it can damage other partitions.

    > We are working to make sure this doesn't
    > happen in the future. I am also testing an
    > idea that might be able to fix what has
    > already shipped.

    Thank you and thank you.  Meanwhile, until the downloadable version gets fixed, Windows Update still needs adjustments in order to avoid causing damage to further customers.  Windows Update is still in operation because there might be customers who will download this stuff tomorrow, right?  And the day after.  After your idea is implemented and shown to work, then it will be reasonable for Windows Update to resume delivery of this component.
  • Previously I had only seen the 64-bit version of .Net Framework 2 installation install its Dr. Watson stuff on an inappropriate partition, possibly overwriting a 32-bit installation.  I have only seen your colleague admit that this bug is known in the 64-bit version.

    A few days ago I saw the 32-bit version do the same thing.  Some Dr. Watson stuff was on a partition that didn't belong to the 32-bit Windows and .Net Framework 2 installation.
  • If I am redistributing DotNet 2.0 (because it is required by SQL 2005 Express) is this something I need to be concerned about? Do I need to download the transform and rewrite the third party's prerequisite installer to handle this situation?
  • Daniel, you do not because this only affects administrative installations and you would be doing just a simple installation. Administrative installations using Windows Installer is like a glorified unzipping process.

Page 1 of 1 (11 items)