One of the first things I do on a "fresh" system is re-assign the CD/DVD
drive to "R:". And then go in and change each and every reference to D: (or
whatever it was) in the registry to point to the new location. Now as I
add/remove drives, I don't have to worry about what drive letter the CD is
on - it's always at the same location on every machine. Makes life simpler.
But what I really, really, want is "regsed" -- a stream editor for the
registry. It would make my life so much easier.
--
Charlie.
http://msmvps.com/xperts64
"Darrell Gorter[MSFT]" wrote:
> Hello,
> It does a lookup for each filename, so each file that is replaced looks to
> find where the source should be ( layout.inf is what it looks at to find
> where the file came from ( service pack or install CD)). Based on that it
> looks for the location specified in the registry for that filename. That
> is why if you have installed a servicepack for instance you may be
> prompted for the service pack cd instead of the OS cd. You have to
> modify the registry to change the behavior of the where SFC looks for
> files.
> Thanks,
> Darrell Gorter[MSFT]
>
> This posting is provided "AS IS" with no warranties, and confers no rights
> --------------------
> <From: "M. Murcek" <>
> <References: <>
> <#>
> <Subject: Re: Just ran sfc...
> <Date: Thu, 6 Apr 2006 16:27:14 -0400
> <Lines: 30
> <X-Priority: 3
> <X-MSMail-Priority: Normal
> <X-Newsreader: Microsoft Outlook Express 6.00.3790.1830
> <X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
> <X-RFC2646: Format=Flowed; Response
> <Message-ID: <uVXq#>
> <Newsgroups: microsoft.public.windows.64bit.general
> <NNTP-Posting-Host: monrovll-cuda1-68-168-191-9.pittpa.adelphia.net
> 68.168.191.9
> <Path:
> TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA02.phx.gbl!TK2MSF TNGP01.phx.gbl!TK2MSFTNGP0
> 4.phx.gbl
> <Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.windows.64bit.general:32281
> <X-Tomcat-NG: microsoft.public.windows.64bit.general
> <
> <Thanks Rick. I figured the dll question was a "Who knows? Could be
> <anything." Once sfc was told once where the CD was, it seems odd that it
> <kept looking to the registry, rather than to whatever was cached as the
> <program ran, but hey, there it is.
> <
> <Again, Thanks.
> <
> <
> <"Rick" <> wrote in message
> <news:%...
> <> There are a multitude of reasons as to how .DLL's may get corrupted.
> So <> that cannot be answered without a debugger running, and know exactly
> what
> <> is going on at the time.
> <>
> <> As for the CD drive, when you install Windows it assigns drive letters
> and
> <> keeps the letter of the install CD drive in the registry. Usually the
> <> inability to find the CD is due to someone changing the drive letter in
> <> the Management Console. You can edit the registry to point to the
> current
> <> CD drive letter.
> <>
> <>
> <> M. Murcek wrote:
> <>> It did fix my problem. Now, two questions. It apparently put back
> some
> <>> missing / changed / corrupted dlls. Anyone have a simple, general
> <>> explanation on how the dlls might have got that way? Also, I had to
> keep
> <>> telling sfc to retry looking for the x64 Edition CD. Why come Windows
> <>> couldn't keep track of where it was at as sfc ran? No big deal, I'm
> just
> <>> curious.
> <
> <
> <