1) regsvr32 /i /n digest.dll - DllInstall in digest.dll failed.
Return code 0xc0000005 [double-checked and omitted to give full
details first time - apologies]
Aha. That's more understandable then. The error code is a page
fault
so there still could be a problem with RAM in a dependent module.
I suggest you try using Dr Watson to see if it captures that page
fault.
<title>KB275481 - How to Troubleshoot Program Faults with Dr.
Watson</title>
Another thing you could do is use FileMon (freeware from
SysInternals)
to monitor .dll usage associated with that regsvr32 command.
It would probably only be useful if you have access to an identical
system
which is working properly. Then you could compare the traces on the
two
systems and note the main discrepancy.
Similarly if you have access to an indentical system which is working
properly you could compare the versions of the various modules on
both systems.
Here are some excerpts from some previous posts which may help you
do that.
<excerpt>
Download the GetVers utility from the MS DLL Help Database
Help page. Then in a command window enter:
for %d in (*.dll) do GetVers "%d" >>versions.txt
(Pathing left as as an exercise for the user.)
</excerpt>
<excerpt>
Ironically an alternative to this would be an excellent
application of WSH scripting. E.g. instead of downloading
GetVers.exe as described above you could create a
GetVers.js script file containing only:
Set arg = WScript.Arguments
Set objFSO = CreateObject("Scripting.FileSystemObject")
Wscript.Echo( objFSO.GetFileVersion(arg(0)))
Note: this is adapted from the topic Retrieve File Version
Information
in the System Administration Scripting Guide.
For simplicity we assume that there is only 1 item in the argument
(e.g. no spaces in the filename).
</excerpt>
There is no script engine for file extension ".vbs".
Which OS? If NTx open a command window and enter:
<example>
D:\>assoc | find /i "vbs"
.vbs=VBSFile
D:\>ftype | find /i "vbs"
VBSFile=%SystemRoot%\System32\CScript.exe "%1" %*
</example>
I think that the only reason I have that is because I use command line
scripts and once entered:
<example>
cscript //H:CS
</example>
The default supposedly is WScript.exe and you may also find
similar associations for extension "js"
</excerpt>
Putting all those ideas together (or using just the first)
you would have two lists called versions.txt, one from a system
which seems good but which you think is at the same maintenance level
as yours, and the versions.txt list for yours. The lists would be
for c:\windows\system (e.g.).
Then what I would do is sort them and saved the sorted versions.
E.g. on your system execute:
sort <versions.txt >sortedversions1.txt
and on the other system execute:
sort <versions.txt >sortedversions2.txt
(You may prefer to use different names to enable simpler final
analysis
in the last step.)
Then transfer one of those sorted lists to the other system and
execute: fc sortedversions1.txt sortedversions2.txt >diff.txt
notepad diff.txt
Analyse diff.txt to figure out if there are any significant
differences between the two systems which would relate to your
problem. This analysis might
be assisted by the list of .dlls that the FileMon trace that you
took earlier.
I have commented before that it would have been trivial but extremely
useful for the setupwbv.dll tool to include actual version
information
in its Fix IE Log.txt report but unfortunately such is not the case
and
thus it is up to the user to do something such as I have outlined
above
to try to find out what versions are actually being used.
Hmm... I just thought of another tool which exists in XP, which
doesn't
exist in all OS but which would be worthwhile investigating first
before
jumping in with a scripting alternative: msinfo32. If you have
that tool
see if it shows you the version information for the modules it lists.
If you can save the list to a text file (possible in XP), so much the
better.
Apparently its availability may depend on what other software
you have installed:
<title>KB159213 - MSINFO: A Tool to Investigate DLL and Executable
Modules</title>
<quote>
Msinfo is distributed in the Microsoft Office distribution.
</quote>
Unfortunately it is not clear if that is a typo for msinfo32
(in both places) but it appears to be.
HTH
Robert
---
...
Robert,
Many thanks - very helpful. I think we're on the right track
vis-a-vis problem with "upwardly compatible" assumptions. Potted
history might help:
1) Original Problem: Stuck between rock and hard place - neither
repair nor revert to previous version options available. "Fix/work
around" - clean uninstall Ieradicator. > Clean ie6 sp1 install.
2) Everything works fine till Ierepair etc (As I understand it
"upwardly compatible" pre-supposes a continuous [history/presence]
of updated files - intact and stretching back to the base file - for
[continuity] checks to work OK.)
3) Problem seems to be ie6 sp1 install is either:
a) not completely clean and resulting in discontinuous files/registry
entries?
b) ie6 sp1 is not a standalone/base version but an upgrade and that
is the base version that needs to be installed ie5 etc??
c) tried to test this by clean uninstall/install 4.01 sp1 from old
CD Rom. [Initial file checking failed for security reasons >> check
system clock. Option to rename/disable wintrust.dll - thought it
best to ask first??]
Here is quick summary of tests so far:
1) regsvr32 /i /n digest.dll - DllInstall in digest.dll failed.
Return code 0xc0000005 [double-checked and omitted to give full
details first time - apologies]
2) regsvr32 /i /n wininet.dll - DllInstall in wininet.dll
Succeeded 3)
HKLM,"Software\Microsoft\Windows\CurrentVersion\RunOnceEx\500" . No
"500" subfolder
Entry: (Key); Value: (Key); Last modified: N/A.
Hope this helps and sorry about the incomplete info on digest.dll.
With a bit of luck, this might mean identifying the most recent
available [base] version of ie and doing a clean install followed by
Windows Update. Let's hope life is that simple ... or even simpler!
Once again, many thanks for all your help.
Denis
