SFC /SCANNOW asking for files from non existent sources...


M

Ms. Linda A.W.

I wanted to verify my Windows files. While I have installed the
CD i386 image in the /windows/options/i386 directory, it seems to ignore that
location. It wanted to see the files in the root directory C:\i386. So I
copied the files there (though I'm sure I've used /windows/options/i386 in the
past. That solved the requst for the WinXP CD,
but now it wants a Service Pack 1 CD.

Um...I never had an SP1 CD. I downloaded
it and installed it over the net from my file server. So why is it asking
for a CD that never existed and/or how can I point the install location back to
where I installed it from?

thanks for pointers...I'd love to get a clean run.

Am having trouble with Office products (Word 2k or xp) using various
international fonts ('MS Unicode et al). I can select he fonts but
any text formated with the broken fonts is invisible.

This has existed since I was advised by a Microsoft Support technician
to uninstall all my office products and reinstall to solve another problem,
but on re-installing, the problem is immediately evident. Under the
International font support, additional core files and the universal font
are "X"'ed out to indicate they woudln't be installed by _default_. I can
force the install of the fonts, but they won't work.

The fonts _DO_ work in wordpad, but not in Word, Powerpoint or Outlook.
They also work in other 3rd party apps including MS's IE6.

Any help into either problem would be great.

I have uninstalled and reinstalled with different options, but I need go no
farther than installing CD1 of Office 2000. As soon as I see the "X"'ed out
default, I know the problem exists, as it didn't have that problem the first
time I installed it. I have run the Office 2003 setup cleanup file, but
I don't know if it fixes Office 2000 or XP problems. There is no cleanup
tool for O2k that runs on XP that I've found.

Microsoft "specialists" in Bangalore have been on this for a week around 2-3
hours/call and have gotten no where. The problem is they don't seem to have
access to the source or knowledge of the internals of what can be causing these
problems. They just keep you on the phone hours and hours repeating steps
already done "just because"...

The problem I have in Outlook has to do with it speaking the wrong protocol
to talk to my IMAP server. It's literally not complient with the protocol
and doesn't send an "end-of-command" message to the server, so the server
never responds, but Outlook thinks it sent it...deadly embrace/deadlock.
It is a random problem based on timing happening about 30% of the time.

It's frustrating to label security fixes as "critical' and then when you install
them, your rollback is corrupted and your Outlook client stops functioning.
They have so far refused to issue a patch or replacement product. I
specifically bought the outlook upgrade to handle my multiple IMAP folders --
worked for all of 5 months before being disabled by a Critical MS security
hack.

I noticed elsewhere, that if one installs a task scheuler task or SP2, the task
scheduler failes to run jobs -- the person who investigated that said microsoft
had no schedule or urgency to fix the problem.

I'm beginning to feel like MS is deliberately sabotaging their software so older
software breaks and the OS (WinXP) is slowing down (significantly since first
release) so they can impress us with the fact that Longhorn(vista) will run
at full speed again.

Sorry venting a bit...but this has drawn out to more than 2 weeks this go-round
and this one wiped most of my unicode fonts -- specially Arial Unicode MS --
which I use regularly in my documents but can no longer access or print.
:-(

Again, thanks for any help.

Linda



-- .
 
Ad

Advertisements

P

Peter

Start/Run/Regedit go to HKLM/Software/Microsoft/Windows/Setup and alter to
following to C:\
ServicePackSourcePath
SourcePath
 
M

Ms. Linda A.W.

Peter said:
..Also, I just copied and pasted the i386 folder on C:\ not into any options
folder.
It's outlined here: http://www.updatexp.com/scannow-sfc.html
===
Made further progress, but still have problems. The first I've run into
has SFC looking in the wrong place in "Service Pack 1" for a missing file:
"coadmin.dl_" (or .dll). On my SP1 CD (turns out it was included with a
book (Microsoft XP Inside/Out). The file is located at
<servicepack>/i386/ip/coadmin.dl_>.

Thinking my SP1 copy might be odd or corrupt, I just downloaded it just
now, again -- and have figured out "why", but not "why" (!?).
SFC is looking for a file COADMIN.DL_ (or .DLL). It is looking in the "i386/"
directory of the "ServicePackFiles" location, but in SP1, this file is located
at <servicepackpath>\"i386\ip\coadmin.dl_". I.e. not "i386\[filename]",
but in the subdirectory "ip/" under "i386/".

Thinking my SP1 copy might be "weird" for some reason, I just re-downloaded
the 126M SP1 patch. It still has the file "coadmin.dl_" located in the
subdirectory "ip".

Obviously, I can "kludge" around this by moving files from their proper location
to where "SFC" wants to see them, but this would involve me "corrupting" the
the SP1 image. I'm sure some of my other problems were (are) of this ilk as
well. Looking at the "DLL Help Database" for this file
(http://support.microsoft.com/dllhelp/?dlltype=file&l=55&alpha=coadmin.dll&S=1),
it seems only a small-business-edition has it in such a subdirectory, but I
can see the file in the "ip/" sub dir in the "xpsp1a_en_x86.exe" I just downloaded.

This seems a bit "whacked" that I should need to move ServicePack files around
to get SFC to work properly. The "coadmin.dll" is in the "i386" directory of
the original XP release.

I suppose I'll make a 2nd copy of the SP1 dir to contain my "modified" SP1
files, but this makes for a ugly hack -- especially since I have to run
sysinternal's "Filemon" to see what file it is looking for...(amongst tons of
output).
 
Ad

Advertisements

P

Peter

OK now we have a problem. I have SP2, which of course you should to but
that's another story, and in order for this to work the SP2 which includes
SP1 and all other updates, has to be slipstreamed into your installation
disk, otherwise you'd be inserting disk after disk and making little
progress. I used Autostreamer and Nero for that.
Is it prompting you to insert disks?
If you aren't careful here it's going to mean a complete reinstallation.

--
Peter
Toronto, Canada
XP Home SP2
P4 HT @ 3ghz, 1gb RAM, 360gb HD
Ms. Linda A.W. said:
Peter said:
..Also, I just copied and pasted the i386 folder on C:\ not into any
options folder.
It's outlined here: http://www.updatexp.com/scannow-sfc.html
===
Made further progress, but still have problems. The first I've run into
has SFC looking in the wrong place in "Service Pack 1" for a missing file:
"coadmin.dl_" (or .dll). On my SP1 CD (turns out it was included with a
book (Microsoft XP Inside/Out). The file is located at
<servicepack>/i386/ip/coadmin.dl_>.

Thinking my SP1 copy might be odd or corrupt, I just downloaded it just
now, again -- and have figured out "why", but not "why" (!?).
SFC is looking for a file COADMIN.DL_ (or .DLL). It is looking in the
"i386/"
directory of the "ServicePackFiles" location, but in SP1, this file is
located
at <servicepackpath>\"i386\ip\coadmin.dl_". I.e. not "i386\[filename]",
but in the subdirectory "ip/" under "i386/".

Thinking my SP1 copy might be "weird" for some reason, I just
re-downloaded
the 126M SP1 patch. It still has the file "coadmin.dl_" located in the
subdirectory "ip".

Obviously, I can "kludge" around this by moving files from their proper
location
to where "SFC" wants to see them, but this would involve me "corrupting"
the
the SP1 image. I'm sure some of my other problems were (are) of this ilk
as
well. Looking at the "DLL Help Database" for this file
(http://support.microsoft.com/dllhelp/?dlltype=file&l=55&alpha=coadmin.dll&S=1),
it seems only a small-business-edition has it in such a subdirectory, but
I
can see the file in the "ip/" sub dir in the "xpsp1a_en_x86.exe" I just
downloaded.

This seems a bit "whacked" that I should need to move ServicePack files
around
to get SFC to work properly. The "coadmin.dll" is in the "i386" directory
of
the original XP release.

I suppose I'll make a 2nd copy of the SP1 dir to contain my "modified" SP1
files, but this makes for a ugly hack -- especially since I have to run
sysinternal's "Filemon" to see what file it is looking for...(amongst tons
of
output).
 
M

Ms. Linda A.W.

Peter said:
OK now we have a problem. I have SP2, which of course you should to but
that's another story, and in order for this to work the SP2 which includes
SP1 and all other updates, has to be slipstreamed into your installation
disk, otherwise you'd be inserting disk after disk and making little
progress. I used Autostreamer and Nero for that.
Is it prompting you to insert disks?
If you aren't careful here it's going to mean a complete reinstallation.
=======
I don't have SP2 installed. I tried installing it, but too many things
broke at once. It updated successfully (wasn't running any virii scanners
nor infected w/any; behind a couple of firewalls). But even after disabling
the SP2 firewall, too many programs had problems. A short list:
---(file:XP2 faults.txt)---
SP2 - incompat issues -
1) web access corrupt
2) hanging problem launching web items from task bar
3) won't read sopphos disk (thought it was HW, but would read on SP1)
4) program crash for mouse scroll function
5) uxtheme.dll needed replacing (ok)
6) URL launch from explorer hangs Start Menu/Taskbar
7) long hang at shutdown when trying to save user settings
8) medium hang at startup while
-) hotfixes to deinstall:
867282
885884
886185
887472
88774
==================
So I only have SP1 installed and I didn't slipstream it -- I applied it as
an update. Oddly enough, while going through sfc (not done yet, as I have
to go look for files when it comes up with missing titles, and tracing it
through "Filemon" really slows things down), I have run into the following
problems files that want to be in ServicePackFiles/i386, or are missing
from my "winXP CD":

