"Access is denied" to \i386 repairing Windows XP from Recovery Con

[Guest]

I recently had the "pleasure" of helping repair a friend's WinXP Home SP2
machine. He installed some game package, and upon reboot, he got the dreaded
"Windows could not start because Ntfs.sys is Missing or Corrupt" message.
Armed with KB822800, I started Recovery Console from the OEM distribution
CD-ROM, logged in using the Administrator password, and attempted to copy
Ntfs.sys from the CD-ROM's \i386 directory, as instructed. I got an "Access
is denied." message. Apparently, some genius decided it would be a good idea
to make the i386 directory Hidden and System, apparently making it unreadable
(and untraversable) from Recovery Console.
Can I get access to the Ntfs.sys file in the CD-ROM's \i386 directory?
Assume I only have access to Recovery Console, since Windows XP won't start,
and he only has one computer, and I don't want to go home and copy the stupid
file on a computer that has a somewhat less fascist security policy. Does
granting this privilege require registry editing from Recovery Console? If I
can't gain access privileges, isn't this an incredible Catch-22?

 

[Pegasus \(MVP\)]

I recently had the "pleasure" of helping repair a friend's WinXP Home SP2
machine. He installed some game package, and upon reboot, he got the dreaded
"Windows could not start because Ntfs.sys is Missing or Corrupt" message.
Armed with KB822800, I started Recovery Console from the OEM distribution
CD-ROM, logged in using the Administrator password, and attempted to copy
Ntfs.sys from the CD-ROM's \i386 directory, as instructed. I got an "Access
is denied." message. Apparently, some genius decided it would be a good idea
to make the i386 directory Hidden and System, apparently making it unreadable
(and untraversable) from Recovery Console.
Can I get access to the Ntfs.sys file in the CD-ROM's \i386 directory?
Assume I only have access to Recovery Console, since Windows XP won't start,
and he only has one computer, and I don't want to go home and copy the stupid
file on a computer that has a somewhat less fascist security policy. Does
granting this privilege require registry editing from Recovery Console? If I
can't gain access privileges, isn't this an incredible Catch-22?

There is no romm for fascism in Windows and the i386 directory
on the CD ROM is not hidden. You can confirm this by looking at
the CD on any other PC. The message you see is probably generated
because of an invalid target folder you specify. Where are you trying
to copy it to? Have you tried to copy it to your current working
directory?

Access to data directories is indeed restricted while in the Recovery
Console. You can change it like so when the machine is up and
running again:
- Run gpedit.msc
- Local Computer Policy / Computer Configuration / Windows Settings /
Security Settings /
Security Options / Recovery Console: Allow floppy disk access . . .
- Set this policy to "Enabled".

 

[Guest]

Thanks, Pegasus, for your rapid reply. I has assumed that the directory was
Hidden and System, because when I typed dir at the prompt, the attributes of
i386 were reported as something like d----hs- or something similar.
Strangely, I just looked at the same CDROM here at home under the CDROM's
Recovery Console (on a machine that has WinXP Professional installed), and
dir gave not only a significantly different filelist (i.e. about half the
entries), but it reported the attributes of \i386 as d-r-----, which is more
like I'd expect from a CDROM.

BTW, I followed the instructions in KB822800 exactly, i.e. I typed the
following to the Recovery Console:
cd \windows\system32\drivers
ren ntfs.sys ntfs.old
copy D:\i386\ntfs.sys C:\windows\system32\drivers
(and that's when I got "Access is denied.")
(I tried it several times too, so it wasn't a misspelling)

Also typing:
D:
cd \i386
gave "Access is denied." also.

I suspect the problem may have had something to do with booting from the
CDROM. I'm no longer at my friend's house, so I can't test the theory, but
some computers, when booting from a CDROM, remap the CD to drive A:. I may
have therefore run across some conflict in drive lettering, and if I had
tried using drive A: as the CDROM drive instead of D:, everything would have
been fine. If not, there must have been something deeper going on with the
WinXP installation (does starting the CDROM's Recovery Console use ANY of the
hard drive XP installation's drivers/files?), or with the CD drive's
hardware. Thoughts?

 

[Pegasus \(MVP\)]

See below.

Thanks, Pegasus, for your rapid reply. I has assumed that the directory was
Hidden and System, because when I typed dir at the prompt, the attributes of
i386 were reported as something like d----hs- or something similar.
Strangely, I just looked at the same CDROM here at home under the CDROM's
Recovery Console (on a machine that has WinXP Professional installed), and
dir gave not only a significantly different filelist (i.e. about half the
entries), but it reported the attributes of \i386 as d-r-----, which is more
like I'd expect from a CDROM.

BTW, I followed the instructions in KB822800 exactly, i.e. I typed the
following to the Recovery Console:
cd \windows\system32\drivers
ren ntfs.sys ntfs.old
copy D:\i386\ntfs.sys C:\windows\system32\drivers
(and that's when I got "Access is denied.")
(I tried it several times too, so it wasn't a misspelling)

Also typing:
D:
cd \i386
gave "Access is denied." also.

A moment ago I ran this same test myself from the
Recovery Console. I had no problem at all reading
the i386 folder on my WinXP Professional installation
CD. This leaves you with three possible reasons for
problem:
a) Your CD is a damaged. Borrow a replacement.
b) Your CD is a fake. Get the real thing.
c) Your CD drive is marginal. Replace it.

I suspect the problem may have had something to do with booting from the
CDROM.

No. The Recovery Console is usually launched in just this way.

I'm no longer at my friend's house, so I can't test the theory, but
some computers, when booting from a CDROM, remap the CD to drive A:. I may
have therefore run across some conflict in drive lettering, and if I had
tried using drive A: as the CDROM drive instead of D:, everything would have
been fine.

Remove the CD temporarily and you will soon know.