I get to go make my first trip to Japan tomorrow, I'm going to be presenting a couple of talks at Asia DevCon 2004.  The talks I am giving were first presented at the US DevCon at the end of June, and I've modified them with some updated content and slightly different demos.  For those who are interested, I'm presenting the following talks:

• Everything you wanted to know about Enhanced Write Filter (EWF) but were afraid to ask (I didn't name it....) - I'll go over the reasons why you would want to use EWF in your embedded image, then talk about how to setup and configure RAM, disk and RAM registry overlays.  I'll finish up by giving an overview of some of the EWF changes that are coming up in XPE SP2 later this year
• EEFs: Unplugged (didn't name this one either but at least it is shorter) - I'm going to talk about a couple more advanced Embedded Enabling Feature (EEF) concepts - how to overcome the limitation in EWF that requires you to protect the entire volume by implementing a registry filter service so that some registry values can be updated on the EWF protected volume; and how to create and SDI file and boot Windows Embedded from RAM.

There is a little more detail about the talks at the site for the US DevCon at http://www.windowsembeddeddevcon.com/tech_content.asp.

I'm also going to be meeting with some customers with a few other members of my team and our Japanese counterparts while I'm in Tokyo.  I'm looking forward to getting to see how some of our features are being used in the real world and some of the limitations that we need to look at addressing in the future.  I'm also hoping to brainstorm some ideas for better tools, new white papers, and more effective testing processes we can incorporate on our team so that the features we end up shipping will better meet all of our customers' expectations.  Oh yeah, and maybe I'll get be able to bring back some sample hardware so that our team can test XP Embedded and Longhorn Embedded on additional types of devices  :-)

I wanted to provide a link I found today for a KB article that lists the fixes included in the .NET Framework 1.1 SP1 package, you can find it at http://support.microsoft.com/?kbid=867460.  This article has a pretty good list of individual issues that have been fixed in SP1.  It does not appear to be 100% comprehensive however.

For example, I know that the issue described at http://support.microsoft.com/default.aspx?scid=kb;en-us;827072 has been fixed in 1.1 SP1 (the ASPNET user account no longer causes the XP welcome screen to appear after installing .NET Framework 1.1 SP1 if there is only a single user account on the machine).  This particular issue has been mentioned a couple of times in the newsgroups, and it was actually a bug that the account was not installed with the bit set to mark it as a hidden/system account.  This account is used to run ASP.NET worker processes on the machine that serves up ASP.NET pages.

Anyway, I hope this helps....

Yesterday, I wrote about some of the problems encountered so far with the .NET Framework 1.0 SP3 and 1.1 SP1 in an article here.  I was talking to one of the developers who worked on these service pack setups, and he suggested a couple additional workarounds for cases where someone encounters the TargetInvocation exception:

1. Repair .NET Framework 1.0 or 1.1 (depending on what version you are trying to install the service pack for) and then try applying the service pack again.  To perform a repair, you can follow the steps in %windir%\Microsoft.NET\Framework\v1.0.3705\repair.htm or %windir%\Microsoft.NET\Framework\v1.1.4322\1033\repairRedist.htm.
2. Clear the Windows Update temporary downloads cache.  See http://support.microsoft.com/?kbid=193385 for more information about how to do this.  You may also need to delete the contents of %windir%\SoftwareDistribution\Download in addition to the steps listed in the KB article.

Hope this helps....

<update date="10/27/2005"> The link in item 2 above is broken because the KB article was unpublished; updated with a new link and an additional step </update>

I have been talking to some folks inside of Microsoft, looking at a few failures that have been reported internally and externally and read some newsgroup posts and it appears that there are 3 major points where setup has been failing for the .NET Framework 1.0 SP3 and 1.1 SP1:

• Installing the SP hangs and has to be killed because it never completes successfully
• Installing the SP triggers a repair that asks for the source location of netfx.msi
• Setup throws a TargetInvocationException almost immediately after launching the installer

I wanted to talk about each of these in a little more detail....

Installing the SP hangs

In nearly all of the cases where SP setup hangs (such as the case described at http://www.gotdotnet.com/community/messageboard/Thread.aspx?id=260442) the underlying problem is that one of the IIS services fails to respond when setup tries to stop it.  This should only happen on platforms that support ASP.NET (Windows 2000 and higher) and that have IIS installed, configured and started at the time setup is run.  When the .NET Framework detects that IIS exists and is started, it attempts to stop the IIS Admin service in order to update ASP.NET configuration settings.  .NET Framework setup uses a custom action to stop and start this service (because we want to only start the service at the end of setup if it was running prior to setup), but within that custom action it uses a standard Win32 API (ControlService).  In most cases, opening a cmd prompt and running sc query iisadmin or sc query w3svc will show that one of these services is in the "stopping" state.

So far, the instances I've seen this behavior has been mostly on Windows XP with SP2 (and also one or 2 cases on Windows 2000 with SP4).  I haven't been able to figure out any specific root causes for this unfortunately.  The workaround that I have been recommending is to kill the service pack setup, manually stop the IISAdmin service by using the Services control panel (run services.msc from a cmd prompt) or by running net stop iisadmin from a cmd prompt, and then running the service pack setup again.

Installing the SP triggers a repair

This is probably the most common issue I've heard of from customers who have had issues installing a .NET Framework service pack.  The underlying cause for this is that Windows Installer has determined that one or more components in the version of the .NET Framework being patched is broken and needs to be repaired before installing the patch.  I've talked a little bit in a previous blog entry about how Windows Installer's resiliency feature works, and the workaround for this issue is straightforward, though a bit painful:

• Locate the original install package named dotnetfx.exe or re-download it - make sure that you download the version that matches the one you are trying to apply the service pack for
• Open a cmd prompt and run dotnetfx.exe /t:c:\temp /c (or some other path of your choosing other than c:\temp)
• Re-run the service pack setup and when prompted for the source location of netfx.msi, browse to the folder c:\temp that you used in the previous step to extract the contents of dotnetfx.exe

Now - the thing that is more interesting to me here is trying to figure out a root cause (or more likely, different classes of root causes).  When diagnosing why the .NET Framework fails the resiliency check and triggers a repair, I usually look at the application event log on the computer by running eventvwr.exe from a cmd prompt.  From there I look for log entries where the source name is MsiInstaller.  Resiliency repairs usually create pairs of warnings in the application event log that contain GUIDs for the component that triggered the resiliency check, and the component that failed the check and requests the repair.  Generally, I can take that information from the event log and cross-reference it against the MSI data in Orca (ctrl+c in event viewer, ctrl+f in Orca, ctrl+v in the Orca find dialog and away we go)

I have been playing around with some of the event log Win32 APIs to try to write a little app that would mine this data to make it easier for us to gather data from customers who are hitting this.  So far I have figured out how to create a copy of the application event log and zip it to send in email.  I also figured out how to parse the application event log and find all of the entries where the source is MsiInstaller.  The thing I've been having trouble with is converting the warnings into readable strings.  The warnings are strings loaded from msi.dll that have tokens (%1, %2, etc) to replace, and I haven't figured out yet how to pull the tokens out of the event log entry and plug them into the string I load from msi.dll.  So if anyone has any pointers or sample code for manipulating event logs, I'd appreciate it....

TargetInvocationException

This error is something new with this round of service packs (1.0 SP3 and 1.1 SP1).  The wrapper EXE for the .NET Framework service packs is new compared to 1.0 SP2, and it is written in managed code this time around.  Because of that, if there is something broken in the version of the .NET Framework on the machine, it may fail.  From what I have heard so far, a major cause of this error is applying a previous service pack or QFE for the .NET Framework and then attempting to install 1.0 SP3 / 1.1 SP1 without a reboot in between (because the previous SP or QFE may need to update in-use assemblies and be unable to do so without a reboot).  So, the first thing to try to workaround this issue is to reboot and re-run the service pack.

If the reboot does not help, it may help to examine the log file from the service pack wrapper setup.  The wrapper creates a log file in the %temp% directory named netfxsl.log.  In many cases, the exception occurs before any useful data can be written to the log, but it is good to check just in case.  In addition, if you run the wrapper with the switch /l:logfile it will generate a log in the location you specify - but this will not happen if the exception is thrown while the setup package is being extracted.  I have not yet encountered a machine that is failing with this error, so I don't know what level of detail is provided by this log file.  If anyone gets a chance to try this out, please send me a mail and attach the log file so I could take a look.

As a workaround, I suggest trying to manually extract the setup package on a different machine by running the package with the /Xp:<path>.  This will extract the Windows Installer patch package (named *.msp) to the path you specify.  Then you can copy that MSP file to the machine where you are seeing the failure and right-click on it and try to install it directly.  There will likely be some later failure, but hopefully the error is more easily understandable and diagnosable when that happens.  Again, if anyone has a machine in a failing state that they try this on, I would like to know the results.

I'll post more as we learn more about other points of failure, additional workarounds and diagnoistic tools, etc....

Steven Bone wrote up a really good list of his top 20 pet peeves about setup that can be found at http://bonemanblog.blogspot.com/2004/09/top-20-installation-pet-peeves-and-how.html.  This list got me thinking and I'm going to see what I can come up with for pet peeves that I have that aren't already covered on his list (it is pretty comprehensive though so finding things that aren't already covered is going to be a bit tricky).  I encourage everyone interested in setup technologies to read his list and post comments for him (and the rest of us) to read

Hey all,

In response to some suggestions from folks who read my blog posts describing how to detect the presence of .NET Framework 1.0 service packs and .NET Framework 1.1 service packs, I wrote up a quick sample application that shows how to implement the detection methods I recommended.  You can download the sample code here.

In this sample, I detect the presence of the .NET Framework core packages for 1.0 and 1.1, and then if I find that they are installed, I detect the service pack level also.  The sample simply pops up a message box for each version, but could be easily updated to perform some conditional action (as part of a 3rd party setup or something like that).

The code is provided as an example only....I hope it will help better explain how to implement a detection strategy for the .NET Framework and its service packs that will continue to work when future service packs are released.  Let me know if you have any problems or questions.....

<update date="6/4/2010"> Fixed broken link to the sample code. </update>

I posted information here earlier today about how to detect which service pack is installed for the .NET Framework 1.1 (and will also be able to be used for future versions of the .NET Framework).  Since then I've done some additional research to figure out what registry key/value pair can be used to detect the service pack level for the .NET Framework 1.0 so that the instructions on this KB article will not need to be used (since it is more difficult to perform programatically and the detection has to be updated with each future service pack that Microsoft releases).  Here are the registry keys/values that can be used:

For the MSI version of the .NET Framework 1.0:

• Key Name: HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\{78705f0d-e8db-4b2d-8193-982bdda15ecd}
• Value: Version
• Data type: REG_SZ

For the OCM version of the .NET Framework 1.0 (ships on Tablet PC, Media Center and XP Embedded only):

• Key Name: HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\{FDC11A6F-17D1-48f9-9EA3-9051954BAA24}
• Value: Version
• Data type: REG_SZ

For both of the above registry values, the data will be of the form 1,0,3705,x.  The "x" in this data represents the service pack level.  If you retrieve the registry value data and then parse off the number after the last comma, that will give you the SP level for the .NET Framework 1.0.

I'm going to try find time tonight or tomorrow to create a code snippet that will show how to detect whether or not the .NET Framework 1.0 or 1.1 is installed, and if so, which SP (if any) is installed.  Stay tuned.....

I have seen a few questions on the newsgroups about how to determine whether or not the .NET Framework 1.1 SP1 is installed on your machine.  A colleague pointed me to a KB article that describes a method of looking at file versions to determine this.  We created a new registry hive that started getting installed in the .NET Framework 1.1 specifically to address this and a few other types of detection issues and make this simpler for 3rd party developers, so I wanted to quickly outline how to check for this in the .NET Framework 1.1 and new versions moving forward (it will take a bit for my request to have that KB article updated to go into effect on the live KB site).

Basically you need to query for the existence of a registry value and then check the data in that value.  Here is where it is located:

• Key Name: HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322
• Value: SP
• Data type: REG_DWORD

The data in this SP value tells you which service pack is installed for the .NET Framework 1.1.  For future versions of the .NET Framework, you will just need to change the part of the key named v1.1.4322 to be the version you are interested in.

Note that this method cannot be used to tell you whether or not you have any QFE's or GDR's installed for the .NET Framework.  If anyone out there needs to be able to detect on this granular of a level, let me know via a comment or email and I can dig into this further.

There are also other alternative ways of detecting the presence of the .NET Framework 1.0 service packs, I will post something about that when I figure out the exact details of how to do that.

Hope this helps....

Hey all,

The most recent service packs for the .NET Framework - 1.0 SP3 and 1.1 SP1 - were released at the beginning of September and it looks like they are showing up on Windows Update now.  I wanted to provide the direct links to the service packs in case you want to download it without using WU -

• .NET Framework 1.1 SP1 (MSI version)
  http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=a8f5654f-088e-40b2-bbdb-a83353618b38
• .NET Framework 1.1 SP1 (OCM version for Windows Server 2003 only)
  http://www.microsoft.com/downloads/details.aspx?familyid=AE7EDEF7-2CB7-4864-8623-A1038563DF23&displaylang=en
• .NET Framework 1.0 SP3
  http://www.microsoft.com/downloads/details.aspx?FamilyId=6978D761-4A92-4106-A9BC-83E78D4ABC5B

I will post some troubleshooting tips if installing these service packs fails for some reason in a separate article either later tonight or tomorrow, plus I want to write up a brief set of guidelines for detection and deployment of these SP's.

In the meantime, I have also been talking to some folks inside and outside of Microsoft who have had trouble getting one or both of these installed, plus I've scanned a few of the longer newsgroup threads about installation problems.  It seems that the overall failure rate for installing these service packs is much higher than for the original 1.0 or 1.1 packages or for 1.1 SP1/SP2, and I'm trying to help figure out why.  If anyone out there has experienced errors installing one or the other of .NET Framework 1.0 SP3 or 1.1 SP1 please let me know.  It would help a lot if you can include any/all of the following:

1. What SP did you try to install and on what OS?
2. What was the error you encountered?
3. Have you resolved the error yet?  If so, is there any information out on the web that you found helpful?

Thanks in advance!

One of the Windows Embedded partners - Sygate  - put out a press release today with details about a suite of security protection and monitoring tools that have been specifically optimized to install and run on Windows XP Embedded.  Check it out at http://www.sygate.com/news/xp-embedded-endpoint-security_rls.htm

Hey all, I posted an article earlier this week describing how to create a custom security template to configure user accounts to not have expiring passwords.  I got a comment on that article indicating that there is an easier way to do this in certain situations.  The net.exe tool has a command line you can use to set this for you.  Here are the steps you would need to follow to get this to work for XP Embedded:

1. Include the Net.exe Utility in your image in Target Designer
2. Create a component with a single generic command (or just add a new generic command to the Extra Resources section of your image)
3. Configure the generic command to run net accounts /maxpwage:unlimited

Thanks to Alexander Suhovey for the heads up on this one!

Thanks to a heads up from someone who read my previous post about msizap.exe, I am happy to be able to point to a download location where you can get msizap.exe (along with a GUI-based front end to make it easier to use) from a Microsoft KB article - http://support.microsoft.com/default.aspx?scid=kb;en-us;290301.  This package contains an MSI that installs the tool, but it works correctly if you just extract the msizap.exe file and optionally the msicuu.exe UI wrapper.  Note that the setup package is branded for Microsoft Office, but it is a generic Windows Installer tool that will work correctly for any MSI-based product.

Hope this helps (it definitely helps me - thanks to Martin Hueser for the heads up!)

Hey all,

I received an email this morning asking about how to manually uninstall the .NET Framework (due to some issues that happened after installing Windows XP SP2 - this is another issue that I'll tackle in a future blog after I do some more investigation to figure out why we're seeing so many problems installing .NET Framework service packs after installing XPSP2, so stay tuned for that).  There are a couple of KB articles that describe manual removal techniques:

• http://support.microsoft.com/default.aspx?scid=kb;en-us;320112
• http://support.microsoft.com/default.aspx?scid=kb;en-us;824643

Unfortunately, those articles reference a tool called msizap.exe that ships as part of the Windows Installer SDK.  Due to numerous functional and design issues with the Platform SDK installer, it is way more pain than it should be to install, not to mention that you have to install hundreds of megs of stuff to your machine even if you want only one tool that is shipped with it like msizap.  The person who emailed me with this problem found a location to download just the msizap tool.  I can't officially endorse it because it is on a 3rd party company's site, and I can't be sure which version they have on their server, etc.  But it appears to have worked fine in the cases that I tried, so if you are in need and have a slow network connection and can't take the time to download all the Platform SDK stuff, you can find it here.

Hope this helps....

Hey all, I have seen this question internally a few times - how can I configure a user account that I add to my XP Embedded image to have a non-expiring password?  This topic has been added to the XP Embedded SP2 documentation, but in the meantime I thought I would go ahead and post the information here for anyone who needs it in the meantime:

_____________________________________________________________________________________________________________________

By default, when you add user accounts to your image, the user is prompted to change the password 15 days before it will expire. In some types of deployments, it is not feasible or desirable for end-users to change passwords.  You can create a custom security template that turns off password expiration and add it to your image so that it runs during First Boot Agent.

Note   Weak passwords are a potential security vulnerability and can allow hackers access to your system. It is always advised to configure all user accounts with strong passwords.

To remove password expiration from User Accounts

1. Create a custom security template. For more information, see Creating a Custom Security Template Using the MMC Snap-in.
2. In the MMC main window, under the new security template node, expand the Account Policies node.
3. Expand the Password Policy node.
4. In the right pane, right-click Maximum Password Age Policy.
5. Select the Define this policy setting in the template checkbox.
6. Set Password will not expire to 0 days.
7. Click OK and save the template.
8. Create a component for this security template and add it to your image, by following the steps to Create a Component for a Custom Security Template and to Include a Custom Security Template in your Runtime Image

_____________________________________________________________________________________________________________________

Hey all, I found a really good set of instructions about what settings to configure in order to get remote debugging using Visual Studio .NET 2002 or 2003 working again once you install Windows XP SP2 (XPSP2 has a lot of new security features that make computer-to-computer communications more difficult).  The best part about these instructions is that they're written by a developer on the Visual Studio debugger team (Gregg Miskelly) who has been through the pain of setting this up many times.  Also, I worked with Gregg prior to Embedded DevCon to figure out how to get the managed side of the remote debugger working on XP Embedded SP2.  Anyway, check it out at this blog article.