Tripredacus

I found some more things you might try: http://support.microsoft.com/kb/958055 You could possibly rename or delete this: c:\9b53f85f7ed01fc7c7830c4f\amd64\mp_ambits.msi A leftover file there, Also in C:\windows\temp and %userprofile%\Local Settings\Temp, etc could have read-only files left over from other installers/programs that this update needs to overwrite and cannot. This used to be a big problem back in the Win9x days but it never hurts to empty out those folders. Some other leads: http://social.answers.microsoft.com/Forums/en-US/msestart/thread/908fad3e-f9fc-4d8a-be83-ae7d3bc48db5 These logs aren't very helpful. Neither of the MSIb8c2x logs really have any info you need to worry about. The only "error" in there is the APPCOMPAT message, but I am fairly certain that can be ignored. The CBS log doesn't seem to have any related info either. You can see the MSI logs are recording at 12:02 but the latest time on CBS is 11:59. If this wasn't done already: http://support.microsoft.com/kb/223300 we want to enable the switch /l*vx I've had problems determining why MSSE wouldn't install in the old version, and the cause of the problem was that MSSE installs with a Wrapper and isn't very friendly or responsive to troubleshooting. My problem was that MSSE wouldn't install on an x64 system that had Office installed on it. It was never resolved.

That is annoying when old links stop working. And especially when those sites aren't on the wayback machine. You'll definately be able to find some help here, as we have a large number of day-to-day Win98 users.

This XML looks like it is only used with sysprep and not install. If you are using it for sysprep you can pretty much name it anything.

You know, I remember working my first tech job and encountered this issue quite often. At that time I had actually gone about and debugged Win98 and determined a clear-cut solution to msgsrv32 errors and problems. Unfortunately, that was so long ago that I forgot it (and how to debug Win9x) But just seeing that file name for the first time in 10 years warmed by heart!

Unfortunately, as previously mentioned, we cannot help you if you are using an pirated version of Windows.

We have this topic already: And this one too:

There doesn't seem to be anything inherently wrong with that update. I see that the newest versions of FEP (Forefront) require this update, and since MSSE is the "public" version of FEP, I can see it requiring it also. However, your log file says that one of the updates it has downloaded is corrupted and cannot be opened. Therefore it can't install it either. I am not able to determine (by that log) which update that specifically is, or where it may be located.

The log file you posted was created DURING sysprep, before the image was captured. There should be another log file (in a different folder than where you found the one you posted) that will detail the system's actions during the second phase of sysprep that is done after deployment.

Well you want to try the Live CD first. If there is a problem with the hardware (ie the system not announcing the audio hardware to the OS) then a reinstall is going to be a waste of time! Definately check those BIOS settings and try a Live CD before doing a reload. What we can see here is that you likely have a hardware problem rather than an OS problem.

Ah too hasty, I'll merge these.

It may not specifically mean anything (that magic internet) but when I look up "CBS_E_INVALID_PACKAGE" in TechNet, I only find topics where people have installed some form of SP1. Have you updated your Win7 to SP1?

Welcome to the MSFN!

Could you maybe post the model numbers of the switches that you have there?

A reinstall might do it, but I believe the actual file here is inetcpl.cpl. It might be different name, I don't have access to an XP machine and both my Win7 PCs have some form of IE9 on them.

1. That isn't the correct log file. Get the one from C:\windows\panther\unattendGC or C:\windows\system32\sysprep\panther. 2. I'm wondering why there is Chinese in the log file you posted?

There are two registries in x64. On an unattended install of x64, does sysprep write the changes to just the x86 registry?

Try installing it from the website first, if that doesn't work then we can look at some logs.

Got some results finally. Got MSHTA and MSHTA64 to at least show an HTA with files without giving an error. Problem is that it doesn't show anything besides the Browse box on the Imagex HTA. The SVG HTA exits out completely. Had to take ownership of files in the mounted system32. Replaced the following: ieframe.dll ieui.dll imgutil.dll mshtml.dll mshtml.tlb mshtmled.dll msrating.dll Removed CDATA object from SVG.HTA and makes no difference. Got a little further using Depends to determine any particular issues. Added: wmdrmsdk.dll rpchttp.dll d3d10level9.dll d3d10warp.dll d3d10.dll d3d10core.dll Here's where the problem lies. Depends keeps reporting that DXGI.DLL is calling functions from D3D10WARP.DLL and they are returning NULL values. Unfortunately, these values are NULL by default, as can be seen here: MSDN So how to get these variables have values? This may be related to the fact that DX nor .NET support is in PE, so not sure how to troubleshoot what needs to be present, such as services or DLLs that need to be registered.

Run at least 12hour Memtest on each stick of RAM separately. Sometimes you can have errors when memory is used together and not separately.

You are running in Dual Channel. It is normal for it to read 667, as 667*2 = 1333Mhz (approx)... Check the BIOS to see if you can see the actual bus speed there, should be 1333MHz and not say... 1066MHz.

I want to point out that there is nothing wrong with the Sandy Bridge CPU! The problem Intel reported it only for the 6 Series of motherboards, including: DH67CF, DH67BL, DH67CL, DP67BA, DP67DE and DP67BG. It is also not really stated if the Sandy Bridge problem is in other integrator's boards like Asus or Gigabyte, etc or if it is just Intel branded boards.

Yep, wait until end of February 2011 for the fixed Sandy Bridge boards.

The error you are getting is caused by Windows Installer when attempting to install "an update" from Windows Update. Even the newer MSSE versions are considered updates... On KB it says to have it create verbose logging to determine what the actual problem is. Before you even go that far, you might want to check in Event Viewer to see what kind of errors show up in there from Windows Installer or Windows Update. Here is the link: http://support.microsoft.com/kb/958052 I'll move this topic into Windows 7 forum too.

We have a WPI forum. Since your topic is about installs (I do not use WPI) I shall move it there. Hopefully you aren't referring to a different WPI.