The .NET Framework 3.5 can fail to install on a system where MSXML is not properly registered. There is a custom action that runs during .NET Framework 3.5 setup that tries to use some APIs in MSXML to modify some information in the web_mediumtrust.config file that is a part of the .NET Framework 2.0. In the cases that we've seen of this issue so far, one of the MSXML CLSID values was somehow unregistered on the system, and that causes this custom action to fail.

How to diagnose this issue from the .NET Framework 3.5 setup log file

This issue will cause the following information to be written to the verbose MSI log file for the .NET Framework 3.5 component (named %temp%\dd_net_framework35_MSI*.txt):

You can use one of the following options to work around this issue if you encounter it during .NET Framework 3.5 setup. Note that these workarounds are only useful for this exact error and HRESULT value. They will not help fix all possible .NET Framework 3.5 setup failures.

In the example log file above, the HRESULT value is 0x80040154, which means that a class is not registered. On systems where we have seen this error, the root MSXML CLSID is listed in the registry at the following location:

Hi Jossy81 - I'm not sure if your error has the same root cause as this .NET Framework error. Can you please use the tool described at http://blogs.msdn.com/astebner/archive/2007/11/21/6458047.aspx to gather your VS 2008 setup log files, post the logs to a file server (such as http://skydrive.live.com) and then reply here with a link I can use to download the log files so I can take a look and see if I can figure anything out about the cause of this error?

The error code is different than the one described above in this blog post, so I’m not surprised that the workaround listed here didn’t work in this case. This error code 0x8007006e means “The system cannot open the device or file specified.” Can you check and see if this file exists on your system, and if so, if there are any settings on it that would prevent it from being opened (for example – is it marked as compressed or encrypted or something like that?)

Hi Paul - Error 1603 just means that setup failed, and there are many possible causes for that. This blog post describes only one of the possible causes. In order to diagnose this further, we'll need to look at your log files and see what the exact root cause of the failure is. Can you please use the tool described at blogs.msdn.com/.../6458047.aspx to gather all of your log files, then post the file named %temp%\vslogs.cab that this tool creates to a file server (such as http://skydrive.live.com), then reply back here with a link I can use to download your logs and take a further look?

Hi Rawaa - Can you please use the tool described at blogs.msdn.com/.../6458047.aspx to gather all of your .NET Framework setup log files, then post the file named %temp%\vslogs.cab that this tool creates on a file server (such as http://skydrive.live.com), then reply here and provide a link that I can use to download your log files and take a look?

Joe

13 Oct 2010 6:08 PM

Reregistering the DLL fixed this issue for me. I was spending hours trying to fix it. Looking at the logs helped find the exact error message that was preventing it from installing.

Thanks.

Chris

15 Jan 2011 2:59 AM

I followed your directions above and have posted the vslogs.cab to the following link: