Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

January, 2005

  • Aaron Stebner's WebLog

    How to submit proposals for papers for the upcoming Mobile and Embedded DevCon


    Hey all, I was browsing Mike Hall's blog (specifically this post) and noticed that there is now a site available where you can post proposals for papers that you'd like to present in the form of a talk or a lab at the upcoming MEDC (Mobile and Embedded Developers Conference) in Las Vegas.  Here's what you need to do:

    1. Visit the MEDC Call For Papers site
    2. Read and agree to the terms and conditions
    3. Submit an idea!

    I presented at MEDCs in San Diego and Tokyo last year and learned a tremendous amount while I was preparing my talks and also by talking face-to-face with embedded developers and system builders, so I definitely encourage you to consider submitting something.....


  • Aaron Stebner's WebLog

    Registry key to force Windows to use short filenames


    I thought this was interesting - there is a way that you can globally force Windows to use short filenames (also known as 8.3 filenames because they were limited to 8 characters for the name and 3 characters for the extension) or alternatively allow Windows to use long filenames that are not bound to the 8.3 naming restrictions.  This is the key name and value:

    • Key name: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem
    • Value name: Win31FileSystem
    • Data type: REG_DWORD

    Setting this value to 0 will allow Windows to use long filenames.  Setting this value to 1 will force Windows to use short filenames.

    When you use the SHORTFILENAMES property in Windows Installer, that is the equivalent of forcing 8.3 filenames but only for a single MSI installation.  This registry key controls 8.3 file naming for the entire system, and I have seen this be the cause of 1325 errors ('[2]' is not a valid short file name) when installing MSI packages in some rare cases.

    Some setup authors do not pay attention to the setting in the file table for the short file name value and inadvertantly provide a short file name that is greater than 8 characters long.  Then when someone tries to install that MSI on a system that has the Win31FileSystem value = 1 or the SHORTFILENAMES property set, they get a 1325 error.  For example, you will see this if you try to install Visual Studio .NET 2003 on a machine that has this registry value set because we did not pay enough attention to the short file name values we provided in the MSI.  One of the files has a short file name value of "Microsoft" which has 9 characters instead of 8.


  • Aaron Stebner's WebLog

    New white paper now available - installing XP Embedded SP2


    There is a new white paper that has just been published.  It provides an overview of reasons why you would want to update to SP2, some considerations to think about before updating, the process of updating, and an FAQ and troubleshooting guide for installation issues.  You can find the white paper by clicking here.

    This is a really good document to read so that you can carefully consider some of the branching decisions for runtimes you want to build.  For example, if you are currently building and maintaining XP Embedded RTM or SP1 runtimes and you want to update your database to SP2, you will need to maintain a separate database if you want/need to continue providing updates to your SP1 runtimes without also updating them to SP2.


  • Aaron Stebner's WebLog

    Mobile and Embedded DevCon 2005 - May 9-12 in Las Vegas!!


    Hey all, the 2005 edition of the Mobile & Embedded Developers Conference (MEDC) has been announced.  This year it is going to be in Las Vegas, a quiet little town in southern Nevada from what I hear.  I had the opportunity to attend last year's DevCon in San Diego and had a great time presenting session and lab content, but most of all I enjoyed getting the chance to meet people trying to use Windows XP Embedded in their products.  We have released XP Embedded SP2 since the last DevCon, so I am anxious to hear how it has helped make embedded development easier and where it is still lacking.  If anyone has any suggestions for session or lab topics that they would like to see this year at DevCon please let me know and I will make sure to pass them on to the organizers here at Microsoft.


  • Aaron Stebner's WebLog

    Windows Installer, the Class table, and resiliency repair dialogs


    A while back I wrote an article about Windows Installer and the resiliency feature.  Anyone who has seen a small dialog appear saying "Configuring XXX....please wait" has seen resiliency in action.  I wanted to talk in more detail about a specific type of problem I have seen that ends up inadvertantly triggering resiliency repairs at very random times.

    According to the help documentation for Windows Installer, the Class table contains COM server-related information that must be generated as a part of the product advertisement. Each row may generate a set of registry keys and values. The associated ProgId information is included in this table.

    In practice, what happens during setup is that for each entry in the Class table, a set of registry data is created under HKEY_CLASSES_ROOT\CLSID\{GUID} for the COM object in question.  The {GUID} in this case is the value of the CLSID column of each row in the Class table of the MSI.  This registry data allows the COM object to be instantiated on this machine by applications or custom script code later on.

    There is also some additional data that advertises this COM object and associates it to any MSI that includes it in the Class table.  If you look under the InprocServer32 subkey, you will see a REG_MULTI_SZ value that is also named InprocServer32.  This collection of strings represents an encoded list of features that are associated with this COM object.  Whenever an instance of this COM object is instantiated (with CoCreateInstance or WScript.CreateObject for example), Windows Installer recognizes that this COM object is advertised and proceeds to perform a feature health check for each of the features listed in the REG_MULTI_SZ value named InprocServer32 for this COM object.  If this feature health check returns false for any reason, then you will see a small Windows Installer dialog and a resiliency repair, even if the information needed for this COM object is functioning perfectly fine.

    I have run into this problem numerous times while debugging resiliency repairs that have popped up for internal users who installed daily builds of Visual Studio 2005.  Using the debugging techniques in my previous blog article and also here have led me to components in Visual Studio that were being reported as broken.  I had been meaning to write about this for a while, but it got put back in the forefront of my mind yesterday while I helped someone on the Visual Studio team figure out why they were seeing a repair dialog appear when they tried to build a setup/deployment project in the Visual Studio IDE.  In this case, building a setup/deployment project was calling CoCreate on the MSM.Merge object exposed by mergemod.dll, and since this COM object was installed via the Class table of the Visual Studio MSI, it was advertised and a health check was triggered.  The health check happened to fail due to a known bug in the VS MSI that is scheduled to be fixed soon.

    This isn't that big of a deal for daily development work because there are experts within Microsoft that can look at the problem and also because the resiliency repair is exposing valid bugs (in several previous cases they were bugs in fusion related to new assembly attributes that were being treated as invalid because they were not recognized, see this blog item for more details if you're interested).

    However, it becomes a big deal for end users who are trying to install and use shipped products and encountering repair dialogs for unknown reasons - and worse yet are being asked to insert a CD or browse to an inaccessible network location so that Windows Installer can access source files to try to repair them.  In some products, especially large products such as Visual Studio, the feature that ends up being advertised in the registry by the Class table contains many components.  A resiliency repair will be triggered even if some component that is completely unrelated to the functionality of the COM object being instantiated fails the Windows Installer health check.

    Fortunately there is a way to avoid this issue for setup authors.  I recommend using the standard MSI registry, file and component tables to install and register COM objects instead of using the Class table (and the companion ProgId table).


  • Aaron Stebner's WebLog

    Info about the 1935 error with HRESULT 0x80131532


    A little while back I posted a blog entry about some common 1935 errors that might happen during an MSI installation.  Since then, I have gotten a few questions about different types of 1935 errors that have HRESULTs not listed in my previous post.


    I wanted to talk about one specific interesting type of error.  The HRESULT for this error is 0x80131532, and the corresponding error code in the header file means COR_E_MISSINGMANIFESTRESOURCE.


    This error has a couple of possible causes.  Both of the causes I have encountered so far are rooted in errors during setup creation.


    Case 1 – incorrect file entry in the MsiAssembly table


    In the case of the customer that reported this HRESULT to me, the MSI was authored with an invalid file value in the File_Manifest column of the MsiAssembly table for one or more assemblies that are listed to be installed.  The fix is to make sure that the File_Manifest values for all assemblies in the MsiAssembly table refer to file entries that exist in the File table of the MSI.  The interesting thing (in a bad way) is that the customer who hit this problem reported that ICE validation suites did not catch this problem.  I haven’t had a chance yet to look into why ICEs would miss this because it seems like a relatively simple thing to validate.


    Case 2 – invalid assembly attributes in the MsiAssemblyName table


    The other cause that I have seen so far is specific to the .NET Framework 2.0 beta 1.  In this scenario a .NET assembly is authored with invalid attribute pairs in the MsiAssemblyName table of the MSI.  


    In the .NET Framework 2.0 beta 1, if in valid attribute pairs are found in the MsiAssemblyName table, installation fails with a 1935 error.  In the .NET Framework 2.0 beta 2 and later, this will be reverted back to the behavior seen in .NET Framework 1.0 and 1.1 - unknown assembly identity attributes will be ignored and not cause errors or failures.


    The following blog entry and bug report describe this instance of the problem in more detail.



  • Aaron Stebner's WebLog

    Why not try Windows XP Embedded?


    Hey all, Mike Hall wrote up a really good article while I was out on vacation listing some of the common reasons we have heard from customers about why they did not want to consider using Windows CE and/or Windows XP Embedded.  It is a really good read if you have any doubts or questions about specific features or supported scenarios for either or these OSs.  Take a look at it by clicking here.


Page 1 of 1 (7 items)