Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
I am going to keep track of ideas for future blog posts with this blog article. I'll add my own ideas as they come to me, and I also welcome suggestions from anyone out there who would like to suggest a topic. I am going to use the following guidelines:
Hi Lavoe1 - There are some suggestions for TV Tuner installation/configuration errors in the links at http://blogs.msdn.com/astebner/articles/487537.aspx.
If none of those help, then I'd suggest posting a question on one of the following forums to see if someone there can suggest some additional options for you:
Hopefully one of these helps.
I followed your process for removing .NET Framework 1.1, using your removal tool and reloading it, along with the updates. It still crashes after I have browsed through movie titles for a while. I always get the same error:
Application has generated an exception that could not be handled
Process id=0x10d0 (4304), Thread id=0x1434 (5172)
Hi Pmb72 - There might be more detailed information about the cause of this crash in the file named c:\windows\ehome\ehshell.crash and/or in the event logs on the system. I'd suggest looking there to see if there is any helpful information.
It might also help to post a question at one of the following locations to see if anyone there can help suggest any additional workarounds for you:
Hi, I was wondering if you could update the .NET 3.5 installation guide to include .NET 3.5 SP1. I have tried to follow a similar process to create the administrative share, but with 3.5 SP1 it fails to install.
Hi Mushimushi - Thank you for the suggestion. There are steps to create an administrative install point for the .NET Framework 3.5 at http://msdn2.microsoft.com/library/cc160717.aspx, and the steps should be nearly identical for the .NET Framework 3.5 SP1.
Could you provide more detail about your scenario? What steps were you using when you tried to create your administrative install point, and what error did you see during installation?
I have 2 people that I am helping attempt to install ".NET Framework 3.5 Family Update (KB951847)" which is being presented by Windows Update. I have removed all instances of .Net and reinstalled all and still the update won't install. The two errors I've seen are 0x80070643 and 0x80070645.
I know that this is a blog and not a forum. I thought that if you have heard of this problem from anyone else it may warrant an update to a current blog or a new one altogether. If these are isolated incidents then I may just have to reinstall the OS and try again (OS is XP sp3.. fyi).
Thanks for all the time and effort you put into your site. It has helped a lot of people.
Hi Nelsontrek - The 643 and 645 error codes from Windows Update are generic errors that mean that something went wrong during the installation. When that type of error happens, you typically will have to look at the verbose logs for the product that is failing to install in order to narrow down the cause. For the .NET Framework 3.5, you can find a list of setup log files at http://blogs.msdn.com/astebner/archive/2008/04/30/8445569.aspx. If you can zip and upload your files to a file server and then post a link to the server location back here, I can try to take a look and see if I can figure out what is causing the installer to fail on these systems.
If there are common root causes, I can also create a new blog post about them in the future.
Very simply, I would like to "see" my machine in action to know the bottlenecks. Maybe like one of those pictures of a "cut up" person in your doctor's office showing how a heart works or something. For the more technical, just knowing what is causing *wait* states for command execution and how long each spends in different areas: e.g. FETCH from disk ==> CPU writes *read* instruction + [address?] from hard drive; goes out to cache, memory(?), CPU<-->NB bus, NB <--> SB bus, SB <--> PCI <--> Disk Queue; sits... Command read by disk, fetch time (access + read + store to out buffer), then back, etc. Same for DDR, GPU, and so on. Show in some function of "realtime" with colors. Main point is to see where slow parts are, because I found out with a new MB that a 2GHz bus makes my disk drives seem like they are 2x as fast. So now I'm thinking that the Mobo bus system is *still* (since 8086 cpu) the slow part. You already collect this info, just animate it. Killer tool!
Shawn Harvey / email@example.com
I am looking for an option to upgrade x86 package to x64.
After deploying x86 binaries, what options do I have to upgrade these binaries to x64?
Thanks in advance,
Hi Ronith - My understanding is that this type of "upgrade" is not possible in Windows Installer. You will need to use 64-bit Windows Installer components to install your 64-bit payload, and you cannot change existing 32-bit components into 64-bit components. Typically, you will need to create separate MSIs - one for the 32-bit payload that will install on 32-bit OS's, and another for 64-bit payload and 32-bit payload that will install on 64-bit OS's. I posted a sample that shows how to create these types of MSIs using WiX 3.0 if you're interested. That post is at http://blogs.msdn.com/astebner/archive/2007/08/09/4317654.aspx.
Im working with WindwsMediaCenter SDK combined with aspx application, i'm launching external applications from aspx code using an activeX (http://www.whirlywiryweb.com/q/launchinie.asp) the problem is when the WMC is Maximized the aplications opens in background, and the wmc dont minimize maybe you have an idea how can i minimize it
I can´t use this http://blogs.msdn.com/astebner/archive/2007/01/07/mailbag-how-to-launch-an-exe-from-within-windows-media-center.aspx
because i cant register the application in all clients pc's, the rute of app is from a DB
if you like i can send my code
PD. an apology for the bad English
Hi Xhaman - I don't have a lot of expertise in this scenario. I'd suggest posting this question on the Windows Media Center development forums at http://discuss.mediacentersandbox.com. Hopefully some of the experts there will be able to help suggest some options for you to try.
Aaron, do you have any experience enabling custom actions to consume properties that are defined or set within the context of a merge module?
For example, we've been using SIDLookup (http://www.installsite.org/pages/en/msi/tips.htm#SIDLookup) in our wix msi projects to populate a bunch of properties with the friendly names of well known accounts (sids) in a localized installation. However, when we try to consume the custom action in a merge module project the property(s) that are defined by the merge module are inconsistent with the properties set by the custom action due to the merge module appending it's id to the property name at compile time. So the custom action will not work. I have to hard-code the id into the source of the custom action to force consistency of the property names so that the correct property will be populated at install time and consumed by the LockPermisions table.
The base problem that prompted this question involves trying to set folder permisissions for the USERS group in a localized installation from within the context of a merge module project.
Hi Wicampbell - I'm sorry, but I don't have experience with this type of scenario. It might help to ask about this on the WiX users group (http://wix.sourceforge.net/mailinglists.html#wix-users) and/or the Windows Installer public newsgroup to get some suggestions for how best to configure things in this type of scenario.
Number of MSIExec processes can be running during an installation. The reason for this is that Windows Installer uses a client-server model for performing installations. Additionally for security reasons, Windows Installer hosts DLL and script custom actions in a "sandbox" process.
Depending on how the install was initiated, one of the MSIExec processes can be the client process. Another MSIExec process is Windows Installer service.
Any remaining MSIExec processes are usually sandbox processes for hosting custom actions. The determination as to which MSIExec process will serve as the sandbox process for a script or DLL custom action depends in part on whether the custom action will run elevated or impersonated and whether the custom action is 32-bit or 64-bit.
IN PROCESS EXPLORERE WE SEE
msiexec.exe -Embedding <GUID> - this is the custom action server (indicated by the
what is guid here stand for component ,product or what else