[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: XyWin now working! Microsoft solves problem shock!
- Subject: Re: XyWin now working! Microsoft solves problem shock!
- From: "Robert Holmgren" holmgren@xxxxxxxx
- Date: Thu, 16 Aug 2007 06:32:53 -0400
** Reply to message from Michael Norman
on Wed, 15 Aug 2007 21:18:30 -0400
> I think that should be *sfc* instead...
> SFC [/SCANNOW] [/SCANONCE] [/SCANBOOT] [/CANCEL] [/QUIET]
> [/PURGECACHE] [/CACHESIZE=x]
Thank you! So it's SFC, not SFR; and PURGECACHE, not PURGCACHE.
Bleepity bleep.
The real question is, why did the original DLLs get replaced?
Obviously, a program installer replaced an original file with a
newer or specially-tailored version of a DLL that the installed
program requires, but which was never submitted to MS for
certification. So, by restoring original MS-certified DLLs, is
SFC /PURGECACHE going to re-enable XyWin but incapacitate some
other program(s)? The answer may well be Yes, so I would be
cautious in the use of SFC (last time I used it, which was years
ago, I *think* it asked for confirmation on each file
replacement, but I'm not positive). I'd much prefer to know
exactly which DLL is crashing XyWin -- I'll bet there is just
one -- and swap in the certified version on a test basis to see
what happens. I suspect that this expert used a broadbrush
approach and replaced *all* uncertified DLLs, without
pinpointing which one(s) were trapping XyWin. Or did he? If
so, which one is it? Do you recall whether you had to OK each
file replacement?
So, yes: I would like to see Paul's PROCMON log for his failed
XyWin launch, and also ANOTHER log of a successful launch.
Please ZIP up and attach to a private email. Thanks.
-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------