WU update 643 error w/C++ 2005 redistributable

I suspect the file it detects is the %windir/system32/vbscript.dll that was included with the O/S, whose version is 5.8.7600. If I allow the O/S to attempt to install the service pack, the Installer fails with error code 643, and then the Start button turns into Shut Down that has a yellow shield emblazoned with an exclamation point, and the O/S attempts to install the service pack at shutdown, but with the same 643 error, and keeps on whining about that every session. If I try to install the runtime itself, error 1935 occurs. It also happens if I try to install the 2008 runtime.

The only way to block the former Start button condition is to clear out the SoftwareDistribution folder. The odd thing is that the huge patch series that was just released installed fine — except for the VB 2005 redistributable.

I wonder if the problem is related to contents of the Side by Side folder winsxs? There seem to be other VB runtime vbscript.dlls in there, as there are folders named with the format x86_windows-scripting-vbscript31bf3856ad364e35_6.1.7600_xxxxx_none_yyyyyyyyyyyyyyyy, where xxxxx is either 20662 or 16546 or 16385, and yyyyyyyyyyyyyyyy is respectively either 48cc9903a84aaeeb or 485c9d388f193c9b or 483059728f3a98ba. I’m guessing that Virtual BASIC’s PID is 31bf3856ad364e35. The 16385 folder has a sibling folder with .resources and _en-us_ in its name, that has a vbscript.dll.mui file in it. It’s all very arcane.

The error-log error is
Product: Microsoft Visual C++ 2005 ATL Update kb973923 - x86 8.0.50727.4053 -- Error 1935.An error occurred during the installation of assembly 'Microsoft.VC80.ATL,type="win32",version="8.0.50727.4053",publicKeyToken="1fc8b3b9a1e18e3b",processo rArchitecture="x86"'. Please refer to Help and Support for more information. HRESULT: 0x80070003. assembly interface: IAssemblyCache, function: CreateAssemblyCacheItem, component: {97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E}

GASP GASP GASP.

I wonder if deleting the Side-by-Side stuff for VB runtime would help? If any of the .dlls in Side-by-Side are the dangerous ones, might WU might be detecting those, and flagging the installation as needing the update?

I just think that M$ has a nasty service-pack installation bug here, for there are LOTS of complaints on the Web about the VB 2005 SP1, and M$ doesn't have a simple solution.

Thanks.

For error 1935 I found a couple solutions a bit strange but try it


METHOD I

1.Find in C:\Windows\System32 file mscoree.dll and rename it to mscoreebak.dll

2.Install Microsoft Visual C++ and other problematic programs

3.rename mscoreebak.dll to mscoree.dll

METHOD II

1.Find folder C:\Windows\Assembly and rename it to C:\Windows\Assembly.bak
2.Install problematic program
3.Rename Assembly.bak to Assembly

METHOD III

Some people recommend reset system transaction logs in this case

so let's go:

CLFS transaction logs - Reset

MS don't know much about this error,a couple articles:

http://support.microsoft.com
/kb/902330
BUG: Error 1935 During Install of the .NET Framework
You may receive an "Error 1935" error message when you use the Netfx.msi Windows Installer package to install the .NET Framework 1.1

Related to your theory about WinSxS error,I doubt it,but if you really want you can check in event viewer do you have any Side by Side errors or not

I attached here manual how to diagnose WinSxS
Diagnosing SideBySide failures - Junfeng Zhang's Windows Programming Notes - Site Home - MSDN Blogs

Flavius: Thanks for all your help attempts! :)

OK, this has got to be the gnarliest problem I've ever seen! I've tried all your suggestions, but to no avail. Not only can the 2005 C++ (8.0?) runtime not get its patch (so I disabled it in WU for now), but I can't install the 2008 (9.0?) redistributable either (original nor SP1). Both give 1935 errors (see below). What's odd is that it seems apps that call C++ redistributable services work, but there's no entry in Programs & Features that show either is installed. So, I'm inferring that both the 2005 and 2008 redistributables are part of the Win 7 O/S installation itself, since, looking in the %windir%\winsxs folder, I see x86_microsoft_vc80 and *_vc90 folders in there that I assume are the runtime "assemblies", despite there being no uninstall entries in P&F — unless those are remnants of old installations that somehow didn't get uninstalled.