SFC asked that the SP1 CD inserted for these files, but it was looking
in the "i386/" dir, not a subdir of "i386/". If I had splip-streamed the
CD, the files *were* present on the original XP CD in the "i386/" directory,
so I likely wouldn't have known that they had been relocated on the SP1 update
disk:
ip/coadmin.dl_
ip/adsiis51.dl_
ip/asp51.dl_
new/ati2dvaa.dl_
new/ati2dvag.dl
new/ati3d1ag.dl_
new/ativmvxx.ax
new/ativdaxx.ax

I copied the above files from their individual directories (sub dirs,
"ip/" and "new/") to the "ServicePackFiles/i386" dir. Unfortunately, copying
the files to the "desired" location isn't noticed by "SFC" -- and it still wants
a CD inserted somewhere, so I have to hit cancel and move on. I hope to perform
a full pass through my file system with SFC and get all the filenames it is
going to complain about and make sure they are in the "right" place for my
"next" run of "SFC" (theoretically right after I've made it through this pass).

The following file is *supposed* to be on SP1
(http://support.microsoft.com/dllhelp/default.aspx?l=55&fid=41486),
but I don't see it on the update. I do note, though that the SP1
version and WinXP version are the same, so that's easy enough to copy(fix):
ftpsvc2.dll


The following files were flagged and SFC wanted my original WinXP CD (image) to
install them from, but they are not on it. They may be specific to
my hardware and were applied after the WinXP install, but I'm not sure
why SFC wanted the original XP CD (image) for them:
(where they are not present).
??/atibt829.sys
??/atidrae.dll
??/atidvai.dll
??/atievxx.exe
??/atimpab.sys
??/atimpae.sys
??/atimtag.sys
??/atipcxx.sys
??/atiraged.dll
??/atiragem.sys
??/atirtcap.sys
??/atirtsnd.sys
??/atitunep.sys
??/ativsnd.sys
??/ativmdcd.sys
??/ativtxx.sys
??/ativxbar.sys
??/atixbar.sys
--------
This is a partial list, as SFC hasdn't finished yet...*sigh*...continuing...
I'm so glad I don't have anything better to do on a nice Sunny day in the low
70's in Santa Cruz, CA (USA)....:-/

Linda
 
M

Ms. Linda A.W.

Ms. Linda A.W. wrote a slight "booboo":
The following file is *supposed* to be on SP1
(http://support.microsoft.com/dllhelp/default.aspx?l=55&fid=41486),
but I don't see it on the update. I do note, though that the SP1
version and WinXP version are the same, so that's easy enough to copy(fix):
ftpsvc2.dll
---
Slight correction:
the file that's the same on XP & SP1 is ftpmib.dll
The file "ftpsvc2.dll" isn't on Windows XP at all -- either in
the XP or SP1 disk. It appears on Windows 2000 and Win 2003 Server editions.
Why my XP SFC is searching for it, I'm not sure.

Linda
 
Ad

Advertisements

M

Ms. Linda A.W.

Peter said:
Unfortunately neither am I. You might want to post on TechSupportGuy
forums, they're pretty good at this.
http://forums.techguy.org/
----
Forget the "filemon" util...not needed and just _way_ slows down SFC.
Turns out each non-replaced file generates an entry in the system log (siderant:
why can't this be a simple text file, and why can't you select and copy text
from the log-entry popup. Does MS try to make these things with a difficult
UI?).

Anyway, I'm able to find out where the files that it is looking for
should go after I "cancel" the replacement of the file. Locations that
SFC doesn't seem to be able to check:
1) inside "<XP>/i386/DRIVER.CAB". I've found files in "drivers.cab" that SFC
was looking for on the XP CD but couldn't find (!).
2) inside <servicepackfiles>/i386/new
3) inside <servicepackfiles/i386/ip
4) inside <servicepackfiles/i386/new/SP1.CAB
5) inside <servicepackfiles/i386/<filename>.<ex>_ (i.e. the compressed
filename)
----
So far, I've found 2 files that seemed to be in Win2000 and 1 that I only
found in Visual Studio 6. However, now I have dumped the contents of DRIVER.CAB
and SP1.CAB into separate directories. They were "index'ed" overnight (cygwin
updatedb), so "locate" (also gnu-cygwin) is able to find previously missing files.