BUT, at any rate, I was running Trend Micro Internet Security (malware's never gotten past the product), and they sent me a free upgrade to their new "Titanium" package. So, I removed TMIS to install the new one, and its MSI tries to install the VC++ 2005 redistributable — which fails again with error 1935 of course, so rolls back, and I can't install their antivirus package at all. To work around that and not have to run without an AV net, I re-enabled Windows' own firewall and Defender, then installed MS Security Essentials, which looks like it works great.

Anyway: I've looked in the installation logs for the runtimes, but they give no clear clue as to what's failing; nor does the cbs.log. Seems to me from search-engine browsing that these VC++ runtime installation problems are rampant, and NO ONE gives even reasonably technical help for them.

I wish I could find instructions for manually removing all files for, and Registry entries that pertain to, the runtimes (including stuff in winsxs). It should then be possible to reinstall them without collisions that result in 1935 errors, right?

Here're the error message for today's 2005 & 2008 runtime install attempts:

• Product: Microsoft Visual C++ 2005 Redistributable -- Error 1935.An error occurred during the installation of assembly 'policy.8.0.Microsoft.VC80.ATL,type="win32-policy",version="8.0.50727.762",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86"'. Please refer to Help and Support for more information. HRESULT: 0x80070003. assembly interface: IAssemblyCache, function: CreateAssemblyCacheItem, component: {66332652-9C28-58B1-A01F-C8B3B9A1E18E}
• Product: Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.17 -- Error 1935.An error occurred during the installation of assembly 'Microsoft.VC90.ATL,version="9.0.30729.1",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x 86",type="win32"'. Please refer to Help and Support for more information. HRESULT: 0x80070003. assembly interface: IAssemblyCache, function: CreateAssemblyCacheItem, component: {AE56AAF5-F3C0-3D4B-8859-A1E50A3E27BF}

Notice they both have the same HRESULT and publicKeyToken. "Assembly" seems to be jargon for the winsxs folders I refer to above, along with the most recent stuff in %windir%.

There are pretty verbose cbs.log sections for both failed redistributable attempts, which have a bunch of "Call to uninstall failed" errors in the transactions. There's nothing suspicious in the MSI Installer Cleanup list.

Any more ideas? I'm stumped. Thanks again.

One more thing I wanted to check with you on before I try it: the fsutil resource setautoreset true c:\
My Windows drive is F:, so should I replace c:\ with f:\, and will there be possible problems after I do that? What are possible side effects, if any?

Thanks again.

In case it helps debugging, here's my environment-variable list, and all directories in paths exist:

ALLUSERSPROFILE=F:\ProgramData
APPDATA=F:\Users\Helge\AppData\Roaming
CommonProgramFiles=F:\Program Files\Common Files
COMPUTERNAME=CUD
ComSpec=F:\Windows\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HOMEDRIVE=F:
HOMEPATH=\Users\Helge
LOCALAPPDATA=F:\Users\Helge\AppData\Local
LOGONSERVER=\\CUD
NUMBER_OF_PROCESSORS=2
OS=Windows_NT
Path=F:\Windows\system32;F:\Windows;F:\Windows\System32\Wbem;F:\Windows\System32\WindowsPowerShell\v 1.0\;D:\klassm\4Win
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 3, GenuineIntel
PROCESSOR_LEVEL=15
PROCESSOR_REVISION=0403
ProgramData=F:\ProgramData
ProgramFiles=F:\Program Files
PROMPT=$P $B $T$H$H$H$H$H$H$G
PSModulePath=F:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=F:\Users\Public
SESSIONNAME=Console
SGIMAGE=D:\klassm\4Win\GIFs
SSD=true
SystemDrive=F:
SystemRoot=F:\Windows
TEMP=F:\Users\Helge\AppData\Local\Temp
TMP=F:\Windows\TEMP
USERDOMAIN=CUD
USERNAME=Helge
USERPROFILE=F:\Users\Helge
windir=F:\Windows

WEIRD!!! I ran the system upgrade wizard one more time, and it reported that a manifest file for 2005 C++ redistributable (x86_policy.8.0.microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.762_none_8e053e8c6967ba9d.manifest) was missing. So, since I had a parallel Win 7 installation on my offline rotary HDD (the one I use is an SSD...), I put it on line and copied file over from its %windir\winsxs\manifests folder to the SSD's, and now installation of VC++ 2005 RD SP1 seems to work. But, I still get the notification from WU about the security update, and when I accept that, afterward it turns the Start button into a shield to indicate it needs to shut down to be installed, seems to install ok when I shut down ... but then the redistributable is gone from Programs & Features when I restart, although the I-need-to-shut-down shield comes back, and shutdown/update continues in a loop. So, I disabled the VC++ 2005 SP1 redistributable security patch in WU, and I guess I'm going to have to live with it as it is. Trend Micro Titanium, however, still tries to install the redistributable even when P&F has it in there, which crashes, and I can't install that AV at all. So, I'm compelled to stay with MS Security Essentials...

And, I can't get the 2008 VC++ RD SP1 to install at all. 1935 error, but there's no missing-manifest for that. As I said, there's something really strange going on. Obviously, something's out of sync somewhere, causing all the confusion, but finding the needle in the Win 7 haystack is nearly impossible.

bachware said:

In case it helps debugging, here's my environment-variable list, and all directories in paths exist:

ALLUSERSPROFILE=F:\ProgramData
APPDATA=F:\Users\Helge\AppData\Roaming
CommonProgramFiles=F:\Program Files\Common Files
COMPUTERNAME=CUD
ComSpec=F:\Windows\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HOMEDRIVE=F:
HOMEPATH=\Users\Helge
LOCALAPPDATA=F:\Users\Helge\AppData\Local
LOGONSERVER=\\CUD
NUMBER_OF_PROCESSORS=2
OS=Windows_NT
Path=F:\Windows\system32;F:\Windows;F:\Windows\System32\Wbem;F:\Windows\System32\WindowsPowerShell\v 1.0\;D:\klassm\4Win
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 3, GenuineIntel
PROCESSOR_LEVEL=15
PROCESSOR_REVISION=0403
ProgramData=F:\ProgramData
ProgramFiles=F:\Program Files
PROMPT=$P $B $T$H$H$H$H$H$H$G
PSModulePath=F:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=F:\Users\Public
SESSIONNAME=Console
SGIMAGE=D:\klassm\4Win\GIFs
SSD=true
SystemDrive=F:
SystemRoot=F:\Windows
TEMP=F:\Users\Helge\AppData\Local\Temp
TMP=F:\Windows\TEMP
USERDOMAIN=CUD
USERNAME=Helge
USERPROFILE=F:\Users\Helge
windir=F:\Windows

Here I recommend to restore to defaults:

PROMPT=$P$G
TMP=F:\Users\Helge\AppData\Local\Temp

restart computer to apply changes and check results

I reset my personal TMP variable as you suggested, but no diff. Since PROMPT just displays the prompt in the command environment, I can't see any reason to change it. Mine just displays the path & time, then backspaces over the seconds with $H.