Seems very lame that SFC can't look in "DRIVERS.CAB" and "SP1.CAB" as when I
ran "Filemon", I could see that it would search for "Drivers.cab" and "sp1.cab"
when searching for lost files (but it likely couln't find SP1.CAB because it was
in the "new" subdirectory. It's also lame that it can't use the compressed
version; I'm going to "try" to slip-stream the install image after I've
gotten a clean SFC run. I'd have to look up the notes on that, but doesn't
it basically involve copying the SP1 fiels over the XP image and burning (or
using directly) that image? I note though, that doing so might copy 2
versions of of some files -- the XP version of "FOO.DLL" and the the SP1
version of the file "FOO.DL_"; also some of the files in the XP version that
are under the "i386/" directory are under the "i386/new/" and "i386/ip/"
directories in SP1.

Of course, the reason I went through this whole mess was to verify my
system wasn't corrupt because various UNICODE fonts were not working in
Office (Arial Unicode MS, Batang, et al). They work in Wordpad and other
3rd party apps, but not in office. The problem appeared when a MS support
rep suggested I uninstall Office 2k and the 2 independant copies of Word XP
and Outlook XP to solve a problem with Office Update. After reinstalling,
text formatted in those fonts won't display in the office apps. Special.

Sorta like my objective was to fix a pipe in a dam, but had to drain dam which
turned out to be a swamp filled with alligators....etc...;-/

Thanks for your pointers -- I just SFC would tell me what file it is looking
for and allow me to tell it where to find it like in Win98...sigh. Guess that
makes things "too easy".


Linda
 
Ad

Advertisements


Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top